[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it



On 26/Jan/16 08:34, Joe Maimon wrote:

>  
>
> I dont want to churn a full table any quicker then BGP timers.

You don't have to churn the whole table, you just have to churn the
(indirect) next-hop.


> And if you choose to run that ebgp loopback multihop on the same
> router, you can track routes and interfaces in realtime, to the extent
> your CP SW supports it. Choice is yours.

This feature is not unique to eBGP Multi-Hop.

Search for Next-Hop Address Tracking and/or Indirect Next-Hop.


>
> That was my point. Phy signalling is easily and often sacrificed for
> density and flexibility.

We have not had to sacrifice performance with our customers in these
types of topologies.

In the Metro, BGP sessions instantiate directly on the Ethernet switch,
so we don't lose performance there either.


>
> To return to the topic on hand, Cogent seemed to do quite well in the
> transit wars with this approach. So perhaps there is something to it.

It allowed them to use cheap switches in the Access. That makes a lot of
difference when you're undercutting the competition.

In 2016, you can still use cheap switches to keep your Access costs
down, but you don't have to sacrifice edge-based BGP routing if it's
your thing.


>
> Maybe they were not constrained by the pricing for the gear with the
> latest capabilities and capacities as their competitors were? Perhaps
> this approach enabled them to more rapidly build out and light up
> their network to catch up to their competitors, to the point that they
> now sound more like them than they do their previous selves?

Yes, and yes.

Cheap switches that you can deploy rapidly make for a good business case.


>
> Or better?

Not necessarily.

I can hold more tables because the servers have 512GB of RAM, but won't
because the code can only address 16GB max. today (some of which goes to
the code itself at boot). Work in progress, the code started at 4GB only
last year, so we'll get there.

CPU performance also still needs to get better. 12x cores in the
chassis, but because of code limitations, they aren't yet fully optimized.

Overall, still better than using a dedicated router for RR functions.


> And how do those routers get their full tables to munch on?