[126611] in North American Network Operators' Group
RE: Quick IP6/BGP question
daemon@ATHENA.MIT.EDU (George, Wes E IV [NTK])
Mon May 24 14:41:43 2010
From: "George, Wes E IV [NTK]" <Wesley.E.George@sprint.com>
To: Thomas Magill <tmagill@providecommerce.com>, "nanog@nanog.org"
<nanog@nanog.org>
Date: Mon, 24 May 2010 13:41:08 -0500
In-Reply-To: <FA2E47FFA50291418803D2E7C1DF07F30B4ED3F8@SDEXCL01.Proflowers.com>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
We've done it both ways.
We've found that there are sometimes issues with announcing IPv6 NLRI over =
IPv4 BGP sessions depending on your chosen vendor and code version on both =
sides of the session. Specifically, we have seen some implementations where=
an IPv4-mapped IPv6 address (usually the IPv4 router-id or neighbor addres=
s) is announced as the next-hop, or a link-local address is used as the nex=
t-hop, or some random junk is announced as the next-hop, even with next-hop=
-self configured. All of these result in the receiving router dropping the =
announcements because it doesn't have a route to the next-hop. It's usually=
possible to work around this by using route policies to force the correct =
next-hop to be written on in/outbound announcements, and as we find it work=
ing improperly, we've been reporting bugs, but I thought it would be worth =
bringing this up as a caveat so that you can make sure your hardware/softwa=
re of choice is behaving properly if you choose to go this route.
Also, I know of at least one vendor that didn't implement the converse func=
tionality in CLI yet - it's impossible to configure an IPv6 neighbor addres=
s in the IPv4 address family in order to exchange IPv4 NLRI over an IPv6 BG=
P session.
Thanks,
Wes George
-----Original Message-----
From: Thomas Magill [mailto:tmagill@providecommerce.com]
Sent: Monday, May 24, 2010 2:22 PM
To: nanog@nanog.org
Subject: Quick IP6/BGP question
>From the provider side, are most of you who are implementing IP6
peerings running BGP over IP4 and just using IP6 address families to
exchange routes or doing IP6 peering?
Thomas Magill
Network Engineer
Office: (858) 909-3777
Cell: (858) 869-9685
mailto:tmagill@providecommerce.com <mailto:tmagill@providecommerce.com>
provide-commerce
4840 Eastgate Mall
San Diego, CA 92121
ProFlowers <http://www.proflowers.com/> | redENVELOPE
<http://www.redenvelope.com/> | Cherry Moon Farms
<http://www.cherrymoonfarms.com/> | Shari's Berries
<http://www.berries.com/>
This e-mail may contain Sprint Nextel Company proprietary information inten=
ded for the sole use of the recipient(s). Any use by others is prohibited. =
If you are not the intended recipient, please contact the sender and delete=
all copies of the message.
