[f-nsp] Disabling WRED
Matthew Walster
matthew at walster.org
Fri Nov 14 01:20:35 EST 2014
I have an MLX (not MLX-e) that I'm currently using for a testing
environment, and I'm trying to debug some occasional packet loss.
In doing so, I'm discovered that the interface is doing occasional NP
Ingress drops -- about 10 a second. My config had wred enabled, (even
though the system was practically unused except for OSPF and BGP messages
plus an ssh session , and there were 1G links everywhere) so I disabled it.
I'm still getting drops. It wouldn't be such a big deal, but I'm trying to
transfer data from London to Tokyo and it's causing the data rate to dive
down below 10Mbit/s with frequent stalls due to TCP slow start!
Any ideas?
SSH at tklab1#show qos red
QType Enable AverWeight MaxQSz DropPrec MinAvgQSz MaxAvgQSz MaxDropProb
MaxPktSz
0 No
1 No
2 No
3 No
4 No
5 No
6 No
7 No
SSH at tklab1#show run | in qos
enable-qos-statistics
qos-tos map cos-dscp 0 8 16 24 32 46 48 56
qos-tos map ip-prec-dscp 0 8 16 24 32 46 48 56
SSH at tklab1#show np stat e 1/19
Port 1/19 RX
NP Rx Raw Good Packet = (16509415)
NP Rx Forward Packet = (16062134)
NP Rx Discard Packet = (447281)
NP Rx Misc Packet = (0)
NP Rx Unicast Packet = (16509411)
NP Rx Broadcast Packet = (0)
NP Rx Multicast Packet = (4)
NP Rx Send to TM Packet = (16062134)
NP Rx Bad Packet = (0)
NP Rx Lookup Unavailable = (0)
NP Rx ACL Drop = (0)
NP Rx Priority 0/1 Drop = (447266)
NP Rx Priority 2/3 Drop = (0)
NP Rx Priority 4/5 Drop = (15)
NP Rx Priority 6/7 Drop = (0)
NP Rx Suppress RPF Drop = (0)
NP Rx RPF Drop = (0)
NP Rx IPv4 Packet = (16512176)
NP Rx IPv6 Packet = (4)
NP Rx Route-only Drop = (0)
NP Rx IPv6 Suppress RPF Drop = (0)
NP Rx IPv6 RPF Drop Count = (0)
NP Rx IPv4 Byte = (13847581409)
NP Rx IPv6 Byte = (520)
NP Rx Routed Packet Drop = (0)
Port 1/19 TX
NP Tx Sent to MAC Packet = (20751216)
NP Tx Raw Good Packet = (20751216)
NP Tx Source Port Supress Drop = (0)
NP Tx Bad Packet Count = (0)
NP Tx Unicast Packet = (20750864)
NP Tx Broadcast Packet = (352)
NP Tx Multicast Packet = (0)
NP Tx Receive from TM = (20751216)
NP Tx ACL Drop = (0)
NP Tx IPv4 Packet = (20751641)
NP Tx IPv6 Packet = (0)
NP Tx IPv4 Byte = (15750044583)
NP Tx IPv6 Byte = (0)
SSH at tklab1#show int ethe 1/19
GigabitEthernet1/19 is up, line protocol is up
STP Root Guard is disabled, STP BPDU Guard is disabled
Hardware is GigabitEthernet, address is 748e.f85c.2112 (bia
748e.f85c.2112)
Configured speed auto, actual 1Gbit, configured duplex fdx, actual fdx
Member of VLAN 1 (untagged), port is in untagged mode, port state is
Forwarding
STP configured to ON, Priority is level0, flow control enabled
Priority force enabled, Drop precedence level 3, Drop precedence force
enabled
dhcp-snooping-trust configured to OFF
mirror disabled, monitor disabled
LACP BPDU Forwarding:Disabled
LLDP BPDU Forwarding:Disabled
Not member of any active trunks
Not member of any configured trunks
Port name is INET-UPLINK
Port is not enabled to receive all vlan packets for pbr
Internet address is w.x.y.z/30, MTU 9216 bytes, encapsulation ethernet
Openflow: Disabled, Openflow Index 19
Cluster L2 protocol forwarding enabled
300 second input rate: 1065974 bits/sec, 196 packets/sec, 0.10%
utilization
300 second output rate: 747681 bits/sec, 181 packets/sec, 0.07%
utilization
16725013 packets input, 13782130514 bytes, 0 no buffer
Received 0 broadcasts, 4 multicasts, 16725009 unicasts
0 input errors, 0 CRC, 0 frame, 0 ignored
0 runts, 0 giants
NP received 16972029 packets, Sent to TM 16522098 packets
NP Ingress dropped 449931 packets
20835572 packets output, 15362377564 bytes, 0 underruns
Transmitted 353 broadcasts, 0 multicasts, 20835219 unicasts
0 output errors, 0 collisions
NP transmitted 20900629 packets, Received from TM 20900630 packets
Counters were cleared after disabling WRED, so this is all new data since
disabling WRED. Yes, turning on SACK will help, but I'd rather get rid of
the packet loss that's causing the issue.
M
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/foundry-nsp/attachments/20141114/1ff6660e/attachment-0001.html>
More information about the foundry-nsp
mailing list