Re: Force10 E300 vs. Juniper MX480

["Chris Heighway" <heighway () gmail com>]

I worked with many Foundry models for more than 4 years in the past and
never had any real serious issues. They used to be a bit loud but other than
that they are very easy to manage solid devices. Another great thing with
Foundry (again in my experience) is the support. Any time I ever had a real
issue one of their SE's would be on site quickly and with the knowledge
needed to fix the problem.

_Chric

On Fri, Jul 18, 2008 at 9:52 AM, Chris Marlatt <cmarlatt () rxsec com> wrote:

>  Keith O'neill wrote:
>
> > Force 10 is fine. I do suggest he go with the dual cam cards over the
> > regular cards. I am not sure what Chris is talking about but I have used
> > Force 10 for a long time, E, C and S series and have found it very stable.
> > It will do everything you want and then some. The E300 is a good bang for
> > the buck. Sure Foundry might be cheaper but I hear more complaining about
> > Foundry than any other platform.
> >
> > Chris you want to share what issues you have seen with Force 10.
> >
> > Keith
> >
> > ----- Original Message -----
> > From: "Chris Marlatt" <cmarlatt () rxsec com>
> > To: "Joe Abley" <jabley () ca afilias info>
> > Cc: "nanog" <nanog () merit edu>
> > Sent: Friday, July 18, 2008 7:43:33 AM (GMT-0500) America/New_York
> > Subject: Re: Force10 E300 vs. Juniper MX480
> >
> > Joe Abley wrote:
> >
> > > Hi all,
> > >
> > > An acquaintance who runs an ISP with an M7i on its border is looking to
> > > upgrade, because the M7i is starting to creak from all the flesh-tone MPEGs
> > > his customers are sharing. (How times have changed. Back when I was chasing
> > > packets, it was flesh-tone JPEGs.)
> > >
> > > He's looking at the MX480 and the E300.
> > >
> > > The MX480 is attractive because the M7i has been stable as a rock, and
> > > he's familiar with JUNOS.
> > >
> > > The E300 is attractive because it's half the price of the MX480, and has
> > > the potential to hold layer-2 cards as well as layer-3 ports which makes the
> > > price per port much more reasonable than the MX480. But he has no experience
> > > with Force10 at any ISO layer higher than 2.
> > >
> > > He doesn't have any exotic requirements beyond OSPF, OSPFv3, BGP, IP and
> > > IPv6. There's no MPLS in the picture, for example. However, he's going to
> > > want four or five full tables plus a moderate load of peering routes in
> > > there. And maybe VRRP.
> > >
> > > Thoughts from people who have tried one or the other, or both? Or who
> > > have faced this kind of problem, and came up with a different answer?
> > >
> > > Feel free to send mail off-list; I can summarise if there is interest.
> > >
> > >
> > > Joe
> > I would avoid Force10 if at all possible. In the network I managed I've
> > had some fairly surprising stability problems with their S series switches
> > and feature problems (or lack there of) on their E series. Things you kind
> > of scratch your head at and wonder what they were thinking. Juniper on the
> > other hand is indeed a bit pricier but quite a stable platform. If he has to
> > look at alternatives I would suggest Foundry, either the RX-8, MLX-8, or
> > XMR-8000 (depending on requirements) for comparable models to the MX480.
> >
> > Regards,
> >
> >        Chris
> Considering I just had another issue pop up sure - I'd be glad to at this
> point.
>
> As provided to another member who contacted me off list:
> ==========================================================
> The S series problems were the worst - customer facing issues. <--snip-->.
> The list is noted in SFTOS and FTOS. Our design required layer 3 code on the
> S50N which "caused" some of these errors to present themselves:
>
> - SFTOS: Limit of 8 ACL's (total ACL line count). Secondary assignments on
> the switch were "unprotected".
>
> - SFTOS: OSPF required a specific ACL to form an adjacency even with a
> "default allow".
>
> - SFTOS: If an uplink went down with OSPF running (ECMP) when the link was
> brought back up the OSPF adjacency would only form half way but would add a
> route. A 50/50 chance of success was the result.
>
> - SFTOS: A "Transient Parity Error" crashed one of the S50's in production.
> No known cause.
>
> - FTOS: The switch would lock during certain ARP operations (i.e. port
> flap). A hard reboot was necessary to recover the switch. <--snip-->
>
> - FTOS: Random reboots preceded by "Low memory" errors. Our design would
> not / could not have consumed all the switch memory.
>
> - FTOS: An upgrade from SFTOS to FTOS changes all the SNMP interface
> indexes causing lots of internal software to no longer be able to poll
> switch ports or monitor accurately.
>
> - FTOS: Hard lock of the switch after an STP root change. The root change
> was not seen on any other switches (i.e. another bug in the S50 code) and
> there were no events that should have caused a change in the topology.
>
> The E series has more stable but like I said lacking some features. The
> most notable is the inability to do "normal" PBR. Pretty much any BGP
> attribute can't be used to build a policy. We were forced to dedicate vlans
> to certain policies as they could only match the traffic via an interface.
>
> A minor annoyance is the timing for the management cpu causing ping times
> to look as though there is something wrong with the router. There's a paper
> out there somewhere explaining the cause for this and it has to do with the
> polling cycles of the board.
>
> A snippet of a ping to a routing interface:
> 64 bytes from xxx.xxx.xxx.xxx: icmp_seq=4 ttl=252 time=0.640 ms
> 64 bytes from xxx.xxx.xxx.xxx: icmp_seq=5 ttl=252 time=5.376 ms
> 64 bytes from xxx.xxx.xxx.xxx: icmp_seq=6 ttl=252 time=12.170 ms
> 64 bytes from xxx.xxx.xxx.xxx: icmp_seq=7 ttl=252 time=1.106 ms
> 64 bytes from xxx.xxx.xxx.xxx: icmp_seq=8 ttl=252 time=8.089 ms
> 64 bytes from xxx.xxx.xxx.xxx: icmp_seq=9 ttl=252 time=0.715 ms
> 64 bytes from xxx.xxx.xxx.xxx: icmp_seq=10 ttl=252 time=3.758 ms
> 64 bytes from xxx.xxx.xxx.xxx: icmp_seq=11 ttl=252 time=10.636 ms
>
> The only other problem we've had with the E series is a BGP failure. The
> device failed over to its standby management module so the impact was
> limited. I don't hold that too much against them as I realize that no vendor
> is perfect. However the vast problems we've had with the S series and minor
> problems with the E bring into question the stability and unseen bugs with
> other software. <--snip-->
>
> Hopefully the above is helpful. I'm sure my experience isn't unique or the
> norm. If everyone was having issues similar to mine they'd be out of
> business.
> ==========================================================
>
> The most recent problem occuring today:
> %FIB6-2-FIB6_HW_WRITE_ERROR: Failed to write entry into Host table.
>
> Had to clear the fib in order to get communication with that host back up.
>
> Of all the vendors I've worked with this is by _far_ the longest list of
> issues I've ever come across. I'm glad that you're having better success
> than I am. Believe me I wish I was in the same boat.
>
> We've been using Foundry for a much longer period of time than we have
> Force10 and in comparison I personally no longer consider them comparable
> products.
>
> Regards,
>
>        Chris