Technical > Photos of Broadband gear > New Switch Gear / Various Goodies

reply to calvinj

Re: New Switch Gear / Various Goodies

I've got to say I'm unhappy with the juniper EX 4200's (bought in mid 2010)
in the first few weeks they crashed repeatedly, one of the times required loading new software via serial, the last "solution" has been to upgrade to the latest software just to make them stable and yet the web interface and the telnet interface still crash (atleast their main use, ie ethernet switching, has been stable now)

its a sad thing with some crappy netgears out do a $30,000 switch stack.

reply to sk1939
I think the CLI is pretty powerful on the ones that we have (3500, 5400, 6200). About the only thing I use the gui for anymore is to look at address tables.

We haven't had speed issues with ours, but then again we are a small manufacturing company of about 50 total users

reply to DarkLogix
I've heard that, we mostly use Cisco and HP for switching fortunately. Some of Juniper's latest issues have me questioning their reliability, like that bad BGP/OS update that brought down Level 3 (»www.truedigitalsecurity.com/blog···nternet/).

It is isn't it? I personally prefer Brocade over Juniper, but alas that's not where the corporate focus is.

reply to calvinj
I remember the last time I used it, it lacked the level of detail that I was used to, it was clearly intended to be web managed. Again, maybe they changed it.

True. One of the focuses for the client that had the PowerConnects was pushing wire speed gigabit to the desktop for voice and data. That was also around 2008, so quite some time has passed since then.

reply to sk1939
I prefer cisco over juniper but higher ups wanted juniper even though a cisco 3750G (or X which ever was current at the time) would have saved over 1000 per switch and gotten all the same features (poe, dual power supplies(without having to order the 2nd as another line item), 48gig ports, 2 10gig capable ports, ect)

the juniper WXC (wan accelarator actually slows the wan to a crawl so its basicly fully disabled)

the only thing that was good was that it allowed us to get rid of the netgear stack (but other than that no improvment)

I know, but the 3 switch netgear stack (btw I do mean stack they had a stacking cable type link) was far more reliable than the junipers

messing with vlan configs on them was total crap and super easy to forget to hold ctrl and accedently clear a part of the config (so we pretty much didn't use vlans on the netgears)

reply to Paulg
Netgear is the devil. We tried to setup one the other night for a buddy and it just would not work to save it's life. I also have one at home in my lab and what a cluster fuck that is. Using the GUI don't bother.. Using the CLI.. Painful. Makes me want to go out and cause gratuitous violence

You got it wrong
Juniper is the devil
Netgear is his sidekick

For switches maybe.

Juniper router's I've seen so far have only been slightly less bad
the juniper router hasn't crached taking down the office I'm in yet, but it has at another office (weekly)

That's what I figured. Juniper routers are used on a large scale though (for better or worse) since they have higher throughput that Cisco's equipment, and are cheaper in some cases.

well I'll give them cheaper they sure are built dirt cheap
the lack of throughput might be more of higher ups picking a dumb network design (they claim it'll allow them to more easily lock down the network)

ok so the switches are layer3 switches capable of doing great (in theory) intervlan routing right? well forget that the SRX is doing the inter vlan routing

so we're limited on traffic between vlans, all the computers are connected to the switches at gig but so is the router and the router is doing the inter vlan routing, and of course the SRX is also doing the firewall/nat and a vpn to a remote site, so its at fairly high load all the time

Well the nice thing is that the SRX's can handle it, the Juniper (and Cisco) routers get bogged down with lots of services; NAT and Firewall/IDS especially are killers.

Previously we had a cisco 1711 that handled it flawlessly, of course that was a flat network so it didn't have any intervlan routing

and atleast due to the topology data from one vlan to another is greatly limited by the srx, and its at near max load 24/7 and the srx is crazy bogged down

luckily not many send large files offten to the fileserver as that will bog the SRX to a crawl and slow all other traffic

really it would be way better if the EX4200's did the inter-vlan routing

1711...that's a blast from the past. I still have a 1720 floating around somewhere.

That's not surprising, especially if your pushing gigabit to the SRX (depending on the model). The lack of large files helps; we image from the servers so that wouldn't work for us.

It would, which is why the 4506's/3750's handle the inter-vlan routing for most applications.

Ya, oh well higher ups want the SRX to do intervlan routing

if it were up to me I'd have the 4200EX (ok really I'd have a 3750X) do the intervlan routing

and I'd have nic teaming setup on all the servers, as well as on the ESXi hosts

at home I have a NME-16ES-1G-P doing my intervlan routing and its linked to my 2960G via gig (though if I had a 3750G at home I'd let it take over, or if it didn't have rudundant power I'd get the stackwise etherswitch) (I wish I could justify buying a NME-XD-48ES-2S-P to replace my NME-16ES-1G-P)

It makes sense rather than taxing the router, but they should migrate it to the switch realistically, since CEF can handle routing much easier than a process-based router.

That isn't set up all ready? I think that nic load balancing is one of the most important things on a mission critical server.

I have it set up a little differently at home. I have a 2811 that does NAT and basic firewall, which feeds a Layer 2 switch. Inter-vlan routing is handled in Hyper-V by Vyatta (previously handled by Nexus 1000V). I don't use my Layer 3 switches for anything other than as a test bed, due to noise and power requirements (not to mention lack of gigabit ports).