best practice for advertising peering fabric routes

Wed Jan 15 03:20:33 UTC 2014

On Jan 14, 2014, at 7:55 PM, Eric A Louie <elouie at 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.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 793 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20140114/213cb95f/attachment.sig>