ways to tshoot server and applications issues on L2 and L3 switches?

[baselzind]

in my network I'm handling the switches with the core L3 and L2 edge switches. currently when there is any problem with our applications on our servers the server team will directly say it is from the network and I have to clear the network side everytime before they start tshooting from their side. My question is what other ways of tshooting beside pinging the server and telnetting the server on a certain port that I can prove that it isn't from the switches? and is there any good material for this kind of tshooting?

[Flavio Miranda]

Hi

 Not much and usually the problem is not on the switch. If CPU and memory is under control, the other option I see is wrong configuration. 

 But I know your pain very well.

 One interesting option cisco have for newer switches is ThousandEye. This application can run on the switch and populate a dashborad with information about application, latency, jitter,etc. 

 Aside from this, the option we have is usually ping and trace for l3 and almost nothing for l2. 

[Jon Marshall]

Server guys always blame the network first. 

Do the basic connectivity tests ie. can the device ping it's default gateway, can it ping beyond it's default gateway and ping both the server IP and name. 

Obviously if there are access lists or firewalls in the path then you would need to look at those as well. 

And check with the server guys what IP and subnet mask they have used because quite often it is simply a misconfigured IP setting on the server etc. 

Jon

[Jitendra Kumar]

You can't  do more than telnet and ping connectivity check.

The server and network team both want to show there is not my issue even when investigating such an issue server team most of time loses.

save your output as you are ok.

Thanks,

Jitendra

[Georg Pauwen]

Hello,

you could check the interfaces the servers are connected to (and if the switches are uplinked, check these interfaces, too) for input/output errors and drops.

What servers are we talking about ? What OS are they on, and which applications are causing problems ?

[baselzind]

at the moment there is no issue but the problem is we have many kinds of servers and web application which are critical and at the first accessibility issue they will direct the issue first at me and i will be the center of the problem so I'm trying to improve on methods of how to clear the switches side as I'm worried incase the servers cant be pinged for example because of internal firewall or something. 

[Jon Marshall]

If they are running firewalls on the servers themselves then you need to get a rule added to allow a management IP to be able to ping otherwise it makes it a lot more difficult to check basic connectivity. 

If you cannot ping because of server firewalls then they will always just keep passing it back to you. 

Jon

[baselzind]

is there any kind of improved trace route that will show me a better clearer route of traffic than the normal one on switches which tend to be next to useless as it always show me stars

[MHM Cisco World]

I spent last week study such this case,
what is model of SW you use in Core, Agg and Access SW?

[baselzind]

core is 6500 , server farm is 4500 and edge switches multiple models 3850 and 3560

[MHM Cisco World]

please see the below chart some Packet Capturing Tool you can use in each SW even NX-OS,
so for your case FED tracing CPU Queue NetDR for 3850/4500 and 6400.

[baselzind]

these  FED tracing CPU Queue NetDR are application or what exactly? like wireshark?

[MHM Cisco World]

https://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/116475-technote-product-00.html

https://www.cisco.com/c/en/us/support/docs/switches/catalyst-3850-series-switches/117594-technote-hicpu3850-00.html

let me explain what happened here, 

the swathing is happen in two place in New switch of Cisco 
in  TCAM and in CPU 
in TCAM is hardware switching and it fast 
in CPU is software switching and it slow 

i follow your previous post you have slow so there is chance that the switching is software not hardware.

how is traffic switching via software is matter here we as much as we can reduce the traffic switching via CPU.

other issue of slowness which may be from Queue is full and there is drop is by using Wireshark

in wireshark if there is any TCP double ACK that meaning that one side is missing receive TCP segment and other side is send it and here there is drop and we will go and check Queue.