Re: Output Drops on Gig Interface

nope Kambiz i am based out of US..I understand that these drops are less but
as technical person i would like to know the reason of the drops. I am doing
some tests.. Will update the group with the status.

thanks
naman

On 5 May 2010 13:01, Kambiz Agahian <kagahian_at_ccbootcamp.com> wrote:

> Naman,
>
> By any chance are you based in Japan? I had a Japanese customer and they
> wanted an engineer to "find" a lost packet ;)
>
>
> --------------------------
> Kambiz Agahian
> CCIE (R&S), CCSI, WAASSE, RSSSE
> Technical Instructor
> CCBOOTCAMP - Cisco Learning Solutions Partner (CLSP)
> Email: kagahian_at_ccbootcamp.com
> Toll Free: 877-654-2243
> International: +1-702-968-5100
> Skype: skype:ccbootcamp?call
> FAX: +1-702-446-8012
> YES! We take Cisco Learning Credits!
> Training And Remote Racks: http://www.ccbootcamp.com
>
>
>
>
>
>
> -----Original Message-----
> From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
> naman sharma
> Sent: Wednesday, May 05, 2010 12:48 PM
> To: Marko Milivojevic
> Cc: Ryan West; Narbik Kocharians; itguy.pro_at_gmail.com; Cisco
> certification
> Subject: Re: Output Drops on Gig Interface
>
> Well in our enviorment it is definately a serious problem. It keeps on
> incrementing and the customer sees these error with concerned eyes. So
> what
> do you suggest ??
>
> On 5 May 2010 12:09, Marko Milivojevic <markom_at_ipexpert.com> wrote:
>
> > Hm. Output drop rate of 0.018% is not something I would be concerned
> > about, but that's just me. I thought you had a serious problem :-)
> >
> > --
> > Marko Milivojevic - CCIE #18427
> > Senior Technical Instructor - IPexpert
> >
> > YES! We include 400 hours of REAL rack
> > time with our Blended Learning Solution!
> >
> > Mailto: markom_at_ipexpert.com
> > Telephone: +1.810.326.1444
> > Fax: +1.810.454.0130
> > Web: http://www.ipexpert.com/
> >
> > On Wed, May 5, 2010 at 17:27, naman sharma <naman.prep_at_gmail.com>
> wrote:
> > > Thanks Marko, Pls find the output. It is 6724-SFP module.. I believe
> it
> > has
> > > 1.2:1 subscription and we are only using 2 ports in these module.
> > >
> > > Here is the output.
> > >
> > > GigabitEthernet7/1 is up, line protocol is up (connected)
> > > Hardware is C6k 1000Mb 802.3, address is 001a.e2fa.8200 (bia
> > > 001a.e2fa.8200)
> > > Description: MCWD01 g7/1 to MCRC01 g7/1
> > > Internet address is X.X.X.X/30
> > > MTU 1560 bytes, BW 1000000 Kbit, DLY 10 usec,
> > > reliability 255/255, txload 8/255, rxload 6/255
> > > Encapsulation ARPA, loopback not set
> > > Keepalive set (10 sec)
> > > Full-duplex, 1000Mb/s, media type is LH
> > > input flow-control is off, output flow-control is off
> > > Clock mode is auto
> > > ARP type: ARPA, ARP Timeout 04:00:00
> > > Last input 00:00:00, output 00:00:00, output hang never
> > > Last clearing of "show interface" counters 12:49:09
> > > Input queue: 0/75/0/0 (size/max/drops/flushes); Total output
> drops:
> > 26131
> > > Queueing strategy: fifo
> > > Output queue: 0/40 (size/max)
> > > 30 second input rate 25745000 bits/sec, 6297 packets/sec
> > > 30 second output rate 32664000 bits/sec, 8255 packets/sec
> > > L2 Switched: ucast: 985662 pkt, 76200416 bytes - mcast: 19993 pkt,
> > 1746141
> > > bytes
> > > L3 in Switched: ucast: 136681880 pkt, 55359230030 bytes - mcast: 0
> pkt,
> > 0
> > > bytes mcast
> > > L3 out Switched: ucast: 143660930 pkt, 61006436251 bytes mcast: 0
> pkt,
> > 0
> > > bytes
> > > 137739519 packets input, 55462587036 bytes, 0 no buffer
> > > Received 24701 broadcasts (2057 IP multicasts)
> > > 0 runts, 169733 giants, 0 throttles
> > > 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
> > > 0 watchdog, 0 multicast, 0 pause input
> > > 0 input packets with dribble condition detected
> > > 144669115 packets output, 62231705511 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
> > >
> > >
> > > GigabitEthernet7/5 is up, line protocol is up (connected)
> > > Hardware is C6k 1000Mb 802.3, address is 001a.e2fa.8200 (bia
> > > 001a.e2fa.8200)
> > > Description: MCWD01 g7/5 to MCRC02 g7/1
> > > Internet address is X.X.X.X/30
> > > MTU 1560 bytes, BW 1000000 Kbit, DLY 10 usec,
> > > reliability 255/255, txload 5/255, rxload 4/255
> > > Encapsulation ARPA, loopback not set
> > > Keepalive set (10 sec)
> > > Full-duplex, 1000Mb/s, media type is LH
> > > input flow-control is off, output flow-control is off
> > > Clock mode is auto
> > > ARP type: ARPA, ARP Timeout 04:00:00
> > > Last input 00:00:00, output 00:00:00, output hang never
> > > Last clearing of "show interface" counters 12:49:51
> > > Input queue: 0/75/0/0 (size/max/drops/flushes); Total output
> drops:
> > 30829
> > > Queueing strategy: fifo
> > > Output queue: 0/40 (size/max)
> > > 30 second input rate 18466000 bits/sec, 4701 packets/sec
> > > 30 second output rate 19645000 bits/sec, 6727 packets/sec
> > > L2 Switched: ucast: 842993 pkt, 61018930 bytes - mcast: 18770 pkt,
> > 1660280
> > > bytes
> > > L3 in Switched: ucast: 126079051 pkt, 50881092114 bytes - mcast: 0
> pkt,
> > 0
> > > bytes mcast
> > > L3 out Switched: ucast: 134278036 pkt, 57388511678 bytes mcast: 0
> pkt,
> > 0
> > > bytes
> > > 126982662 packets input, 50967406677 bytes, 0 no buffer
> > > Received 22619 broadcasts (1044 IP multicasts)
> > > 0 runts, 12654 giants, 0 throttles
> > > 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
> > > 0 watchdog, 0 multicast, 0 pause input
> > > 0 input packets with dribble condition detected
> > > 135088285 packets output, 58515937777 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
> > >
> > >
> > > Also i would like to know if WRR queues are considered as Hardware
> > queues.??
> > > and in case i sniff the packets would i be able to sniff the drop
> packets
> > as
> > > well.
> > >
> > > thanks
> > >
> > >
> > > On 4 May 2010 12:37, Marko Milivojevic <markom_at_ipexpert.com> wrote:
> > >>
> > >> Could we see "show int" output for the relevant interface, please?
> > >>
> > >> What kind of LC is this? What is the fabric utilization? What is
> the
> > >> fabric switching mode?
> > >>
> > >> --
> > >> Marko Milivojevic - CCIE #18427
> > >> Senior Technical Instructor - IPexpert
> > >>
> > >> YES! We include 400 hours of REAL rack
> > >> time with our Blended Learning Solution!
> > >>
> > >> Mailto: markom_at_ipexpert.com
> > >> Telephone: +1.810.326.1444
> > >> Fax: +1.810.454.0130
> > >> Web: http://www.ipexpert.com/
> > >>
> > >> On Tue, May 4, 2010 at 19:09, naman sharma <naman.prep_at_gmail.com>
> > wrote:
> > >> > Thanks all for your replies. Well it is 1 Gig and full duplex on
> both
> > >> > the
> > >> > side and it is not hardcoded. Flow control is off on both the
> sides
> > for
> > >> > input and output traffic.
> > >> >
> > >> > So these 2 routers are in MPLs domain with one being PE and the
> other
> > >> > being
> > >> > P router and i see output drops on the PE router towards P
> router. PE
> > >> > router
> > >> > has mls qos enabled and right now the interface in the MPLS
> domain
> > shows
> > >> > all
> > >> > the traffic in cos 0 and hence in Queue 1 and there is where i
> see the
> > >> > drops.
> > >> >
> > >> > Interface GigabitEthernet7/1 queueing strategy: Weighted
> Round-Robin
> > >> > Port QoS is enabled
> > >> > Trust boundary disabled
> > >> >
> > >> > Trust state: trust COS
> > >> > Extend trust state: not trusted [COS = 0]
> > >> > Default COS is 0
> > >> > Queueing Mode In Tx direction: mode-cos
> > >> > Transmit queues [type = 1p3q8t]:
> > >> > Queue Id Scheduling Num of thresholds
> > >> > -----------------------------------------
> > >> > 01 WRR 08
> > >> > 02 WRR 08
> > >> > 03 WRR 08
> > >> > 04 Priority 01
> > >> >
> > >> > WRR bandwidth ratios: 100[queue 1] 150[queue 2] 200[queue 3]
> > >> > queue-limit ratios: 50[queue 1] 20[queue 2] 15[queue 3]
> > >> > 15[Pri
> > >> > Queue]
> > >> >
> > >> > queue tail-drop-thresholds
> > >> > --------------------------
> > >> > 1 70[1] 100[2] 100[3] 100[4] 100[5] 100[6] 100[7] 100[8]
> > >> > 2 70[1] 100[2] 100[3] 100[4] 100[5] 100[6] 100[7] 100[8]
> > >> > 3 100[1] 100[2] 100[3] 100[4] 100[5] 100[6] 100[7] 100[8]
> > >> >
> > >> > queue random-detect-min-thresholds
> > >> > ----------------------------------
> > >> > 1 40[1] 70[2] 70[3] 70[4] 70[5] 70[6] 70[7] 70[8]
> > >> > 2 40[1] 70[2] 70[3] 70[4] 70[5] 70[6] 70[7] 70[8]
> > >> > 3 70[1] 70[2] 70[3] 70[4] 70[5] 70[6] 70[7] 70[8]
> > >> >
> > >> > queue random-detect-max-thresholds
> > >> > ----------------------------------
> > >> > 1 70[1] 100[2] 100[3] 100[4] 100[5] 100[6] 100[7] 100[8]
> > >> > 2 70[1] 100[2] 100[3] 100[4] 100[5] 100[6] 100[7] 100[8]
> > >> > 3 100[1] 100[2] 100[3] 100[4] 100[5] 100[6] 100[7]
> 100[8]
> > >> >
> > >> > WRED disabled queues:
> > >> >
> > >> > queue thresh cos-map
> > >> > ---------------------------------------
> > >> > 1 1 0
> > >> > 1 2 1
> > >> > 1 3
> > >> > 1 4
> > >> > 1 5
> > >> > 1 6
> > >> > 1 7
> > >> > 1 8
> > >> > 2 1 2
> > >> > 2 2 3 4
> > >> > 2 3
> > >> > 2 4
> > >> > 2 5
> > >> > 2 6
> > >> > 2 7
> > >> > 2 8
> > >> > 3 1 6 7
> > >> > 3 2
> > >> > 3 3
> > >> > 3 4
> > >> > 3 5
> > >> > 3 6
> > >> > 3 7
> > >> > 3 8
> > >> > 4 1 5
> > >> >
> > >> > Queueing Mode In Rx direction: mode-cos
> > >> > Receive queues [type = 1q8t]:
> > >> > Queue Id Scheduling Num of thresholds
> > >> > -----------------------------------------
> > >> > 01 WRR 08
> > >> >
> > >> > WRR bandwidth ratios: 100[queue 1]
> > >> > queue-limit ratios: 100[queue 1]
> > >> >
> > >> > queue tail-drop-thresholds
> > >> > --------------------------
> > >> > 1 100[1] 100[2] 100[3] 100[4] 100[5] 100[6] 100[7] 100[8]
> > >> >
> > >> > queue thresh cos-map
> > >> > ---------------------------------------
> > >> > 1 1 0 1 2 3 4 5 6 7
> > >> > 1 2
> > >> > 1 3
> > >> > 1 4
> > >> > 1 5
> > >> > 1 6
> > >> > 1 7
> > >> > 1 8
> > >> >
> > >> >
> > >> > Packets dropped on Transmit:
> > >> > BPDU packets: 0
> > >> >
> > >> > queue dropped [cos-map]
> > >> > ---------------------------------------------
> > >> >
> > >> > 1 295660 [0 1 ]
> > >> > 2 0 [2 3 4 ]
> > >> > 3 0 [6 7 ]
> > >> > 4 0 [5 ]
> > >> >
> > >> > Packets dropped on Receive:
> > >> > BPDU packets: 0
> > >> >
> > >> > queue dropped [cos-map]
> > >> > ---------------------------------------------
> > >> > 1 0 [0 1 2 3 4 5 6 7 ]
> > >> >
> > >> > Now i can increase the queue limit but that will add delay to the
> > >> > packets
> > >> > sitting in the queue and can lead to other issues. Pls suggest.
> > >> >
> > >> > thanks
> > >> > naman
> > >> >
> > >> > On 4 May 2010 11:36, Marko Milivojevic <markom_at_ipexpert.com>
> wrote:
> > >> >>
> > >> >> You are absolutely right... If it's indeed GigE speed we're
> talking
> > >> >> about here. However, we only have the information that interface
> > >> >> itself is GigE, but as we know, we have those "10/100/1000"
> > interfaces
> > >> >> - they are prone to this kind of thing.
> > >> >>
> > >> >> If it's GigE speed on the link, then I would personally look at
> QoS
> > >> >> and especially flow-control, as personally I had quite a few
> issues
> > >> >> with it and Cisco swouters.
> > >> >>
> > >> >> --
> > >> >> Marko Milivojevic - CCIE #18427
> > >> >> Senior Technical Instructor - IPexpert
> > >> >>
> > >> >> YES! We include 400 hours of REAL rack
> > >> >> time with our Blended Learning Solution!
> > >> >>
> > >> >> Mailto: markom_at_ipexpert.com
> > >> >> Telephone: +1.810.326.1444
> > >> >> Fax: +1.810.454.0130
> > >> >> Web: http://www.ipexpert.com/
> > >> >>
> > >> >> On Tue, May 4, 2010 at 18:32, Ryan West <rwest_at_zyedge.com>
> wrote:
> > >> >> > Hey Marko,
> > >> >> >
> > >> >> >> -----Original Message-----
> > >> >> >> Sent: Tuesday, May 04, 2010 2:16 PM
> > >> >> >> To: Narbik Kocharians
> > >> >> >> Cc: itguy.pro_at_gmail.com; Kambiz Agahian; naman sharma; Cisco
> > >> >> >> certification
> > >> >> >> Subject: Re: Output Drops on Gig Interface
> > >> >> >>
> > >> >> >> On Tue, May 4, 2010 at 17:39, Narbik Kocharians <
> > narbikk_at_gmail.com>
> > >> >> >> wrote:
> > >> >> >> > That is true, the end that is in half Duplex mode should
> get
> > "late
> > >> >> >> > collisions" and the end that is in full duplex mode should
> get
> > >> >> >> > "CRC
> > >> >> >> > checks",
> > >> >> >> > whereas, a mismatch in Speed (Which i don't think that
> could be
> > >> >> >> > the
> > >> >> >> > problem
> > >> >> >> > that you are experiencing) should show as "NOTCONNECTED".
> > >> >> >>
> > >> >> >> Quite right, however, if duplex is not hardcoded, but speed
> is, it
> > >> >> >> would not be negotiated in most cases. Cisco used to default
> to
> > >> >> >> half-duplex in this case. I've seen quite a few issues caused
> by
> > >> >> >> configuring only parts of the speed/duplex pair.
> > >> >> >>
> > >> >> >> If any of them is set manually, negotiation is disabled. To
> > >> >> >> negotiate
> > >> >> >> speed and duplex, both need to be set to auto.
> > >> >> >>
> > >> >> >
> > >> >> > It was my understanding that by default, all devices are
> supposed
> > to
> > >> >> > perform autonegotiation as 802.3z does not specifically define
> a
> > way
> > >> >> > to turn
> > >> >> > it off. Also, Cisco devices do not support half-duplex Gig
> and the
> > >> >> > standard
> > >> >> > does not have support for it either. With link negotiation
> turned
> > >> >> > off, the
> > >> >> > device with autonegotiation turned off will report up and the
> other
> > >> >> > side
> > >> >> > will be down.
> > >> >> >
> > >> >> > I have not tested all of these scenario's in great detail, so
> in
> > >> >> > practice it might differ slightly.
> > >> >> >
> > >> >> > -ryan
>
>
> 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 Wed May 05 2010 - 13:36:25 ART