[171494] in North American Network Operators' Group
Re: Best practices IPv4/IPv6 BGP (dual stack)
daemon@ATHENA.MIT.EDU (=?utf-8?B?TcOlbnM=?= Nilsson)
Fri May 2 16:35:08 2014
X-Original-To: nanog@nanog.org
Date: Fri, 2 May 2014 22:35:00 +0200
From: =?utf-8?B?TcOlbnM=?= Nilsson <mansaxel@besserwisser.org>
To: Deepak Jain <deepak@ai.net>
In-Reply-To: <7208d8ca20a14690acf8f34a934a68ec@AINET-EX13-S02.ainet.local>
Cc: NANOG <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
--ubuMVesmirrCclZT
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Subject: Best practices IPv4/IPv6 BGP (dual stack) Date: Fri, May 02, 2014 =
at 07:44:33PM +0000 Quoting Deepak Jain (deepak@ai.net):
>=20
> 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.=20
=20
> 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 re=
sults 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>
--=20
M=C3=A5ns Nilsson primary/secondary/besserwisser/machina
MN-1334-RIPE +46 705 989668
Xerox your lunch and file it under "sex offenders"!
--ubuMVesmirrCclZT
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iEYEARECAAYFAlNkAXMACgkQ02/pMZDM1cVrbwCfW4bHaXPbz2uBbc8UZPk9CTpp
amAAn2DItGvdwziRTt9VL49eQL2yrdkw
=ezCu
-----END PGP SIGNATURE-----
--ubuMVesmirrCclZT--
