IPv6 explicit BGP group configs

Leo Bicknell bicknell at ufp.org
Wed Feb 8 11:25:19 CST 2012


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 at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120208/41f43e3e/attachment.bin>


More information about the NANOG mailing list