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
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
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
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
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>
>
> 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.
This is the key point I believe: No protocol fate sharing!
From the draft BCOP on this topic[1]:
----8<----
Establish new, IPv6-Only peering sessions parallel to existing IPv4
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
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
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.
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
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
Except that VPNv6, today, relies on MPLSv4. So it's not
"pure" yet.
Mark.
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.