IPv6 explicit BGP group configs
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
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. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
On 08-02-12 17:59, 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).
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. -- Grzegorz Janoszka
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. :P -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
On 2/8/12 08:59 , keith tokash wrote:
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.
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
participants (4)
-
Grzegorz Janoszka -
Joel jaeggli -
keith tokash -
Leo Bicknell