3024 switches loose HTTP accessibility

Are these switches stacked, or individually managed?

Also, are there any other switches in your network - particularly from Cisco.  We have had problems with proprietary Cisco protocols such as CDP, PVST/+, and VTP causing management issues with our switches.

We have them in both configurations.  We have one stack of 6, another stack of 5, another stack of 3 and  5 (or so) individual (not stacked) switches.  We are typically using CAT5e on ports 24 & 25 for uplinks between stacks and wiring closets.  Each of the wiring closets is run back to a central wiring closet and plugged into a Dell 3024.  We have one Baystack 350T-HD switch in our main campus environment.

I've considered getting a Dell 5224 for the central wiring closet, but I have refrained until the switch issues are resolved.

I really don't think we can blame the third party Bay switch because the exact same problem occurs at almost all our sites.   (i.e. we can ping the Dell switch stack but we lose management via http.)  I have 5 remote sites that have stacks of 2 or 3 Dell 3024 switches exclusively (i.e. there is no other brand switch in these sites).   We lost HTTP connectivity to these sites as well. 

The routers at our sites are CISCO routers.  The router at our main campus is a Cisco 3350 series. I'm not sure the model at the remote sites, but it is typically a small ADSL router/modem.  I don't believe we are using any of the protocols that you have identified. 

I have one Dell 3024 in my office.  It has only my PC connected to it.  It is uplinked to another single Dell 3024 switch.  My PC is not a heavy traffic PC and it has an Intel P4 mainboard with an onboard Intel 10/100 NIC.  I have also lost http management of this switch...

We have Observer Suite that we can use to monitor the switches.  If Dell wants to work with us to help isolate the cause (i.e. extrainious traffic etc) please let me know... 

Any ideas?

Hello,

I'm also having problems with loosing conenctivity to the switches namely the 5012 and the 3024(stacked)  (management only). It varies from days to weeks. However, the switches still work without the management function. The only way I can manage the switch is through the console. We have Cisco Switches on the network but the problem occured prior to implementing the Cisco Switches. We do have Cisco Routers as well but CDP is enabled for security purposes. Any ideas?

Regards,

eflordel

I tried to contact Dell Technical Support. They advised to upgrade the firmware and so I did but no luck. Another friend of mine is having the same problem, even after 3 replacements. To correct my statement earlier, CDP is "DISABLED" and I also had problems telneting into the switches even if they are not stacked.

Barring any issues with the client system you are using not processing the java code from the web browser, I cannot honestly be sure what is causing the problem.  I would highly recommend you contact Dell Technical support for further assistance on this particular issue.

