Re: best practice for advertising peering fabric routes

[Leo Bicknell <bicknell () ufp org>]

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.

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

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail