[172761] in North American Network Operators' Group
Re: Best practice for BGP session/ full routes for customer
daemon@ATHENA.MIT.EDU (Mark Tinka)
Tue Jul 8 16:56:49 2014
X-Original-To: nanog@nanog.org
From: Mark Tinka <mark.tinka@seacom.mu>
To: nanog@nanog.org
Date: Tue, 8 Jul 2014 22:56:26 +0200
In-Reply-To: <CAJ0+aXbNAj63WFjePB4DaK3OX8RkVAgnuFwdUbEw98A8jkwPKQ@mail.gmail.com>
Reply-To: mark.tinka@seacom.mu
Errors-To: nanog-bounces@nanog.org
--nextPart1440646.dXUIafOD7i
Content-Type: Text/Plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
On Monday, July 07, 2014 08:33:12 PM Anurag Bhatia wrote:
=20
> In this scenario what is best practice for giving full
> table to downstream?
In our case, we have three types of edge routers; Juniper=20
MX480 + Cisco ASR1006, and the Cisco ME3600X.
=46or the MX480 and ASR1006 have no problems supporting a full=20
table. So customers peer natively.
The ME3600X is a small switch, that supports only up to=20
24,000 IPv4 and 5,000 IPv6 FIB entries. However, Cisco have=20
a feature called BGP Selective Download:
http://tinyurl.com/nodnmct
Using BGP-SD, we can send a full BGP table from our route=20
reflectors to our ME3600X switches, without worrying about=20
them entering the FIB, i.e., they are held only in memory.=20
The beauty - you can advertise these routes to customers=20
natively, without clunky eBGP Multi-Hop sessions running=20
rampant.
Of course, with BGP-SD, you still need a 0/0 + ::/0 route in=20
the FIB for traffic to flow from your customers upstream,=20
but that is fine as it's only two entries :-).
If your system supports a BGP-SD-type implementation, I'd=20
recommend it, provided you have sufficient control plane=20
memory.
Cheers,
Mark.
--nextPart1440646.dXUIafOD7i
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
iQIcBAABAgAGBQJTvFr6AAoJEGcZuYTeKm+GxeYP/0dY8P4E8xURGplWIvIfKa/m
IpbqdVkUdhJ14LVPlOosdLyqXymVNIOr5OUv1f2JVO/FEd8Ga2iJid6s07aKlP74
4GpWrujtM9mSU8Q6kV3zNK++sU+z5PAV2g3zbn3GMyCw39MFcjbPMCSG21L1TVRd
mS97EBj44hYYoxI8Dd9RYOcZd/gH2rBM1IfBSP+7BeXweXeBum2dYq5qNjTUf49X
ckS2qrPX2+zIMw0pL+juSxxTdxNMDra65L4p38PO1b/UuvjGcoaYhvAD+kSf25Ai
AoMv8uqb4jlMZEYqj8T4tXy3v/GPCbKy6Ar8tQHp5Zt4YCU+Av5wRHrcOEqOuwaY
2Iy2cGfe3wnOP/P54Kj2eles5cYd89QJwlo6RYFtJJQFQvVdr30ItAIgxFzM02oz
GdNtEMkgm9kSO3U1zxQQv6CcCaFora5z2VcP4EJO7ZF8GmWT0oNHGbeHZb66CwvU
IGfccvlc91Z3XD6MJcUcCanfAZ8uTv/uluuZTSj8Ph23QLr9IGJp6+Jx2vnUVxuK
mfE96FFkMMtXQmVvc0NzRVLZG9s5j4AKjNAhHTsH+wAhDLS9RAweVevgbfCJPY6N
F+xqK72jm/XKw/GKzuqQL9yvwfBOr1KiE5Lr5nh9n/8eMhm1ATgKS3BKdlqfgH30
wSsxR4O2rKNVLGqQPS8Q
=5Ws/
-----END PGP SIGNATURE-----
--nextPart1440646.dXUIafOD7i--
