[168177] in North American Network Operators' Group
Re: best practice for advertising peering fabric routes
daemon@ATHENA.MIT.EDU (Leo Bicknell)
Tue Jan 14 22:21:55 2014
From: Leo Bicknell <bicknell@ufp.org>
In-Reply-To: <1389750938.95176.YahooMailNeo@web181605.mail.ne1.yahoo.com>
Date: Tue, 14 Jan 2014 21:20:33 -0600
To: Eric A Louie <elouie@yahoo.com>
Cc: NANOG <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--Apple-Mail=_4B5CBD46-948A-47F7-8158-30EC0CB984FD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=iso-8859-1
On Jan 14, 2014, at 7:55 PM, Eric A Louie <elouie@yahoo.com> wrote:
> I have a connection to a peering fabric and I'm not distributing the =
peering fabric routes into my network.
There's a two part problem lurking.
Problem #1 is how you handle your internal routing. Most of the "big =
boys" will next-hop-self in iBGP all external routes. However depending =
on the size and configuration of your network there may be advantages to =
not using next-hop-self, or just putting it in your IGP. Basically, you =
should be doing the same thing you do for a /30 from a peer or transit =
provider in your network. There is one thing special about an exchange =
point though, for security reasons you probably want to add it to your =
"never accept" routing filter from peers/customers/transit providers. =
You don't need someone injecting a couple of more specifics to mess with =
your routing.
Problem #2 is your customers. If you have customers that may operate =
default free, and they use one of the traceroute tools that not only =
finds the route, but then continues to probe it (like MTR, or Visual =
Traceroute) there can be an issue. The initial traceroute probe may =
return an IP on the exchange of your peer's router, but then when they =
subsequently source ICMP Ping to that IP there will be no route in their =
network, and it will simply never respond. Some call this a feature, =
some call this a problem. There is also an extremely rare problem where =
the far end of the peering exchange steps down MTU, and thus PMTU =
discovery is invoked, but your customers use Unicast RPF. Since the =
exchange LAN isn't in their table, Unicast RPF may drop the PMTU =
packet-too-big message, causing a timeout.
If your customers have a default to you, all is well. However if they =
have a default to someone else, and take a table from you to selectively =
override the same problem can occur for any routes they select through =
you that also traverse the exchange.
IMHO the best fix for #2 is that the exchange have an ASN, and announce =
the exchange LAN from that ASN, typically via the route server. You =
should then peer with the route server to pick up that network. That =
makes the announcement consistent, and makes it clear who operates that =
network, and your customers can then access it. Many exchanges do not =
do this, and then the next best solution might be to originate it from =
your ASN and announce it to your customers only, with no-export set on =
the way out.
Various people will no doubt chime in and tell you the last two =
suggestions are either excellent wonderful and the worst idea ever. =
Safe to say I know of networks doing both and the world has not ended. =
YMMV, some assembly required, batteries not included, actual conditions =
may affect product performance, do not taunt the happy fun ball, and =
consult a doctor if your network is up for more than four hours.
--=20
Leo Bicknell - bicknell@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
--Apple-Mail=_4B5CBD46-948A-47F7-8158-30EC0CB984FD
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
iQIVAwUBUtX+hLN3O8aJIdTMAQKjrQ//VrvTAQ32mGw2SpAQVLsCcjOcBV98HbrG
aHbXPTb+WgCEYXXhr2PlhHql+iiT0MNOTqDdLZ/j4DmNGBYMG0yQdvTGVjP+n8p7
fZocUoTCECMQ35EqIsSdVvEJDKK11C5WHc4mIa6pHrDh5ivyqN+4D1sK+v6Yo1X+
LksqJzpmo9L9NVg2vvCaB9ZpRL9WvN/Ukv42PVNpmM65T+yc/f9niChshFuZ6JZT
7OPuopHkwMb9RwlqmenZcb4fa10CAVlyfrYVLF/2yf5/TlAscHkZkSlQKDqtAGcX
E9yEfJIniNy0cbd8qk+GF2k9ZBFoD7FNxNUgqETzGvf2EvPh+7xx8msmA/jHQ/e8
uFpdt7yWD1qGt/wBMLZlRMJQg7aiySZ6CEntfkVRDzFz56H6q3jcfFcNZSuzxdd9
pjq2XtxhHXUJ2SxQfv9ahtYbPNePwQvqAyJ6UqL+VkTmaMWmCrn2qGflWsP/satM
Pcr2GFeTauYS47AE9dKW8hkyi36E994edrCSMAtwzsy4QkFDTuCDQLBYFuWP6eii
uzYrvdV9Q2oPG5VJYcEex8suMm81QGP3thEPSAi2w8fKmpyhT52xVKQVS1AQmN+F
U9z8nqqVA6v1c4ocXm8pZSOVxd7WszOgcNc1fPFguOtP96i56gpH5X1tmJI6OEMD
l4KvrG/fiCU=
=q32k
-----END PGP SIGNATURE-----
--Apple-Mail=_4B5CBD46-948A-47F7-8158-30EC0CB984FD--
