[c-nsp] slow convergence for full bgp table on aCisco7613/SUP720-3BXL
lee.e.rian at census.gov
lee.e.rian at census.gov
Tue Mar 13 15:36:20 EST 2007
Are you sure the 10gig port is working correctly? Have you tried a
different port on the card or moving the card to a different slot in the
chassis?
I've had at least two TAC cases where the switch was dropping packets and
the interface counters showed hardly any errors. The explanation I got
from TAC was that only errors that are attributable to a specific port
increment the port error counters. Errors that happened elsewhere - like
going between asics or to the backplane couldn't be attributed to any
specific port so they were basically ignored.
A 7600 is about the same as a 6500 - right? If so and your 10gig port is
on a WS-X6704-10GE card try doing
remote command switch show platform hardware asicreg titan slot 10 port 3
error
remote command switch show platform hardware asicreg super slot 10 port 3
error
If anything comes back with a non-zero value include the output from the
command in your TAC case.
Regards,
Lee
"Church, Charles" <cchurch at multimax.com> wrote on 03/13/2007 03:12:23 PM:
> Are you sure the problem isn't on the other end? You've sent about 2
> million control packets, and half of those have been retransmits.
> Almost all your acks you're sending are being delayed too. It sure
> seems like TCP is the issue. Are these 'bad' counters still
> incrementing? Is the other side doing any policing?
>
> Chuck
>
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Emanuel Popa
> Sent: Tuesday, March 13, 2007 1:41 PM
> To: Oliver Boehmer (oboehmer)
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] slow convergence for full bgp table on
> aCisco7613/SUP720-3BXL
>
> We can clear the bgp session only tomorrow morning when traffic level is
> pretty low. This means 14 hours from now. We will monitor SPD drops in
> the morning but i don't think we are going to notice anything
> interesting.
>
> Regarding tcp stats, do you mean:
>
> br01.frankfurt#sh tcp stat
> Rcvd: 71476208 Total, 2530 no port
> 385 checksum error, 18 bad offset, 0 too short
> 44865801 packets (1625121834 bytes) in sequence
> 1113216 dup packets (38655517 bytes)
> 982 partially dup packets (341189 bytes)
> 153829 out-of-order packets (131849235 bytes)
> 2 packets (1882 bytes) with data after window
> 145 packets after close
> 1 window probe packets, 73202 window update packets
> 3955 dup ack packets, 0 ack packets with unsend data
> 24945059 ack packets (1360941754 bytes)
> Sent: 71782281 Total, 1 urgent packets
> 2023467 control packets (including 1014567 retransmitted)
> 25824879 data packets (1360984359 bytes)
> 287631 data packets (19095511 bytes) retransmitted
> 244 data packets (93857 bytes) fastretransmitted
> 43188396 ack only packets (38453293 delayed)
> 7 window probe packets, 457732 window update packets
> 337116 Connections initiated, 4909 connections accepted, 3852
> connections established
> 342321 Connections closed (including 946 dropped, 336762 embryonic
> dropped)
> 1302198 Total rxmt timeout, 0 connections dropped in rxmt timeout
> 99 Keepalive timeout, 9488 keepalive probe, 0 Connections dropped in
> keepalive
>
> Both peers changed everything on their ends: equipment, vendor,
> interface etc. One of them changed from Juniper to Cisco and this
> becomes pretty confusing. It would be a hell of a coincidence that they
> both have the same problem with the config towards our machine.
> I'm positive that the issue is generated on our gear. I just don't know
> how to deal with it. Me and my colleagues have tried everything.
> Now we are waiting for the case to reach cisco TAC.
>
> Good evening,
> Emanuel
>
>
> On 3/13/07, Oliver Boehmer (oboehmer) <oboehmer at cisco.com> wrote:
> > Can you find out if you indeed see any SPD drops when you converge, or
>
> > if those SPD drops where from something else (i.e. Internet background
>
> > noise or something like this).
> > But I don't think this is an input/SPD drop issue, if you had this
> > problem, you would have noticed it with 2x1GE already.
> > Can you check the TCP stats at both sides? Did your peer change
> > something on his end except the interface? It's really weird.
> >
> > oli
> >
> > Emanuel Popa <mailto:emanuel.popa at gmail.com> wrote on Tuesday, March
> > 13,
> > 2007 6:03 PM:
> >
> > > the headromm has the default value.
> > >
> > > br01.frankfurt#sh ip spd
> > > Current mode: normal.
> > > Queue min/max thresholds: 73/74, Headroom: 1000, Extended Headroom:
> > > 10 IP normal queue: 1, priority queue: 0.
> > > SPD special drop mode: none
> > >
> > > please tell me in what scenario whould your commands help me with my
>
> > > issue?
> > >
> > > regards,
> > > emanuel
> > >
> > > On 3/13/07, Oliver Boehmer (oboehmer) <oboehmer at cisco.com> wrote:
> > >> Emanuel Popa <> wrote on Tuesday, March 13, 2007 3:33 PM:
> > >>
> > >>> Ytti,
> > >>>
> > >>> Here is the output:
> > >>> br01.frankfurt#sh int te 10/3 | i Input queue
> > >>> Input queue: 0/75/109/109 (size/max/drops/flushes); Total output
> > >>> drops: 0
> > >>>
> > >>> But:
> > >>>
> > >>> - routing protocol packets are not dropped when default hold queue
>
> > >>> of 75 is full; they are considered priority packets and they are
> > >>> dropped after headroom of 1000 is full; please see
> > >>>
> > >>
> > http://www.cisco.com/en/US/products/hw/routers/ps167/products_tech_not
> > e0
> > >> 9186a008012fb87.shtml
> > >>> for more details
> > >>>
> > >>
> > >> how's your headroom? What does "show spd" tell you?
> > >>
> > >> ip spd queue max-threshold 999
> > >> ip spd queue min-threshold 998
> > >>
> > >> might help..
> > >>
> > >> oli
> >
> _______________________________________________
> 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