Aruba & ProVision-based
1748285 Members
3984 Online
108761 Solutions
New Discussion юеВ

Re: Major Network Issues

 
SOLVED
Go to solution
parnassus
Honored Contributor

Re: Major Network Issues

Start with show arp and show mac-address commands.

I'm not an HPE Employee
Kudos and Accepted Solution banner
dmcdonough
Occasional Advisor

Re: Major Network Issues

ran show arp

i see the normal arp table. what would i see on this output if anything was out of bounds?

 

i see ip address ,mac address, type and port.

 

All seems normal

 

 

parnassus
Honored Contributor

Re: Major Network Issues


16again wrote: Is switch ARP table growing out of bounds?

Would out of bounds mean over 64k entries (considering that HPE 5400zl Switch Series's MAC Table Size should admit up to 64k entries)?


I'm not an HPE Employee
Kudos and Accepted Solution banner
Vince-Whirlwind
Honored Contributor

Re: Major Network Issues

STP doesn't detect remote loops on unmanaged switches unless you are actually sending BPDUs out of Access ports AND the unmanaged switch is passing them. This is what "loop-protect" is for, you put it on all Access ports to protect you from unmanaged switch loops.

The way I very quickly solve these kinds of issues is by gathering switchport statistics. I use Solarwinds Performance Monitor.
I fire it up, point it at all the switches, adding all switchports as monitored objects and half an hour later I will see which switchports have dodgy-looking traffic profiles.

dmcdonough
Occasional Advisor

Re: Major Network Issues

Think I have finally made some progress. 

I believe the issue is with a down line switch on the other end of my fiber connection between my buildings over my (trk1) i ended up finding a replacement switch and off loaded my phone system in my other building on the new switch. After waiting a few hours and checking the new switch and phone system connections are holding steady as the other switch in question is still showing packet drops. 

Still waiting for a level 2 HP engineer to call.

I am going to see how inter building phone communication is tomorrow and see if the new switch works out. If all looks good I will transfer everything else over to the new switch.

Once HP calls i will work with them to replace the possible bad switch.

Keep you posted on the final outcome.

dmcdonough
Occasional Advisor

Re: Major Network Issues

Thanks Parnassus,

The HP level 2 didn't suggest the update the firmware, however he did ask me to run: no tcp-push-preserve command on my core and any other edge switch that would accept the command. Once i did this the network settled right down.

We are still troubleshooting a few other minor things on my network.

I have a ping program running a constant ping to my core along with the 5 network switches that are in my 2nd buidling. Buidlings are connected together with 1 gig fiber connection / tranceiver.

I am still getting some random packet drops or ping timeout on 1-2 of the switches in my 2nd building. I updated the firmware on all of my other switches.

Other than that, my phone are good, however i am sitll showing high round trip delay errors even though no one has reported call quailty issues. I have and avaya ip office in both buidlings connected together over the same 1 gig fiber trunk.

 

Vince-Whirlwind
Honored Contributor

Re: Major Network Issues

I think you're looking to find a fault in the switches when the fault actually lies in your environment, specifically: 1Gb for uplinks is no good - you are surely seeing congestion on these. The tcp-push-preserve "fix" isn't going to relieve the congestion. Your ping latency is showing that you have congestion.

PCs now have 1Gb NICs as a rule, and these days a PC running something like FTP can easily achieve a throughput of over 500Mb/s, meaning that two PCs running FTP will max out their uplink.

Uplinks need to be 10Gb.

I had a network with 2x 5412 in the core that performed fine with about 40x 10Gb ports on each 5412, uplinking to about 2000 active switchports.

parnassus
Honored Contributor

Re: Major Network Issues

Hello @dmcdonough: glad things are running nicely than before.

The point is, as @Vince-Whirlwind pointed out, that your actual highway (Trk1) between your buildings is less capable of the route to your VDI system...so congestions could be always around the corner especially if the majority of clients are on the other side of the trunk flooding it constantly (would interesting to monitor trunk usage and VDI link usage to see the range of ingress/egress data traffic flowing into/from them).

You should plan an upgrade of your Trunk from 2x1Gbps aggregated links to a 2x10Gbps aggregated links or, if you can't afford that configuration (physically fiber optic cables are there already), trying at least to play with just one 10Gbps trunk (in both cases you need SFP+ Modules and SFP+ Transceivers on both ends of the trunk).


I'm not an HPE Employee
Kudos and Accepted Solution banner
parnassus
Honored Contributor

Re: Major Network Issues


dmcdonough wrote: ...however i am sitll showing high round trip delay errors...

 


Can you quantify the (average) delay? High Round Trip value isn't necessarily an error...also having a fat pipe doesn't necessaarily mean that TCP data transfers will become higher (this article could be an interesting reading).

What is the fiber optic trunk's latency value (below/around millisecond I suppose)?


I'm not an HPE Employee
Kudos and Accepted Solution banner
Jcckmc
Occasional Visitor

Re: Major Network Issues

What i have found is that meerly setting Spanning-tree up does not prevent unmanaged switches from looping the HP switch they are connected to.  When a loop is presented on an unmanaged switch spanning-tree of the core switch will shut off the uplink to the edge switch  or the edge switch cpu will be overrun and cannot be accessed remotley.  At that point you have to console into the edge switch to identify the port that has an unmanaged switch with the loop.  What we did to combat this is turn on BPDU-protection on the station end ports that use unmanaged switches.  This setting will shut off the port connected to the looped unmanaged switch without affecting the entire edge switch.   Since we implemented this we have not had anymore switch level outages caused by loops on unmanaged switches.