[j-nsp] Why should I *not* buy an MX?

Richard A Steenbergen ras at e-gerbil.net
Sat Nov 8 17:15:21 EST 2008


On Sat, Nov 08, 2008 at 04:12:37PM -0500, Keegan.Holley at sungard.com wrote:
> Technically all routers are switches (or groups of switches in the case of 
> GSR's and M series, etc).  Unless you are doing process switching (not 
> recommended) all the routing function really does is generate and cache a 
> series of forwarding destinations for the switching ASIC's.  Once this is 
> done all the packets are switched the same way they are in layer 2 
> devices.  There are some functions that come along with L3 intelligence 
> such as ACL's,/FW filters and QOS but even here the actual work is done by 
> the switching ASIC's, but this is all semantics anyway. 

Thats clearly not what he means... The distinction here is that almost
all of the competetive platforms (Cisco 6500/7600, Foundry, Force10,
etc) are actually layer 2 platforms which have been "hacked" to do
routing. This works fine most of the time and for most use cases, but 
there are several inherient disadvantages of doing it this way.

For starters, you've got the previously mentioned global VLAN
significance, which limits your vlan id flexibility significantly, as
well as the scale of the box for some applications. The classic L2
platforms also don't offer much in the way of vlan rewriting or stacking
functionality, because what little they do offer is quite simply the
most that can be accomplished with that architecture. And of course,
there is a limit to the amount of data that you can fit into a 72 or 144
bit TCAM entry, which limits what you can do with firewall filtering and
QoS. You can see these limitation quite clearly in things like the
6500/7600, where if you want to ACL an IPv6 address + layer 4 port
matching you have to restrict your v6 address to only 88 bits to fit the
lookup into a 144-bit TCAM entry. And of course there are failure mode
considerations. On a hacked up L2 platform, what you're really doing to
"route" is secretly stealing a vlan (from a very limited 4096 entry
pool) for every L3 port, but the default behavior of the architecture 
itself is to be a switch and to flood packets across vlans. This means 
that in the event of a configuration mistake or software bug, it is very 
easy to get packets leaking across their routed boundries, sometimes 
with disasterous (loopy) consequences (ask anyone who owns a Foundry how 
often they leak broadcasts across routed ports :P).

The MX platform on the other hand, is actually a router that has been
hacked up to do switching. The forwarding architecture is very similar
to a T-series, with a newer consolidated and shrunk-down version of the
same forwarding asics (I-chip instead of separate LMNR chips on
T-series). There are none of the design limitations of a CAM 
architecture that restrict numbers of vlans, and no mechanisms for 
packets to easily leak across their boundries and create loops. There 
are significantly better limitations on what you can do with QoS, what 
things you can match in firewall, and how scalable the platform is for 
things like martini handoffs. To compare the MX to those other platforms 
is purely an excercise in marketing, not technical design. The MX is 
actually more capable than T-series in many areas, as they bumped up a 
lot of the internal resource sources in the newer I-chip.

If you want a Juniper product that has the same limitations as a
traditional hacked up L2 switching CAM platform, look at the EX. You'll
quickly start to see the same limitations I mentioned above. Don't think
of the MX as a switch, think of it as a better T-series without SONET or
multichassis support for 1/4 the price. What I tell people is this: If
you run a complex network which can make use of the features of the MX
then there is absolutely no comparison to any other "switch" platform. 
If you run a very simple network and don't know or care why these would
be advantages for you, then Foundry MLX/XMR or Cisco 6500/7600 is 
probably a better choice for you.

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)


More information about the juniper-nsp mailing list