The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it
Joe Maimon
jmaimon at ttec.com
Tue Jan 26 06:34:47 UTC 2016
Mark Tinka wrote:
>
>
> You may want to signal failure more quickly than BGP's own timers can
> handle.
I dont want to churn a full table any quicker then BGP timers. 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.
>
> Not how I run my network. I aggregate customer ports to a Layer 2
> switch, which upstreams to the edge router for service. Router ports are
> expensive.
That was my point. Phy signalling is easily and often sacrificed for
density and flexibility.
> If your gear does not have the latest capabilities, then using what it
> has to achieve the best possible outcome is a well understood strategy.
And when you can use a design that offers advantages either way, so much
the better.
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.
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?
>
> I have virtual routers running on x86_64 servers chugging along just as
> well as the routing engines on my Juniper and Cisco edge routers.
Or better? And how do those routers get their full tables to munch on?
> Admittedly, the control planes in those routers are high-end, and I
> can't expect that everyone can afford them, but to say the brains in
> modern routers are not up to the task is simply not true.
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.
> In fact, the
> control plane on some of these boxes is not yet being fully exploited
> because code is still slowly evolving to take advantage of multi-core
> architecture, and 64-bit memory, particularly for routing processes. The
> headroom and performance on these has been phenomenal, and I can take
> that to the bank.
Are you saying that the control plane experience lags behind general
purpose computing?
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.
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.
Joe
More information about the NANOG
mailing list