Re: Runts & Gaints

Scott,

Thanks a lot ... I understood now ..
Its awesome.

Thanks and Regards,
Mohan

Scott Morris <smorris_at_ine.com>
08/01/2009 09:27 AM
Please respond to
smorris_at_ine.com

To
Roy Waterman <roy.waterman_at_gmail.com>
cc
Mohan Kumar Devarajan/Chennai/iNautix_at_iNautix, Andy Reid <ccie_at_reid.it>,
"ccielab_at_groupstudy.com" <ccielab_at_groupstudy.com>, nobody_at_groupstudy.com,
Tapas Das <tapas_75_at_hotmail.com>
Subject
Re: Runts & Gaints

Uber-Geek-TS1#ping 10.10.100.84 si 36
 
Type escape sequence to abort.
Sending 5, 36-byte ICMP Echos to 10.10.100.84, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

Uber-Geek-TS1#
*Aug 1 14:02:08.938: IP: tableid=0, s=10.10.100.248 (local),
d=10.10.100.84 (FastEthernet0/0), routed via FIB
*Aug 1 14:02:08.938: IP: s=10.10.100.248 (local), d=10.10.100.84
(FastEthernet0/0), len 36, sending
*Aug 1 14:02:08.938: ICMP type=8, code=0
*Aug 1 14:02:08.942: IP: tableid=0, s=10.10.100.84 (FastEthernet0/0),
d=10.10.100.248 (FastEthernet0/0), routed via RIB
*Aug 1 14:02:08.942: IP: s=10.10.100.84 (FastEthernet0/0),
d=10.10.100.248 (FastEthernet0/0), len 36, rcvd 3
*Aug 1 14:02:08.942: ICMP type=0, code=0
*Aug 1 14:02:08.946: IP: tableid=0, s=10.10.100.248 (local),
d=10.10.100.84 (FastEthernet0/0), routed via FIB
*Aug 1 14:02:08.946: IP: s=10.10.100.248 (local), d=10.10.100.84
(FastEthernet0/0), len 36, sending
*Aug 1 14:02:08.946: ICMP type=8, code=0
*Aug 1 14:02:08.946: IP: tableid=0, s=10.10.100.84 (FastEthernet0/0),
d=10.10.100.248 (FastEthernet0/0), routed via RIB
*Aug 1 14:02:08.946: IP: s=10.10.100.84 (FastEthernet0/0),
d=10.10.100.248 (FastEthernet0/0), len 36, rcvd 3
*Aug 1 14:02:08.946: ICMP type=0, code=0
*Aug 1 14:02:08.950: IP: tableid=0, s=10.10.100.248 (local),
d=10.10.100.84 (FastEthernet0/0), routed via FIB
*Aug 1 14:02:08.950: IP: s=10.10.100.248 (local), d=10.10.100.84
(FastEthernet0/0), len 36, sending
*Aug 1 14:02:08.950: ICMP type=8, code=0
*Aug 1 14:02:08.950: IP: tableid=0, s=10.10.100.84 (FastEthernet0/0),
d=10.10.100.248 (FastEthernet0/0), routed via RIB
*Aug 1 14:02:08.954: IP: s=10.10.100.84 (FastEthernet0/0),
d=10.10.100.248 (FastEthernet0/0), len 36, rcvd 3
*Aug 1 14:02:08.954: ICMP type=0, code=0
*Aug 1 14:02:08.954: IP: tableid=0, s=10.10.100.248 (local),
d=10.10.100.84 (FastEthernet0/0), routed via FIB
*Aug 1 14:02:08.954: IP: s=10.10.100.248 (local), d=10.10.100.84
(FastEthernet0/0), len 36, sending
*Aug 1 14:02:08.954: ICMP type=8, code=0
*Aug 1 14:02:08.954: IP: tableid=0, s=10.10.100.84 (FastEthernet0/0),
d=10.10.100.248 (FastEthernet0/0), routed via RIB
*Aug 1 14:02:08.954: IP: s=10.10.100.84 (FastEthernet0/0),
d=10.10.100.248 (FastEthernet0/0), len 36, rcvd 3
*Aug 1 14:02:08.954: ICMP type=0, code=0
*Aug 1 14:02:08.954: IP: tableid=0, s=10.10.100.248 (local),
d=10.10.100.84 (FastEthernet0/0), routed via FIB
*Aug 1 14:02:08.958: IP: s=10.10.100.248 (local), d=10.10.100.84
(FastEthernet0/0), len 36, sending
*Aug 1 14:02:08.958: ICMP type=8, code=0
*Aug 1 14:02:08.958: IP: tableid=0, s=10.10.100.84 (FastEthernet0/0),
d=10.10.100.248 (FastEthernet0/0), routed via RIB
*Aug 1 14:02:08.958: IP: s=10.10.100.84 (FastEthernet0/0),
d=10.10.100.248 (FastEthernet0/0), len 36, rcvd 3
*Aug 1 14:02:08.958: ICMP type=0, code=0
Uber-Geek-TS1#

