Best practices IPv4/IPv6 BGP (dual stack)
Between peering routers on a dual-stacked network, is it considered best practices to have two BGP sessions (one for v4 and one for v6) between them? Or is it better to put v4 in the v6 session or v6 in the v4 session? According to docs, obviously all of these are supported and if both sides are dual stacked, even the next-hops don't need to be overwritten. Is there any community-approach to best practices here? Any FIB weirdness (e.g. IPv4 routes suddenly start sucking up IPv6 TCAM space, etc) that results with one solution over the other? Thanks in advance, DJ
On May 2, 2014, at 3:44 PM, Deepak Jain <deepak@ai.net> wrote:
Between peering routers on a dual-stacked network, is it considered best practices to have two BGP sessions (one for v4 and one for v6) between them? Or is it better to put v4 in the v6 session or v6 in the v4 session?
We use v4 transport for v4 routes and v6 transport for v6 routes only. This way if one plane is unstable the other is unaffected. - Jared
On Fri, May 2, 2014 at 1:47 PM, Jared Mauch <jared@puck.nether.net> wrote:
On May 2, 2014, at 3:44 PM, Deepak Jain <deepak@ai.net> wrote:
Between peering routers on a dual-stacked network, is it considered best practices to have two BGP sessions (one for v4 and one for v6) between them? Or is it better to put v4 in the v6 session or v6 in the v4 session?
We use v4 transport for v4 routes and v6 transport for v6 routes only.
+1
This way if one plane is unstable the other is unaffected.
From the draft BCOP on this topic[1]: ----8<---- Establish new, IPv6-Only peering sessions parallel to existing IPv4
This is the key point I believe: No protocol fate sharing! peering. Individual IPv4 and IPv6 BGP peering sessions should be established between all BGP neighbors, particularly eBGP peers. While it is possible to use Multiprotocol BGP (MP-BGP)[2] to carry IPv6 Network Layer Reachability Information (NLRI) over existing (or new) IPv4 BGP peering sessions, this is not recommended. Both BGP sessions MAY use the same logical circuit, or, a new port MAY be used for IPv6 (separate physical or logical connections is NOT a requirement). [removed image] This maintains independent IPv6 and IPv4 topologies, rather than tying the two together unnecessarily. It prevents black holing of IPv6 traffic in the event of a protocol outage because the IPv6 session goes down when IPv6 reachability is lost. When an IPv4 BGP session carries IPv6 NLRI, IPv6 routes are only withdrawn if IPv4 connectivity is lost. Independent BGP sessions also facilitate protocol specific maintenance because the IPv4 and IPv6 sessions don’t affect each other (e.g. IPv6 can be “bounced” without effecting IPv4 and vice verse). Finally, establishing new, IPv6-only peering creates better operational clarity. It allows IPv4 and IPv6 configuration stanzas to be independent and easily recognizable. ----8<---- Cheers, ~Chris [1] - http://bcop.nanog.org/index.php/IPv6_Peering_Transit_BCOP_v0-6 [2] - Bates, T., Chandra, R., Katz, D., and Y. Rekhter, “Multiprotocol Extensions for BGP-4”, RFC 4760, January 2007
- Jared
-- @ChrisGrundemann http://chrisgrundemann.com
Two different sessions using two different transport protocols. The v4 BGP session should have address family v6 disabled and vice versa. Exchange v4 routes over a v4 TCP connection, exchange v6 routes over a v6 TCP connection. Just treat them as independent protocols. -Laszlo On May 2, 2014, at 7:44 PM, Deepak Jain <deepak@ai.net> wrote:
Between peering routers on a dual-stacked network, is it considered best practices to have two BGP sessions (one for v4 and one for v6) between them? Or is it better to put v4 in the v6 session or v6 in the v4 session?
According to docs, obviously all of these are supported and if both sides are dual stacked, even the next-hops don't need to be overwritten.
Is there any community-approach to best practices here? Any FIB weirdness (e.g. IPv4 routes suddenly start sucking up IPv6 TCAM space, etc) that results with one solution over the other?
Thanks in advance,
DJ
Between peering routers on a dual-stacked network, is it considered best practices to have two BGP sessions (one for v4 and one for v6) between them? Or is it better to put v4 in the v6 session or v6 in the v4 session?
According to docs, obviously all of these are supported and if both sides are dual stacked, even the next-hops don't need to be overwritten.
Is there any community-approach to best practices here? Any FIB weirdness (e.g. IPv4 routes suddenly start sucking up IPv6 TCAM space, etc) that results with one solution over the other?
Thanks in advance,
DJ
For what it’s worth, my AboveNet and Cogent BGP peerings are v4 for v4 routes and v6 for v6 routes. Two separate sessions to each carrier. While I don’t have any BGP speaking IPv6 customers yet, I would set up this same way to keep the two protocols apart from each other. Best, Ryan Wilkins
Subject: Best practices IPv4/IPv6 BGP (dual stack) Date: Fri, May 02, 2014 at 07:44:33PM +0000 Quoting Deepak Jain (deepak@ai.net):
Between peering routers on a dual-stacked network, is it considered best practices to have two BGP sessions (one for v4 and one for v6) between them? Or is it better to put v4 in the v6 session or v6 in the v4 session?
Like others, yes, two sessions, v6 over v6 and v4 over v4. only the native AF is active.
According to docs, obviously all of these are supported and if both sides are dual stacked, even the next-hops don't need to be overwritten.
It works, but might produce interesting side effects. I've had to resort to it when peering between different IOS versions; but that might have been the result of fat-fingering as well.
Is there any community-approach to best practices here? Any FIB weirdness (e.g. IPv4 routes suddenly start sucking up IPv6 TCAM space, etc) that results with one solution over the other?
If having MPLS bgp peers over v6 carrying vpnv4 routes all sorts of strange things can happen. There is no standard for it; so one should not expect it to work. But the failure modes are "interesting"; I've had the next-hop for a v6-carried vpnv4 peering be the first 32 bits of the v6 next-hop, interpreted as a v4 address.. It only works if there is a v4 route to that made-up address. This is a field where v4 next-hops are essential to make things work. <rant>In that context, allocating 100.64.0.0/10 to CGN was especially un-clever... </rant> -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Xerox your lunch and file it under "sex offenders"!
On May 2, 2014, at 12:44 PM, Deepak Jain <deepak@ai.net> wrote:
Between peering routers on a dual-stacked network, is it considered best practices to have two BGP sessions (one for v4 and one for v6) between them? Or is it better to put v4 in the v6 session or v6 in the v4 session?
Separate v4 and v6 sessions are the best practice. It is possible to have a single-protocol outage in which case you either take out the other protocol unnecessarily or you black-hole traffic.
According to docs, obviously all of these are supported and if both sides are dual stacked, even the next-hops don't need to be overwritten.
Mostly true, but implementations vary and YMMV vendor to vendor and in some cases, model and/or software version to model and/or software version. Two sessions always works and unless you are somehow resource-constrained on sessions is really the simplest, easiest to manage, cleanest way to do things.
Is there any community-approach to best practices here? Any FIB weirdness (e.g. IPv4 routes suddenly start sucking up IPv6 TCAM space, etc) that results with one solution over the other?
See above for BCP. As to the rest, in my experience, the answers vary (see above). Owen
On Fri, May 2, 2014 at 10:44 PM, Deepak Jain <deepak@ai.net> wrote:
Between peering routers on a dual-stacked network, is it considered best practices to have two BGP sessions (one for v4 and one for v6) between them? Or is it better to put v4 in the v6 session or v6 in the v4 session?
According to docs, obviously all of these are supported and if both sides are dual stacked, even the next-hops don't need to be overwritten.
I've done it separately. IPv4 with IPv4, IPv6 with IPv6. From my point of view it's a cleaner configuration to have things decoupled completely: management, debugging.
Is there any community-approach to best practices here? Any FIB weirdness (e.g. IPv4 routes suddenly start sucking up IPv6 TCAM space, etc) that results with one solution over the other?
None that I've noticed.
As precaution, you should always deny ipv6 unicast on v4 sessions, and vice versa. On 5/3/2014 午後 03:01, Eugeniu Patrascu wrote:
On Fri, May 2, 2014 at 10:44 PM, Deepak Jain <deepak@ai.net> wrote:
Between peering routers on a dual-stacked network, is it considered best practices to have two BGP sessions (one for v4 and one for v6) between them? Or is it better to put v4 in the v6 session or v6 in the v4 session?
According to docs, obviously all of these are supported and if both sides are dual stacked, even the next-hops don't need to be overwritten.
I've done it separately. IPv4 with IPv4, IPv6 with IPv6. From my point of view it's a cleaner configuration to have things decoupled completely: management, debugging.
Is there any community-approach to best practices here? Any FIB weirdness (e.g. IPv4 routes suddenly start sucking up IPv6 TCAM space, etc) that results with one solution over the other?
None that I've noticed.
Sure it's a different transport protocol altogether, anyways It's interesting to see how everybody tends to separate the IPv4 and IPv6 AFs onto a different TCP sessions and still run the plethora of other AFs on the common v4 TCP session, maybe apart from couple of the big folks, who can afford running separate control-plane and edge infrastructure for some of the AFs, IPv6 AF being the first ran separately. adam
On Sat, 3 May 2014, Vitkovský Adam wrote:
Sure it's a different transport protocol altogether, anyways It's interesting to see how everybody tends to separate the IPv4 and IPv6 AFs onto a different TCP sessions and still run the plethora of other AFs on the common v4 TCP session, maybe apart from couple of the big folks, who can afford running separate control-plane and edge infrastructure for some of the AFs, IPv6 AF being the first ran separately.
I know lots of people who run vpnv4 separately from ipv4 and ipv6 (so they have 3 sessions). The ones I talked to intends to run vpnv6 separately as well. -- Mikael Abrahamsson email: swmike@swm.pp.se
Le 03/05/2014 20:23, Mikael Abrahamsson a écrit :
On Sat, 3 May 2014, Vitkovský Adam wrote:
Sure it's a different transport protocol altogether, anyways It's interesting to see how everybody tends to separate the IPv4 and IPv6 AFs onto a different TCP sessions and still run the plethora of other AFs on the common v4 TCP session, maybe apart from couple of the big folks, who can afford running separate control-plane and edge infrastructure for some of the AFs, IPv6 AF being the first ran separately.
I know lots of people who run vpnv4 separately from ipv4 and ipv6 (so they have 3 sessions). The ones I talked to intends to run vpnv6 separately as well.
Voilà ! Question is rather ``why not''?... once you decide to support services... mh
On Saturday, May 03, 2014 08:23:43 PM Mikael Abrahamsson wrote:
I know lots of people who run vpnv4 separately from ipv4 and ipv6 (so they have 3 sessions). The ones I talked to intends to run vpnv6 separately as well.
Except that VPNv6, today, relies on MPLSv4. So it's not "pure" yet. Mark.
On Saturday, May 03, 2014 07:24:24 PM Vitkovský Adam wrote:
Sure it's a different transport protocol altogether, anyways It's interesting to see how everybody tends to separate the IPv4 and IPv6 AFs onto a different TCP sessions and still run the plethora of other AFs on the common v4 TCP session, maybe apart from couple of the big folks, who can afford running separate control-plane and edge infrastructure for some of the AFs, IPv6 AF being the first ran separately.
We run separate AF's for each family-type, i.e., IPv4 separate from IPv6, separate from VPNv4 separate from BGP- based VPLS, e.t.c. Mark.
participants (13)
-
Chris Grundemann -
Deepak Jain -
Eugeniu Patrascu -
Jared Mauch -
Laszlo Hanyecz -
Mark Tinka -
Michael Hallgren -
Mikael Abrahamsson -
Måns Nilsson -
Owen DeLong -
Paul S. -
Ryan Wilkins -
Vitkovský Adam