Problem Switch Auditing on 6513

Oh man! Ad-blocking software has been detected! :'(

This website is run by the community, for the community... and it needs advertisements in order to keep running. Blocking our ads means your killing our stats!
Please disable your ad-block, or become a premium member to hide all advertisements and this notice.

Hi All,

I have recently been looking through our network here, and have found a large number of overruns on various interfaces within our 6513 switch.

We only had 12 blades installed, so I have now installed a 13th blade so that I can reduce some of the congestion. As these switch blades work on a line card supporting 8 ports, I have split up the current ports into groups of 8, totalled any overruns and identified the biggest groups of congestion, along with the biggest single offenders etc.

Now, the root cause of the overruns appears to be various blade enclosures of ours, so consist of multiple servers which could be creating the load. Unfortunately, whoever did the cabling has not done a good job and large amounts of it appear to be wrong.

I was rather hoping I could look at the cables from the blade centres, which state which port they are plugged into, then present that to our server team to show which servers/blades are causing the fault. Due to the labelling though I am not able to do it without individually tracing each and every cable, which would be a mountain if work for me to get through.

So my question, Is there a way from the switch to be able to find out which port in the blade centre it is connected too? I know if it was a single server, then I could get the server MAC address, then just check the mac address table to see where it is coming from, however I am not too sure how it works with blade centres, as they have multiple servers. Will all data still come from one shared NIC? ie I will be able to see the same NIC coming in on 8 different ports on the switch, but no way to know which port in the Blade is sending to that switch port? If that makes sense?

Is there an easy way to audit this? So that I can find where the problem is without having to trace the mountains of cables?

 

Oh man! Ad-blocking software has been detected! :'(

This website is run by the community, for the community... and it needs advertisements in order to keep running. Blocking our ads means your killing our stats!
Please disable your ad-block, or become a premium member to hide all advertisements and this notice.

Anyone???

 

I assume you've checked for cdp neighbors? Even if the blade switches aren't Cisco they may support LLDP and you may be able to get something back.

Actually looking back you've not said if the blade modules are in fact switches. So really what make blade centre is it and what modules are installed?

 

I think they are HP blade centres. I have today managed to get a list of all servers on the blade centres though, so I'm thinking I can ping the servers one by one, then show ip arp to get a MAC, then use the mac address table to find what's attached to what port. If that makes sense. That should at very least give me the active channels, Then I just hope they have been setup properly in port channels as active and passive!

I have run the cdp neighbours but it doesn't help, the blades don't show up as neighbours etc.

Hopefully my above plan will work though, as it's the only other way I can think of to find what's what!

 

Meant to come back to this, had my "I'm tired but should post something hat on" when I first posted so apologies if you've got it done now.

From the sound of it (assumptions aplenty) the blade chassis has a 8 port external switch and probably 16 port internal per fabric slot, so a standard 24 port switch. It should be managable and the uplinks should be etherchanneled off ideally to your distribution/core so shouldnt be too bad to trace *if* required as a last resort. Internally you will probably have server 1 in port 1, server 2 in port 2 etc etc...

A mac address trace should tell you which uplink it is using (take care of etherchannel load balancing) and a re-arrange of the etherchannel trunking and vlans will probably solve the congestion.

 

I'm halfway through doing it, been busy with other bits and pieces so not had as much time as I would of liked to focus on it.

The blade centres have 2 8port switches in them, one set as primary, one as backup. So I am tracing the servers and finding the active connections, then looking at that interface to see if it is port channelled, which will hopefully highlight the back up too.

I have got some good information out of it so far, but time will tell once I have it completed as to what I really find. Hopefully enough to get the heaviest users across to the new switch blade though and relieve a bit of the issue. No way will I be able to eradicate it completely, but will at least be able to ease it.

Quote in at the moment for NEXUS upgrade, just waiting for approval, then will have to plan for that as a major project to upgrade the entire core setup. Should be fun.