[f-nsp] NetIron MLX-4 vs Juniper MX240

Michal Buchtik buchtajz at borsice.net
Sat May 8 03:37:54 EDT 2010


Hi
we have MLX short time and don't need (and don't try)  these advanced 
features
but there is support for some of this.

>> Could you little bit elaborate more about the "advanced feature" which
>> is lacking in MLX but available in MX?
>>      
> Well for example, MPLS IP traffic engineering. MLX/XMR is missing nearly
> every feature that would be necessary to do IP TE in a complex service
> provider network, its MPLS is basically only useful for doing some
> simple transport services, meanwhile MX has one of the best MPLS
> implementations available anywhere. If you don't need MPLS or you don't
> need TE than it really doesn't matter to you. If on the other hand you
> run a complex network TE can save you millions in circuit costs, and
> there is absolutely no comparison between the two products.
>    
Here is snip from NetIron Configuration Guide (IronWare 5.0.0):

This chapter explains how to configure Multiprotocol Label Switching 
(MPLS) on the NetIron for
traffic engineering purposes. MPLS can be used to direct packets through 
a network over a
predetermined path of routers. Forwarding decisions in MPLS are based on 
the contents of a label
applied to the packet.
Traffic engineering is the ability to direct packets through a network 
efficiently, using information
gathered about network resources. When used as an application of MPLS, 
traffic engineering
involves creating paths that make the best use of available network 
resources, avoiding points of
congestion and making efficient use of high bandwidth interfaces. 
Packets travelling over these
paths are forwarded using MPLS.

The implementation of MPLS supports the following IETF RFCs and Internet 
Drafts.

RFC 3031 – Multiprotocol Label Switching Architecture
RFC 3032 – MPLS Label Stack Encoding
RFC 3036 – LDP Specification
RFC 2205 – Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 
Specification
RFC 2209 – Resource ReSerVation Protocol (RSVP) -- Version 1 Message 
Processing Rule
RFC 3209 – RSVP-TE
RFC 3270 – MPLS Support of Differentiated Services
RFC 4090 – Facility backup and Fast Reroute
RFC 3630 TE Extensions to OSPF v2
RFC 3784 Intermediate System to Intermediate System (IS-IS) Extensions 
for Traffic Engineering

> Another example would be complex BGP policies.
> ....
> Foundry doesn't even support route-map continue, so it is
> nearly impossible to build powerful policies using it.
>    
continue clause in route-map is supported (for BGP only).

> There are plenty of other things that may or may no tmatter to you,
> complex vlan rewrite and double-tag functionality that Foundry can't do,
>    
double-tag ? Do you mean 802.1Q-in-Q tagging  ? It's supported via 
802.1Q tag type on ports.

As I write, we don't use these features, so there may exists limitations 
I don't see.

--
Michal Buchtik



More information about the foundry-nsp mailing list