Upgrade Path Options from 6500 SUP720-3BXL for Edge Routing

Wed Jul 30 13:43:33 UTC 2014

On (2014-07-30 08:06 -0500), Jimmy Hess wrote:

> Keep in mind most of the MX series makes the 6500  look like a 5 port
> linksys home router,  when it comes to carrying around and managing
> large BGP tables;  both in terms of prefix capacity, speed,  the
> policy/filtering/configuration management functionality of the OS,
> and how they will take the  route update "beating"  during  setup of
> new multiple BGP sessions...
> 
> The SUP2T  is   about  a 100% increase in TCAM size,  but  still
> pretty limited  in terms of  system resources.
> 
> You can also "protect" your investment if appropriate by taking  this
> late 1990s gear off your BGP edge, or otherwise recruiting it for a
> role  which it is more suited for in this day and age, where  it is
> not handling full tables and thus the feeble amount of FIB size, CPU,
> memory  are  no potential hinderance now or on the next 10 years.

These seem cute anecdotes but I'm not sure how appropriate they are.

CAT6880 is XEON control-plane, and if we compare MX80 and RSP720, where RSP720
has slightly lower performance CPU, RSP720 out-performs MX80 (and MX104) in
BGP convergence and BGP scale.
Certainly if you compare SUP720 to XEON MX960, your anecdote is accurate.

JunOS is architecturally quite similar to IOS-XE, single fat process (iosd,
rpd) doing all the relevant work, running on modern control-plane (linux,
freebsd). One advantage to iosd is, that it's actually multithreaded unlike
rpd.

Obviously Sup2T/6880 2M FIB is limited, but what is JNPR MX scale? Trio has
256MB RLDRAM for everything, looking at my MX IPv4 FIB memory consumption
divided by entry size, it pegs IPv4 entry to 77B (seems massive), which would
translate to 3.5M IPv4 FIB upper bound, if nothing else is there.
Realistically, I don't think JNPR promises anywhere near this. So the FIB
scale may be pretty similar in both.

So I don't think FIB, control-plane or software are selling-points here. Where
MX shines, is deep services, with CAT you have relatively dumb ASIC, while MX
is capable for very deep services with its NPU.

If you can reuse existing LC and skill investment while living with limited
forwarding-plane functionality offered, it seems entirely sensible solution,
and in no way more '90s technology' than MX.

If you need deep services, of course it's wrong box, then MX or ASR9k is what
you should be looking at.

-- 
  ++ytti