[168178] in North American Network Operators' Group
Re: best practice for advertising peering fabric routes
daemon@ATHENA.MIT.EDU (Patrick W. Gilmore)
Tue Jan 14 22:35:52 2014
From: "Patrick W. Gilmore" <patrick@ianai.net>
In-Reply-To: <1DE560B4-092A-4C10-B3B4-08386F5B400A@ufp.org>
Date: Tue, 14 Jan 2014 22:35:31 -0500
To: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--Apple-Mail=_4E8128D9-A266-4A63-8C25-9F9C62A6908B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=iso-8859-1
On Jan 14, 2014, at 22:20 , Leo Bicknell <bicknell@ufp.org> wrote:
> On Jan 14, 2014, at 7:55 PM, Eric A Louie <elouie@yahoo.com> wrote:
>=20
>> I have a connection to a peering fabric and I'm not distributing the =
peering fabric routes into my network.
>=20
> There's a two part problem lurking.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
I've known Leo for .. well, let's just say a long time. And I have great =
respect for his networking abilities. But I fall into the second camp. =
As someone who owns & operates an IXP, and is on the board of a couple =
more, and helped start even more, I'm going to stick to my guns here.
As for knowing networks that do both, blah, blah, blah. I know lots of =
networks that allow spam, don't configure BCP38, have abusable name or =
NTP servers, etc. and the world has not come to an end. Doesn't mean you =
should. Lame excuse, Leo, and beneath you to even go there.
NEVER EVER EVER put an IX prefix into BGP, IGP, or even static route. An =
IXP LAN should not be reachable from any device not directly attached to =
that LAN. Period.
If for no better reason, how about because it is not your prefix, and =
chances are the IXP does not want you to use the prefix. In fact, I =
challenge you to find a major IXP route server which is announcing the =
IXP block.
But because this is a teaching list, let's go through the problems Leo =
mentions. Anyone who steps down MTU on an IXP is far too broken to worry =
about your customer having RFP and not getting PMTU. Again, I challenge =
you to find someone doing this today, their network would be close to =
unusable. As for traceroute .... Seriously? You want to increase =
breakage on the Internet because it might cause 3 stars in a traceroute? =
Puh-LEEEZE. Sorry, neither of those pass the sniff test, IMHO.
So Just Don't Do It. Setting next-hop-self is not just for "big guys", =
the crappiest, tiniest router that can do peering at an IXP has the same =
ability. Use it. Stop putting me and every one of your peers in danger =
because you are lazy.
--=20
TTFN,
patrick
--Apple-Mail=_4E8128D9-A266-4A63-8C25-9F9C62A6908B
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-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http://gpgtools.org
iQEcBAEBAgAGBQJS1gIDAAoJEHZX8udmu5TXYhMIALYLiIfIlIOdRuyW7y4NeMa4
AXfBRLCxXzDPFaf1DYAUxpSh6TnBqcaXYzZfv2R+vz1llmjV94sQET9kinvYEq36
+lcNQe4PNuD6SOcFM/XVKge6M4nNloPu+kG38NvlyRHZ6fh6oQ6QZciX7azpJhbr
w0Kok5JP5T6eQ8mZIDlv0pg/Uw00FpGDC0069uBZ1a5QorzUudB+56bMA42nJt8f
Cq3jskRXYiGPMGmn8YoEzhNNOJ6sQDRkSfVnC8+SrIdqLhfflC+e/4w9eCLBkhxj
2pAZty3mQ4X/zqyuhzMWcrLcrBJJ8KK6cHUlsC8wQbTbKSuZ0yTykdEpB9P0HLI=
=iIk2
-----END PGP SIGNATURE-----
--Apple-Mail=_4E8128D9-A266-4A63-8C25-9F9C62A6908B--
