[c-nsp] "Packets dropped to the next slow path"
Vincent De Keyzer
vincent at dekeyzer.net
Mon Nov 21 10:52:52 EST 2005
Ok,
looking at the list archive (which I should have done right from the start,
shame on me), I see that this could be due to a feature not supported by
CEF.
> interface Serial6/0:0
> mac-address 0014.a862.b71b
> ip address 10.11.130.33 255.255.255.224 secondary
> ip address 10.11.133.1 255.255.255.224 secondary
> ip address x.y.z.5 255.255.255.252
> ip verify unicast reverse-path
> no ip redirects
> no ip unreachables
> no ip proxy-arp
> encapsulation ppp
> load-interval 30
> no fair-queue
> no cdp enable
> ppp bridge ip
> end
What is it? PPP half-bridging? How do I find out?
Vincent
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> bounces at puck.nether.net] On Behalf Of Vincent De Keyzer
> Sent: lundi 21 novembre 2005 15:51
> To: 'Ray Burkholder'
> Cc: cisco-nsp at puck.nether.net
> Subject: RE: [c-nsp] "Packets dropped to the next slow path"
>
> There is a show interface at the bottom of the mail; but I don't think
> it's
> a QoS problem, because problem started when this customer was moved from
> one
> router to another. For me it's more CEF-related - packets not being
> CEF-switched, but I'm not sure.
>
> Vincent
>
> > -----Original Message-----
> > From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> > bounces at puck.nether.net] On Behalf Of Ray Burkholder
> > Sent: lundi 21 novembre 2005 15:42
> > To: Vincent De Keyzer
> > Cc: cisco-nsp at puck.nether.net
> > Subject: Re: [c-nsp] "Packets dropped to the next slow path"
> >
> > How much traffic is going through the interface? Can you do a show
> > interface?
> > Voice is Delay and drop sensitive. There are a number of commands for
> > properly
> > grooming voice traffic if this is a QoS issue.
> >
> > Quoting Vincent De Keyzer <vincent at dekeyzer.net>:
> >
> > > Hello,
> > >
> > >
> > >
> > > I have a customer complaining of micro-cuts during his (VoIP) phone
> > > conversations.
> > >
> > >
> > >
> > > Here is the config of his interface:
> > >
> > >
> > >
> > > interface Serial6/0:0
> > >
> > > mac-address 0014.a862.b71b
> > >
> > > ip address 10.11.130.33 255.255.255.224 secondary
> > >
> > > ip address 10.11.133.1 255.255.255.224 secondary
> > >
> > > ip address x.y.z.5 255.255.255.252
> > >
> > > ip verify unicast reverse-path
> > >
> > > no ip redirects
> > >
> > > no ip unreachables
> > >
> > > no ip proxy-arp
> > >
> > > encapsulation ppp
> > >
> > > load-interval 30
> > >
> > > no fair-queue
> > >
> > > no cdp enable
> > >
> > > ppp bridge ip
> > >
> > > end
> > >
> > >
> > >
> > > We already had similar problems a few months ago, and it was due to an
> > > interface not being CEF-enabled - every second, the BGP scanner
> process
> > > would use a lot of CPU, and delay packets being processed centrally.
> > >
> > >
> > >
> > > Having that in mind, I looked at "sh cef interface":
> > >
> > >
> > >
> > > BRULEOro72#sh cef interface serial 6/0:0
> > >
> > > Serial6/0:0 is up (if_number 59)
> > >
> > > Corresponding hwidb fast_if_number 59
> > >
> > > Corresponding hwidb firstsw->if_number 59
> > >
> > > Internet address is x.y.z.5/30
> > >
> > > Secondary address 10.11.130.33/27
> > >
> > > Secondary address 10.11.133.1/27
> > >
> > > ICMP redirects are never sent
> > >
> > > Per packet load-sharing is disabled
> > >
> > > IP unicast RPF check is enabled
> > >
> > > Input features: Verify Unicast Reverse-Path
> > >
> > > Inbound access list is not set
> > >
> > > Outbound access list is not set
> > >
> > > IP policy routing is disabled
> > >
> > > BGP based policy accounting on input is disabled
> > >
> > > BGP based policy accounting on output is disabled
> > >
> > > Interface is marked as point to point interface
> > >
> > > IPv4 packets switched to this interface are dropped to the next slow
> > path:
> > > PPP - not open
> > >
> > > Hardware idb is Serial6/0:0
> > >
> > > Fast switching type 7, interface type 13
> > >
> > > IP CEF switching enabled
> > >
> > > IP CEF switching turbo vector
> > >
> > > IP CEF turbo switching turbo vector
> > >
> > > IP prefix lookup IPv4 mtrie 8-8-8-8 optimized
> > >
> > > Input fast flags 0x4000, Output fast flags 0x0
> > >
> > > ifindex 11(11)
> > >
> > > Slot 6 Slot unit 0 VC 0
> > >
> > > Transmit limit accumulator 0x0 (0x0)
> > >
> > > IP MTU 1500
> > >
> > >
> > >
> > > It's the "IPv4 packets switched to this interface are dropped to the
> > next
> > > slow path: PPP - not open" that worries me: what does this mean ? Are
> > the
> > > packets CEF-switched, or not ?
> > >
> > >
> > >
> > > PPP seems to be up:
> > >
> > >
> > >
> > > BRULEOro72#sh interfaces s6/0:0
> > >
> > > Serial6/0:0 is up, line protocol is up
> > >
> > > Hardware is Multichannel E1
> > >
> > > Internet address is x.y.z.5/30
> > >
> > > MTU 1500 bytes, BW 1984 Kbit, DLY 20000 usec,
> > >
> > > reliability 255/255, txload 20/255, rxload 177/255
> > >
> > > Encapsulation PPP, crc 16, Data non-inverted
> > >
> > > Keepalive set (10 sec)
> > >
> > > ARP type: ARPA, ARP Timeout 04:00:00
> > >
> > > LCP Open
> > >
> > > Open: BRIDGECP
> > >
> > > Last input 3d15h, output 00:00:00, output hang never
> > >
> > > Last clearing of "show interface" counters 3d18h
> > >
> > > Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops:
> > 2565
> > >
> > > Queueing strategy: fifo
> > >
> > > Output queue: 0/40 (size/max)
> > >
> > > 30 second input rate 1381000 bits/sec, 172 packets/sec
> > >
> > > 30 second output rate 157000 bits/sec, 132 packets/sec
> > >
> > > 3059499 packets input, 1503754010 bytes, 0 no buffer
> > >
> > > Received 0 broadcasts (0 IP multicast)
> > >
> > > 0 runts, 0 giants, 0 throttles
> > >
> > > 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
> > >
> > > 2965137 packets output, 2160279388 bytes, 0 underruns
> > >
> > > 0 output errors, 0 collisions, 0 interface resets
> > >
> > > 0 output buffer failures, 0 output buffers swapped out
> > >
> > > 0 carrier transitions
> > >
> > > no alarm present
> > >
> > > Timeslot(s) Used:1-31, subrate: 64Kb/s, transmit delay is 0 flags
> > >
> > >
> > >
> > > This is 12.2(25)S4 on a 7206VXR.
> > >
> > >
> > >
> > > Vincent
> > >
> > > _______________________________________________
> > > cisco-nsp mailing list cisco-nsp at puck.nether.net
> > > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > > archive at http://puck.nether.net/pipermail/cisco-nsp/
> > >
> > > --
> > > Scanned for viruses and dangerous content at
> > > http://www.oneunified.net and is believed to be clean.
> > >
> > >
> >
> >
> > --
> > Ray Burkholder
> > http://www.oneunified.net
> > ray at oneunified.net
> > 441 505 7293
> >
> > -------------------------------------------------
> > Sent from http://www.oneunified.net via IMP: http://horde.org/imp/
> >
> > --
> > Scanned for viruses and dangerous content at
> > http://www.oneunified.net and is believed to be clean.
> >
> > _______________________________________________
> > cisco-nsp mailing list cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
>
> _______________________________________________
> cisco-nsp mailing list cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
More information about the cisco-nsp
mailing list