On Jan 14, 2014, at 7:55 PM, Eric A Louie <[email protected]> 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 - [email protected] - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
signature.asc
Description: Message signed with OpenPGP using GPGMail
