Packet loss

[Diana Karolina Rojas]

Good morning community,

I have the following question: I have a network that consists of the following: SWACCESO-> SWDISTRIBUCION-> CORE when I do ping (32bytes) from a machine that is connected to my access switch to its gateway (which ais in the SWCORE) I lose packages, of 1688 I lost 5. 

These are my port statitics:

FastEthernet0 / 7 is up, the line protocol is up (connected)
The hardware is Fast Ethernet, the address is 0022.0d61.d309 (bia 0022.0d61.d309)
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
ARPA encapsulation, loopback not established
Keepalive Set (10 sec)
Full-duplex, 100Mb / s, media type is 10 / 100BaseTX
the input flow control is disabled, the output flow control is not compatible
ARP type: ARPA, ARP Wait time 04:00:00
Last entry never, exit 00:00:01, exit hang never
Last cleaning of "show interface" counters never
Input queue: 0/75/0/0 (size / maximum / drops / downloads); Total output drops: 4618
Tail strategy: fifo
Output queue: 0/40 (size / maximum)
Input speed of 5 minutes 11000 bits / sec, 8 packets / sec
Output speed of 5 minutes 35000 bits / sec, 9 packets / sec
27570921 input packets, 4961662284 bytes, 0 unbounded
Received 73620 broadcasts (62217 multicasts)
0 runts, 0 giants, 0 throttles
7 input errors, 0 CRC, 0 frame, 0 overflow, 0 ignored
0 watchdog, 62217 multicast, 0 pause input
0 entry packs with dribble status detected
30118819 output packages, 14373369350 bytes, 0 underutilizes
0 output errors, 0 collisions, 3 interface restarts
0 babbles, 0 late collisions, 0 postponed
0 loss of carrier, 0 non-carrier, 0 exit PAUSE
0 output buffer errors, 0 output buffer exchanged

My interface is configured in the following way:

FastEthernet0 / 7 interface
switchport access vlan 538
Access to switching mode
switchport voice vlan 635
Maximum security switching port 2
security switching port
switchport port-security aging time 2
switchport port-security violation restrict
bandwidth quota of srr-queue 1 30 35 5
priority-queue outside
mls qos trust dscp
auto qos trust dscp
Storm control transmission level 5.00
expansion tree portfast
spanning-tree bpduguard enable
expansion tree guard loop
end

My question is: is a loss like that normal? That ping was running like 25-30 minutes. It is normal? I consult it because I have an application that constantly disconnect and we want to know if this is a layer 2 issue, it happens to all users within the same VLAN.

Best regards,

[Julio E. Moisa]

Hi Diana, Good morning,

Usually (rarely) there are no lost packets over layer 2 devices, and the timing is around of 1-8 ms. Have you verified the cabling, trunk ports, replaced SFP's, HSRP changes or any spanning-tree change?

:-)

[Joseph W. Doherty]

Do I understand correctly, you're pinging a gateway IP?

If so, understand that network devices give ping replies very low priority, so it's not uncommon for such devices to drop ping requests (or delay their reply). If they do, it's usually not an indication that there's any kind of network (performance) issue. So, yes, it can be "normal".

That said, its also possible packets are being drop to or from the gateway too. For example, your f0/7 stats do show some output drops, although at a very low percentage.

[pigallo]

Hello Diana,

i would say in this case that it could probably be a layer 2 issue.

Without knowing the services running into your campus i can give you only generic advice about what to verify and check in such cases.

First of all if this happens just into this specific vlan (id 538), i would not waste too much time looking into physical link overload or faulty cables, because if you share links among multiple vlans, then other vlans may have been impacted too by this loss.

So first thing to verify is if the Spanning tree is working correctly. You should verify if topology changes occur too often in your network because this can lead also to additional problems like unknown unicast flooding issues.

Secondly you may want also to verify if you run storm control over uplink trunks because sometimes broadcast traffic can compete against unicast traffic and create some outage.
Third thing to check how your Qos is working inside that vlan, check your queues, if they are saturated, if they are dropping, and what is going on within that vlan domain.

If your broadcast domain span across too many devices it could be difficult to isolate the problem on first attempt, thus it could be useful to proceeed with ping attempt from different network zones to isolate better what could be the interested device or group of devices.

Finally if you rely on network analisys tool inside your organization, it may be useful to check if alarms or drops are registered across specific devices in order to isolate rapidly the affected machines and keep focus on targeted areas rather than waste time to troubleshoot everywhere.