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

Mark Tinka mark.tinka at seacom.mu
Tue Jan 26 07:17:19 UTC 2016



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?

From a bunch of purpose-built edge, peering and border routers.


>
> What I said is that they do not compare. Or is the control plane
> hardware specs in the latest and greatest C/J box identical to what
> you would be getting for the latest and greatest x86_64 server? My,
> times have changed.

My Juniper routers are running x86_64-based 1.8GHz Quad-Core CPU's with
16GB of RAM. 32GB RAM options are now available.

Not cheap, but with several full IPv4/IPv6 views, dozens of customers
taking full feeds, I am not struggling for grunt.

As Junos gets cleverer, those additional cores will come to life
(fingers crossed).


>
>
> Are you saying that the control plane experience lags behind general
> purpose computing?

Nope - I'm saying if you have some cash to burn, you're now in a
position where one option is not automatically better than the other.

I use servers with virtual routers for my RR's because the prospect of
sticking 1TB of RAM in a router is not yet feasible. At the same time,
I'm comfortable running BGP natively in the edge because the control
planes on the routers I have are nowhere near saturation, running tech.
2x years old now.


>
> Simply because you can afford the inflated pricing of the latest and
> greatest gear does not mean you should and it also does not mean the
> techniques available and in use to do so are in and of themselves
> suspect. No matter the temptation to do so.

Agree, but BGP routing is not the only reason we need the control planes.

There are other elements to our business that drive that spec.


>
> To a certain extent, the market for the hardware probably accounts for
> and takes advantage of any such unwillingness to engineer around cost,
> whether it is due to pure design concerns or tinged with psychological
> suggestion.

We spend if we have to, and don't if we don't have to.

For our RR deployment, for example, it was either dedicated routers for
the task, or a long-term view on servers + a hypervisor. We chose the
latter.

Mark.




More information about the NANOG mailing list