North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Force10 E300 vs. Juniper MX480
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 <[email protected]> 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" <[email protected]> >> To: "Joe Abley" <[email protected]> >> Cc: "nanog" <[email protected]> >> 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 > >
|