Ok, we see at 36 bytes (datagram, by the way, in case we need to review
OSI model naming of PDUs). And the debug indicates a length of 36 as
well.

But Wireshark has a different opinion. Building up (packet generated
from Cisco device to my laptop):

Data = 8 bytes
ICMP Header = 8 bytes
IP Header = 20 bytes
(There's your 36 bytes by the way)
Ethernet Header = 24 bytes (This includes a 10-byte trailer of all 0's
that Cisco's sticking on)

Thus you have 60 bytes. Plus a 4-byte CRC/checksum that is not viewed by
Wireshark.

Ethernet -- Total Capture length = 60 bytes (60 bytes on wire, 60 bytes
captured) -- Not counting ethernet header

When we look at raw ethernet information (as pointed out, captures will
vary based on media type), the minimum information allowed **per spec**
is:

7 byte preamble
1 byte delimiter (these two aren't always used and aren't captured either)
6 byte Dest MAC
6 byte Src MAC
2 byte type/length
46 byte data (includes L3 header, etc.)
4 byte checksum

That's 72 bytes total, or 64 without the preamble/delimiter

Scott Morris, CCIEx4 (R&S/ISP-Dial/Security/Service Provider) #4713,
JNCIE-M #153, JNCIS-ER, CISSP, et al.
JNCI-M, JNCI-ER
evil_at_ine.com

Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987
Outside US: 775-826-4344

Knowledge is power.
Power corrupts.
Study hard and be Eeeeviiiil......
 

Roy Waterman wrote:
Mohan...

There is a difference between the minimum packet size and the minimum
frame
size...
The size option in ping does not take into account the underlying l2
header
that will be applied...which will vary of course dependent upon the
interface type...

2009/8/1 <MDevarajan_at_inautix.co.in>

 
Andy ,
As I have checked min packet size is 36 bytes.

R4#pi 155.1.45.5 re 1 size 36

Type escape sequence to abort.
Sending 1, 36-byte ICMP Echos to 155.1.45.5, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 48/48/48 ms

Please correct me if am wrong.

Thanks ,
Mohan

Andy Reid <ccie_at_reid.it>
Sent by: nobody_at_groupstudy.com
07/31/2009 09:52 PM
Please respond to
Andy Reid <ccie_at_reid.it>

To
Tapas Das <tapas_75_at_hotmail.com>
cc
"ccielab_at_groupstudy.com" <ccielab_at_groupstudy.com>
Subject
Re: Runts & Gaints

Hi Tapas,

The 'runts' counter gives the number of packets that are discarded
because they are smaller than the medium's minimum packet size. An
Ethernet frame (IEEE 802.3) minimum packet size is 64 bytes.

The 'giants' counter gives the number of packets that are discarded
because they exceed the medium's maximum packet (MTU) size. The original
default value is 1500 bytes, however it can usually be configured
smaller or larger.

I see that you have Gigabit Ethernet interfaces, yet they have connected
at Fast Ethernet and have an MTU size of 1500 bytes. In my experience,
poor negotiation can cause all sorts of problems. Either when connecting
Ethernet between two vendors equipment, of simply one end is hard set
and the other is configured for auto. Try performing a throughput test
over the link, if the throughput is 10Mbits or less then money is on the
Ethernet negotiation causing the error counters to increment.
If you look at your input queue, in 1w2d you have accumulated 161044
drops - this may seem large, but it only accounts for 0.5% of the total
input traffic. In addition, your CRC counter is 83386 - either the
medium is faulty (i.e. for cable) or the frames are being interrupted.
Note that the other interface has not been cleared for 40 weeks - its
impossible to tell the history from a single snapshot over such a long
duration.

Also, graph the history of the CPU in the device - flat-lining at 100%
for periods of time would also be a possible cause for runts, giants and
CRC's.

regards Andy

Tapas Das wrote:
 
Due to what reasons I may recive runts & gaints on my Interface
SH RUNN INT GI 11/6Building configuration...
Current configuration : 220 bytes!interface GigabitEthernet11/6
 
switchport
 
 switchport access vlan 502 switchport mode access no ip address speed
 
100
 
duplex full spanning-tree portfastend
XXXXXXXX#SH RUNN INT GI 11/9Building configuration...
Current configuration : 218 bytes!interface GigabitEthernet11/9
 
switchport
 
 switchport access vlan 502 switchport mode access no ip address speed
 
100
 
duplex full spanning-tree portfastend

SH INT GI 11/6GigabitEthernet11/6 is up, line protocol is up (connected)
Hardware is C6k 1000Mb 802.3, address is 001b.d5fe.29dd (bia
 
001b.d5fe.29dd)
 
Description: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX MTU 1500
 
bytes, BW
 
100000 Kbit, DLY 10 usec, reliability 255/255, txload 1/255, rxload
 
1/255
 
Encapsulation ARPA, loopback not set Keepalive set (10 sec)
 
Full-duplex,
 
100Mb/s input flow-control is off, output flow-control is on Clock
 
mode is
 
auto ARP type: ARPA, ARP Timeout 04:00:00 Last input never, output
 
00:00:56,
 
output hang never Last clearing of "show interface" counters 1w2d Input
queue: 0/2000/161044/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo Output queue: 0/40 (size/max) 5 minute input
 
rate 0
 
bits/sec, 0 packets/sec 5 minute output rate 3000 bits/sec, 6
 
packets/sec
 
28590011 packets input, 3155794998 bytes, 0 no buffer Received 3238
broadcasts (9 multicasts) 8779 runts, 141 giants, 0 throttles 161044
input errors, 83386 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 0
multicast, 0 pause input 0 input packets with dribble condition
 
detected
 
53066376 packets output, 57544944850 bytes, 0 underruns 0 output
 
errors, 0
 
collisions, 0 interface resets 0 babbles, 0 late collision, 0
 
deferred
 
0 lost carrier, 0 no carrier, 0 PAUSE output 0 output buffer
 
failures, 0
 
output buffers swapped out
xxxxxxxxxx#SH INT GI 11/9GigabitEthernet11/9 is up, line protocol is up
(connected) Hardware is C6k 1000Mb 802.3, address is 001b.d5fe.29e0
 
(bia
 
001b.d5fe.29e0) Description:
 
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX MTU
 
1500 bytes, BW 100000 Kbit, DLY 10 usec, reliability 255/255,
 
txload
 
1/255, rxload 1/255 Encapsulation ARPA, loopback not set Keepalive set
 
(10
 
sec) Full-duplex, 100Mb/s input flow-control is off, output
 
flow-control is
 
on Clock mode is auto ARP type: ARPA, ARP Timeout 04:00:00 Last
 
input
 
never, output 00:00:03, output hang never Last clearing of "show
 
interface"
 
counters 40w0d Input queue: 0/2000/31379086/0 (size/max/drops/flushes);
 
Total
 
output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max)
 
5
 
minute input rate 70000 bits/sec, 34 packets/sec 5 minute output rate
 
25000
 
bits/sec, 9 packets/sec 1246875972 packets input, 678093317020
 
bytes, 0 no
 
buffer Received 11404 broadcasts (0 multicasts) 336645 runts,
 
8315
 
giants, 0 throttles 31379086 input errors, 30144143 CRC, 0 frame, 0
overrun, 0 ignored 0 watchdog, 0 multicast, 0 pause input 0
 
input
 
packets with dribble condition detected 828815484 packets output,
126903728484 bytes, 0 underruns 0 output errors, 0 collisions, 0
 
interface
 
resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0
 
no
 
carrier, 0 PAUSE output 0 output buffer failures, 0 output buffers
 
swapped
 
out
Received on Sun Aug 02 2009 - 05:46:45 ART