[188999] in North American Network Operators' Group
Re: Multiple VRFs from provider, IP addressing
daemon@ATHENA.MIT.EDU (Hugo Slabbert)
Thu Apr 28 23:28:09 2016
X-Original-To: nanog@nanog.org
Date: Thu, 28 Apr 2016 20:28:04 -0700
From: Hugo Slabbert <hugo@slabnet.com>
To: Craig Rivenburg <crivenburg@gmail.com>
In-Reply-To: <CABDHgxJMxuOLU6Yis3Mrv_RUO=PcX-HY4n-bzQj=krQeBq7D9g@mail.gmail.com>
Cc: nanog@nanog.org
Errors-To: nanog-bounces@nanog.org
--UFHRwCdBEJvubb2X
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Thu 2016-Apr-28 05:22:26 +0000, Craig Rivenburg <crivenburg@gmail.com> w=
rote:
>Hi Nanog...looking for some advice. I have a customer who has a large
>network...approximately 130 sites across the US. Each site is fed via two
>providers, via two Separate CE Routers. It's a L3-VPN service. Each
>provider currently provides connectivity for 6 VRFs, each over a single
>service multiplexed UNI. Ie...there are 6 dot1q interfaces facing each
>provider, each sub-interface is in its own VRF.
>
>The network is going through a redesign, and one of my tasks is to
>consolidate and "streamline" IP addressing.
>
>Looking for a sanity check...I have this idea to make every dot1q
>sub-interface facing the provider the same point-to-point subnet.
>Specifically, facing a single provider, I want to use the same /30 subnet
>for all 6 VRFs. I'd use a separate /30 for each of the CE routers per
>site, so I could go from 12 /30s to 2 per site. I should note, PE-CE
>protocol is BGP, and behind the CE routers is a small iBGP network.
>
>I know it's technically possible to configure the OPs this way and under
>normal circumstances its fine. But, in this case, there is a whole lot of
>route leaking / cross target exchanges happening between VRFs. I still
>think it's okay...but can anyone think of a a failure mode that I may not
>have? Is what I'm thinking common practice? Is there a best practice for
>this sort of thing?
6 VRFs per site, across the board, with extensive leaking between VRFs. At=
=20
the risk of second-guessing a design with very little insight into whatever=
=20
requirements are going on behind the curtain: what's the point of all of=20
those VRFs, especially if you're leaking routes back and forth fairly=20
frequently/commonly? Are you using routing policy to split security zones=
=20
or something?
For the IP addressing "streamlining": I fail to see the benefit of having=
=20
the same /30 across each dot1q sub-interface. If anything, this seems to=
=20
confuse things and complicate troubleshooting (`ping no-resolve=20
<PE-IP-for-this-site> routing-instance <VR1? or 2? erm...which one was it=
=20
again?>`). If you're dealing with apparently complex route leaking between=
=20
VRFs, I could see the fun of fat fingering your exports/imports and having=
=20
the shared touchdown /30 of the local or remote sites leak into the wrong=
=20
VRF(s).
What problem are you trying to solve? Are you short on IPs for these=20
touchdowns? Are they at a position in the topology where you could just=20
swing them over to RFC1918 space? Or drop them to /31s (since they are ptp=
=20
on dot1q sub-interfaces anyway) and half your IP allocation requirement for=
=20
the touchdowns if that's the issue?
>Thanks!
--=20
Hugo Slabbert | email, xmpp/jabber: hugo@slabnet.com
pgp key: B178313E | also on Signal
--UFHRwCdBEJvubb2X
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBCgAGBQJXItTEAAoJEFsnhBAb2KmADPoP+wbHq0nhisSTUFa3nKdwDUJ9
yb+mC675gwBijqmwLZpcU7LGUQaynOFlh0Jx9UQkFQUnK10e5OKzSWQht8STcTYW
iQhUPtBXXf43MSgfvYBoqbOOxtJpsr+zsSQEL42UGJisYpvRbuabAymxVwIG0pus
JMe0licQ431MEQ4nlUK1XmVgib8QS36yS7YN7yTft+NQldHiARaZxfFUjVko+jO5
AVg7A2L+R/hOvk7YzDbK9cNrWzvLUoK3IL+3X+fsZl90Y3mea3nSi9e1CWrYg0QP
fFRdolnZWZ6tq6Vw1gqDCeTbfdmhttZJq5SN1qGARCHGAeo1jWRH0I2YuJEAGeul
SllWkJ9JWHvpoPyZxexttmmqfZkx7pNpw1REawTE4y7eSVt4Yn3yeczfmaQwHedv
NAibhgnZEglw4D/x2VvJyG6qjocooctQlZMaHUAprf9KuPDygn+/G2AoxYMFlwx6
g5D7X3nDxqOH4VmHhtdSopg91NypICgaePDl+i2pV3oqRkNmyaDgfcVAkTi56Pj6
EpKMuBGxpIBa7EU0B8QVpG0FM4UbuNu0JrDXuS3504nZcFspJVEsKCBSCXNSJ3r1
tKRsK3g4fsxZu4WYAWKdrRIgvetraeNlaC9b2gqHgpRnn5a9Wvom6xCNpfDn6yKk
kf2EN13bpOFE5B6QCs21
=GnR6
-----END PGP SIGNATURE-----
--UFHRwCdBEJvubb2X--
