Re: Output Drops on Gig Interface

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
Received on Tue May 04 2010 - 12:09:24 ART