SGE2010 stack - http (80) to certain devices not working but port 80 responds to paping

[jacqueline.allen]

We have had an interesting situation occur at least twice on a stack of SGE2010 switches. It appears that port 80 on certain devices attached to teh switch will respond to paping on port 80, but will not allow access to the web page information. If the device is moved off of the stack to a 3Com switch which is uplinked to the stack, everything works fine.  This happened once before that I am aware of and reloading the entire stack resolved the problem until this just occurred again.Also, if the device also supports 443, the access to port 443 works fine but not port 80. Does anyone have any ideas what might ne going on? Nothing should be blocking port 80 as there is no firewall or ACLs.. The devices are within the same IP subnet. ANy assistance would be appreciated. Thank you.

[David Hornstein]

Hi Jacqueline,

I am not a Post Sales professional, but a pre-sales Systems Engineer at Cisco, but you are correct this is a interesting observation..

I guess you run the paping test,  when you have a webpage problem.

Resetting the switch will reset the webservers ethernet interface, so not a great conclusive test

The only thing that I question is that the ethernet interface of the web server has been reset when you unplugged the ethernet cable and then  plugged it into the old  3COM switch..not a great test.

Next time you can't access the webserver via a HTTP session, grab a wireshark capture of the Webpage request.  It would be interesting to see a capture of a good response  and a second capture wehn the web server doesn't respond for comparitive reasons.

But, it seems,  that if there is a issue, this hopefully can be looked at by our good  folks at Small Business Support Center (SBSC). I'm guessing they could check out the wireshark capture  and check out the switch port  interface statistics.

Again I am not a post sales support professional , by my thought is,

• grab a good exchange now,  for comparitive reasons with a web server in question.

• when the problem next occurs, whereby you can't access a webpage, grab the wireshark capture by mirroring the web servers ethernet port, and then open a case with SBSC.

http://www.cisco.com/en/US/support/tsd_cisco_small_business_support_center_contacts.html

I will monitor this posting with interest.

regards Dave

[jacqueline.allen]

We are working on getting packet captures of the web server working in the 3Com switch and not working on the Cisco stack. The server has been moved back to the Cisco stack from the 3Com switch and is still not working. So I don't think the interface on the server is at issue. Also, in the past when this occurred with the http interface on printers, resetting the printers did not resolve the issue. We will open a ticket with the SBSC, but I wanted to post additional information for anyone else who may be experiencing this issue. Thank you.

[jacqueline.allen]

The packet capture from the Cisco stack revealed unicast flooding which may be cIontributing to the problem.  am working to determine the cause of the unciast flooding.

[jacqueline.allen]

The switch stack is definitely having an issue with unicast flooding. Periodic flooding was observed due to STP topology changes which resolved when once the mac addresses were relearned and placed in the CAM. However, at some point something happens to the switch and it stops adding MAC addresses to the CAM. If I manually add the enties, we can then access the device but the unicast flooding continues for that destination address. Also unicast flooding is observed for MAC addressing already in the CAM. The unicast flooding on the switch appears to be the root of the strange behaviors. If we move the devices off the stack, they are fine for anyone that does not have to traverse the Cisco stack. The Cam table is no where near full-approximatley 400 addresses - the normal size is closer to 600.

Can anyone explain why these switches SGE2010P in a stack configuration) would be unicast flooding if the MAC address is in the CAM and appears on the correct port on the switch? We are planning to break the stack to try to isolate the problem. The only resolution to the problem so far has been to reload the switch stack. 

[ITInfraTeam]

Hi Jacqueline,

We are experiencing the same issue on a Stack of C2960S switches running IOS 15.0(1)SE2. Where you able to get to the bottom of this issue????.

The CAM table contains the destination MAC address but the flooding continues. This appears to happen on all VLANs configured.

Regards

Infrastructure Team

[Tom Watts]

Hi ITInfraTeam, the SGE2xxx switch is a small business switch. The solution for the unicast flood on the SGE2000 stack is to filter the BPDU message. I cannot say that would be a solution on your 2960s

-Tom
Please mark answered for helpful posts
http://blogs.cisco.com/smallbusiness/