I would think traffic would be an issue, save that you are experiencing this same issue with a switch connected to just a desktop PC, and no other connection to the network (at least, that's the inference I'm drawing from your above statement.

Dell Technical Support can be reached at 1-800-822-8965, PowerConnect Option.

eflordel,

My response was directed to the first poster on this thread, regarding the loss of just HTTP management.  If you're losing all management capability, save for use of a null modem cable, then I have found the problem to be more an issue either with the amount or type of traffic crossing the switch.

I would recommend you set up a packet sniffer on one of the 10/100 ports on an affected 3024, and perform a 5-10 minute capture of everything passing through one of the uplink ports on the switch.  To do this, just use the Port Mirroring feature of the switch (this can be accessed via either telnet/terminal emulator or web console.  The source port should be the uplink to another switch or router, the destination should be the port with your traffic analyzer.  Keep in mind that while you are traffic sniffing, the system running the sniffer will be unable to access the network.

Generally, if you're seeing broadcast traffic on the switch in excess of 20%, this will cause management problems.  Usually, you can alleviate this by simply creating a separate VLAN for management traffic, and a VLAN for data traffic.  Most of the time, simply separating the two can help alleviate problems if you've got a network that has too high a percentage of broadcasts or a heavy traffic load.

I'm going to give that a shot. Thank you for your response.

eflordel

Actually my pc is the only device hooked to a 3024 switch but the 3024 is uplinked to the network, so it is not in total isolation.  But the way I expected switch traffic to work, the switch in my office would see only the traffic to and from my PC.  It wouldn't and shouldn't see the general traffic on my network's backbone.

I included this so you appreciate that even a low traffic switch is losing the HTTP management functions.

I'd be surprised if we are the only ones with this problem.  I have about 7 sites and they are all doing it.  We'll see what tech support can do.  The last time they suggesting upgrading the firmware, and that didn't fix it...

 

Thanks!

Don't forget about broadcast/multicast traffic.  Broadcast traffic floods out every port on a switch, as only routers or VLANs can actually break up a broadcast domain.

Even if you only have one device attached, if you have a high broadcast utilization on the switch, it WILL impact management.  The only odd thing is that usually, high broadcast utilization will impact all management (telnet, ping, etc.), not just the web console.

You may want to see my suggestion, above, about doing a traffic capture on the switch - if you're seeing high broadcast/multicast traffic crossing the switch, that may be the culprit.  As a guide, you generally do not want more than 20% of the total switch traffic in broadcasts/multicasts.

Broadcast or not, the switches don't have to behave this way. It is unfortunate to say that I've only experienced this type of problem from the DELL switches in my whole life. There should be more explanation to this than just the above 20% utilization or broadcast issues. Besides, on a busy network a utilization of around 10-20% is quite normal. Especially if you have VLANS and such. I'm not trying to criticize...just trying to find more answers. On another note, I will initiate a traffic capture on my switches to see where the culprit lies.

 

eflordel

Hello,

We have 3 3024's stacked and we are experiencing the same problem. What is with these things? It'll work for a while, then stop responding to HTTP requests.

DELL, this is not normal. PLEASE don't make me yank these things out for something more robust...

Hi guys, i'm new to the thread, and i've also got a Power Connect 3024 Switch.  Besides what has already been mentioned here, about the lose of http, i've seen a few other things, and I think I may have a solution, or at least an idea that may correct the problem if dell would do this for us.

I'm seeing the same, loss of http, but at the same time, on my switch here, i'm seeing loss of telnet AND console.  I was in working with the settings and it locked up on me.  I figured, go into the office next day and do the console thing.  Console not responding.  Ok, Pull power plug and reboot.  Old Windows Trick .  Was able to get into the switch.  This is my problem with it.  Also, v-lans are a different story, but then i'm probably spoiled by the other NON Dell switch I have to work with as the main unit.  For now, i've got http turned OFF, thinking it might help the telnet but it didn't.  Figured i'd leave it off since it's just one more port open to hack.  And yes, it works for a while, then quits responding.

The First thing I noticed when getting the switch was there is NO WAY TO LOG OUT when you telnet in or console in.  You telnet in, the only way out is to close your telnet session, and if you telnet in from another machine, this means closing the connection all the way through.  Same thing with console, there is no exit or logout in the firmware.  I'm thinking, and mind this is just a hunch, that if they would incorporate this into the next release, this may fix a few problems??

Oh, by the way, I was thinking this might be corrected by latest release of 6.0.4.2492 but it wasn't.  The topography of this switch is as such.....Switch plugs into main switch.  One machine is then pluged into the Dell Switch.  Yes, it's only being used for one machine until I know I can rely on this guy.

Hello,

We are also experiencing the same thing with one of our Dell  3024.  The switch becomes unpingable but still passes traffic.  This particular switch is in a small branch office with approximately 15 or so nodes but is uplinked to our corporate office via 10/Mpbs ethernet.  It's in it's own VLAN. 

What I've found is that the switch will become unreachable, even from a PC directly attached to it, for varying amounts of time.  However, if I delete the ARP entry from my PC it comes back immediately.  The ARP entry is correct and it comes right back exactly the same. 

Oxfordnet,

This is a common bug in DELL switches that I hope they have corrected by now. When I experienced this the last time, I did some major research such as opening threads, the Internet and speaking to Dell Engineers. The conclusion, setup a separate management VLAN and assign an IP Address to this switch. Do not assign an IP Address that belongs to your DATA VLAN (in most cases, the default VLAN). Another important fact would be to add some routes in your router to this Management VLAN (or subnet)...a simple static route is preferred.

Example: 

1. If your default VLAN is, 192.168.0.1 255.255.255.0

2. Assign a new Management VLAN 192.168.5.1 255.255.255.0

- This keeps the Data Traffic out therefore it does not interfere nor overload the ARP Entries on the switch. Weird but trust me, this works...and the Engineers said so . In addition, it also keeps the weasels out from poking into your configs.

3. Add a new static route in your router to 192.168.5.1 255.25.255.0 and point it to the new Management VLAN IP Address of your DELL switch.

I hope this helps

Regards,

eflordel

 

Hello,

This is exactly how we have the switch setup now.  Only one port is part of VLAN 1 and that is the port we use to manage the switch via a PC connected to it.   The LAN ip scheme is 192.168.1.x and the switch is on 192.168.100.x with subnet masks of 255.255.255.0.

We've even tried different PC's with different OS on this port.  Each time we lose connectivity we just clear the ARP table and viola! we're back in.