Re: Runts & Gaints

Thanks all for this nice troubleshooting stuff...

On Sun, Aug 2, 2009 at 4:11 PM, Scott Morris <smorris_at_ine.com> wrote:

> No worries.... Things like this I put into my "Seeing Is Believing"
> category. Or as President Reagan used to say, "Trust, But Verify". :)
>
> Whenever you can let the routers/switches/packet capture/whatever tell
> you what's actually going on, you get to either verify, or disprove
> something, or even lead to extra/deeper questions along the way. All
> of which are good for your level of understanding!
>
> Cheers,
>
>
>
>
> *Scott Morris*, CCIE/x4/ (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 <http://www.internetworkexpert.com/>
>
> Toll Free: 877-224-8987
>
> Outside US: 775-826-4344
>
>
> Knowledge is power.
>
> Power corrupts.
>
> Study hard and be Eeeeviiiil......
>
>
>
>
>
>
> MDevarajan_at_inautix.co.in wrote:
> > 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 <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
> > _________________________________________________________________
> > MSN Quiz The clash is on to find the best brains. Test your skills with
> >
> > avid
> >
> > quizzers on MSN quiz.
> > http://specials.msn.co.in/WLSocialNetworkConnector/Chrome.aspx
> >
> >
> > Blogs and organic groups at http://www.ccie.net
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
> >
> > Blogs and organic groups at http://www.ccie.net
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
> >
> > Blogs and organic groups at http://www.ccie.net
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
> >
> > Blogs and organic groups at http://www.ccie.net
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Mon Aug 03 2009 - 07:30:15 ART