IPv6 explicit BGP group configs

Mailman List Mirror (Read Only)
1

Hi,

I'm prepping an environment for v6 and I'm wondering what, if
any, benefit there is to splitting v4 and v6 into separate groups.
We're running Junipers and things are fairly neat and ordered; we have
multiple links to a few providers in many sites, so we group them and
apply the policies at the group level. We could stick the new v6
neighbors into the same group and apply the policies at the neighbor
level, or create new groups (i.e. Level3 and Level3v6).

This
might sound a little nit-picky, but I'm concerned that there's a nuance
I'm not thinking of right now and I don't want to be "that guy" who puts
something in place and is cursed for a decade.

Thanks,
Keith Tokash

2

In a message written on Wed, Feb 08, 2012 at 08:59:23AM -0800, keith tokash wrote:

I'm prepping an environment for v6 and I'm wondering what, if
any, benefit there is to splitting v4 and v6 into separate groups.
We're running Junipers and things are fairly neat and ordered; we have
multiple links to a few providers in many sites, so we group them and
apply the policies at the group level. We could stick the new v6
neighbors into the same group and apply the policies at the neighbor
level, or create new groups (i.e. Level3 and Level3v6).

I'm going to answer with a very specific bit of administriva, but
I think it illustrates the sort of thing you want to think about.

When adding a BGP address family like IPv6 it can be done by sending
the routes down an existing BGP session (e.g. IPv4 transport carrying
IPv4 and IPv6 routes), or by having two sessions, an IPv4 transport
with IPv4 routes, and an IPv6 transport with IPv6 routes.

Most ISP's do the latter. There are a pile of reasons, but here's
one of the easiest. Imagine a world in the future where we are
removing IPv4 from the network as we're now IPv6 only. If one
transport was used, it must now be torn down and rebuilt over IPv6,
causing an outage for everything and a lot of work for your engineers.
If you used two transports, you can remove the IPv4 and the IPv6
keeps working just fine.

Lather, rince, reapply to everything you can do on routers. How you
group config statements, how you write your management tools, and so on.
I would generally advise, where possible, to treat them like ships in
the night. Keep them in separate areas. It allows you to add IPv6
without disturbing IPv4, and some day will allow you to remove IPv4
without disturbing IPv6.

YMMV. Batteries not included. Not all vendors support all features.
No warranty expressed or implied. Do not taunt happy fun ball.

3

Sometimes we have the same group for v4 and v6, but in most cases we
have different ones. One of the basic reasons is different max-pref setting.

Most policies can be used in two address families, you can also match
prefixes, but you cannot have v4 and v6 prefixes in one term. So in your
policies you have to have at least two terms - one for v4 prefixes, one
for v6 prefixes.

4

Hi,

I've done it either way, I prefer to put the v6 peers in a different
group than the v4 peers so that I can group the policies at the group
rather than neighbor level.

5

In a message written on Wed, Feb 08, 2012 at 06:33:17PM +0100, Grzegorz Janoszka wrote:

Most policies can be used in two address families, you can also match
prefixes, but you cannot have v4 and v6 prefixes in one term. So in your
policies you have to have at least two terms - one for v4 prefixes, one
for v6 prefixes.

Another thing IOS-XR fixes!

route-policy my-example
  if destination in my-ipv4-prefix-list or destination in my-ipv6-prefix-list then
    set community 1234
    set med 0
    done
  endif
end-policy

In 99.99% of the cases it allows you to have one policy for both IPv4
and IPv6, and add the parameter passing I discussed the other day and
it's almost like something was thinking of routing engineers when they
wrote it. :stuck_out_tongue: