best practice for advertising peering fabric routes

Adam Vitkovsky adam.vitkovsky at swan.sk
Tue Feb 4 12:56:08 UTC 2014


> However, a good engineer would know there are drawbacks to next-hop-self, 
> in particular it slows convergence in a number of situations.  
> There are networks where fast convergence is more important than route 
> scaling, and thus the traditional design of BGP next-hops being edge
interfaces, 
> and edge interfaces in the IGP performs better.

Well it's not true anymore BGP PIC edge and core converges under 50ms. 
"fast external failover" and "local repair" where available long before -but
yes that's applicable only for MPLS. 


adam
-----Original Message-----
From: Leo Bicknell [mailto:bicknell at ufp.org] 
Sent: Wednesday, January 15, 2014 3:18 PM
To: Dobbins, Roland
Cc: NANOG list
Subject: Re: best practice for advertising peering fabric routes


On Jan 15, 2014, at 12:02 AM, "Dobbins, Roland" <rdobbins at arbor.net> wrote:

> Again, folks, this isn't theoretical.  When the particular attacks cited
in this thread were taking place, I was astonished that the IXP
infrastructure routes were even being advertised outside of the IXP network,
because of these very issues.

I know a lot of people push next-hop-self, and if you're a large ISP with
thousands of BGP customers is pretty much required to scale.

However, a good engineer would know there are drawbacks to next-hop-self, in
particular it slows convergence in a number of situations.  There are
networks where fast convergence is more important than route scaling, and
thus the traditional design of BGP next-hops being edge interfaces, and edge
interfaces in the IGP performs better.

By attempting to force IX participants to not put the route in IGP, those IX
participants are collectively deciding on a slower converging network for
everyone.  I don't like a world where connecting to an exchange point forces
a particular network design on participants.

> IXPs are not the problem when it comes to breaking PMTU-D.  The problem is
largely with enterprise networks, and with 'security' vendors who've
propagated the myth that simply blocking all ICMP somehow increases
'security'.

That's some circular reasoning.

Networks won't 9K peer at exchange points for a number of reasons, including
PMTU-D discovery issues.

Since there are virtual no 9K peering at exchange points, PMTU-D is a
non-issue.

Maybe if IXP design didn't break PMTU-D it would help attract more 9K peers,
or there might even be a future where 9K peering was required?

This whole problem smacks to me of exchange points that are "too big to
fail".  Since some of these exchanges are so big, everyone else must bend to
their needs.  I think the world would be a better place if some of these
were broken up into smaller exchanges and they imposed less restrictions on
their participants.

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










More information about the NANOG mailing list