Mailing List Archive: Cisco: NSP

7606 to 6509 [BGP hold time issue]

Index | Next | Previous | View Threaded

Kieron.Scantlebury at level3

May 3, 2012, 7:55 AM

Post #1 of 12 (1243 views)
Permalink

7606 to 6509 [BGP hold time issue]

Hi Guru's

I have a Cisco 7606-S with a 1 gig DIA link to our customers Cisco 6509 switch.
This is directly connected just a few cabinets down in the same COLO.

The link is stable and we have no errors.

The problem we are seeing is that BGP is getting ripped down 3 minute (hold timer) - See below

*FYI - The obvious has been checked. Hold timers match on each device. Tried adjusting MTU etc...

May 3 05:00:10.490 BST: %BGP-5-ADJCHANGE: neighbor *** .***.***.*** Up
May 3 05:03:11.302 BST: %BGP-5-ADJCHANGE: neighbor *** .***.***.*** Down BGP Notification sent
May 3 05:00:00.866 BST: %BGP-3-NOTIFICATION: sent to neighbor *** .***.***.*** 4/0 (hold time expired) 0 bytes

I have done a few packet captures. It appears that the customers 6509 isn't acknowledging the BGP update packets and so our ASR try's to re-transmit packets (that are above 1300 bytes +) again and again. The customer is unable to do a PCAP so I cant Guarantee that the update packet is hitting his device.

The customer requires the full routing table. Some 39000+ routes. BGP only drops when sending this table. If I limit these advertisements to say 1.23.0.0/16 le 32 the BGP stays stable. If I advertise a full 1.0.0.0/8 le 32 then it becomes unstable again.

We do have a known issue on our 7606 at the moment, TCAM is full. This issue is being resolved this coming weekend. However I don't believe that this will be the cause of our BGP issue. Unless of course this issue is effecting the overall performance of our router. (That's for another team to worry about :))

An idea that's been thrown around is that the customers 6509 doesn't have enough memory to support the full routing table. Here are some outputs from his switch.

#####show proc mem | i BGP Router
396 0 4160646648 3294746732 284982876 0 0 BGP Router

#####show ip bgp summary
408443 network entries using 48196274 bytes of memory

#####show version
cisco WS-C6503-E (R7000) processor (revision 1.3) with 983008K/65536K bytes of memory.
Processor board ID FOX1350GH8H
SR71000 CPU at 600Mhz, Implementation 0x504, Rev 1.2, 512KB L2 Cache
Last reset from s/w reset
9 Virtual Ethernet interfaces
66 Gigabit Ethernet interfaces
1917K bytes of non-volatile configuration memory.
8192K bytes of packet buffer memory.

65536K bytes of Flash internal SIMM (Sector size 512K).
Configuration register is 0x2102

Also, There is nothing in their logs to indicate a memory issue.

Any further ideas would be appreciated.

Many Thanks in advance.
Kieron

_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

scott at granados-llc

May 3, 2012, 8:13 AM

Post #2 of 12 (1171 views)
Permalink

Re: 7606 to 6509 [BGP hold time issue] [In reply to]

You have an MTU mismatch.:)

THis is my guess anyway because it really matches closely your issue.

I ran in to this with almost the same set up using larger MTU sizes for the ethernet + tags. I had to use the IP MTU command under the actual interface (or subiff depending) and set to 1500.

You can easily tell by
show ip bgp nei a.b.c.d | inc data

look at the segment size and make sure that it makes with the MTU you have set including overhead.

In my case, I was getting number greater than 1460 which in my setup I knew wouldn't fly.

Hope that helps.

Thanks
Scott

On May 3, 2012, at 10:55 AM, Scantlebury, Kieron wrote:

> Hi Guru's
>
> I have a Cisco 7606-S with a 1 gig DIA link to our customers Cisco 6509 switch.
> This is directly connected just a few cabinets down in the same COLO.
>
> The link is stable and we have no errors.
>
> The problem we are seeing is that BGP is getting ripped down 3 minute (hold timer) - See below
>
> *FYI - The obvious has been checked. Hold timers match on each device. Tried adjusting MTU etc...
>
> May 3 05:00:10.490 BST: %BGP-5-ADJCHANGE: neighbor *** .***.***.*** Up
> May 3 05:03:11.302 BST: %BGP-5-ADJCHANGE: neighbor *** .***.***.*** Down BGP Notification sent
> May 3 05:00:00.866 BST: %BGP-3-NOTIFICATION: sent to neighbor *** .***.***.*** 4/0 (hold time expired) 0 bytes
>
> I have done a few packet captures. It appears that the customers 6509 isn't acknowledging the BGP update packets and so our ASR try's to re-transmit packets (that are above 1300 bytes +) again and again. The customer is unable to do a PCAP so I cant Guarantee that the update packet is hitting his device.
>
> The customer requires the full routing table. Some 39000+ routes. BGP only drops when sending this table. If I limit these advertisements to say 1.23.0.0/16 le 32 the BGP stays stable. If I advertise a full 1.0.0.0/8 le 32 then it becomes unstable again.
>
> We do have a known issue on our 7606 at the moment, TCAM is full. This issue is being resolved this coming weekend. However I don't believe that this will be the cause of our BGP issue. Unless of course this issue is effecting the overall performance of our router. (That's for another team to worry about :))
>
> An idea that's been thrown around is that the customers 6509 doesn't have enough memory to support the full routing table. Here are some outputs from his switch.
>
> #####show proc mem | i BGP Router
> 396 0 4160646648 3294746732 284982876 0 0 BGP Router
>
> #####show ip bgp summary
> 408443 network entries using 48196274 bytes of memory
>
>
> #####show version
> cisco WS-C6503-E (R7000) processor (revision 1.3) with 983008K/65536K bytes of memory.
> Processor board ID FOX1350GH8H
> SR71000 CPU at 600Mhz, Implementation 0x504, Rev 1.2, 512KB L2 Cache
> Last reset from s/w reset
> 9 Virtual Ethernet interfaces
> 66 Gigabit Ethernet interfaces
> 1917K bytes of non-volatile configuration memory.
> 8192K bytes of packet buffer memory.
>
> 65536K bytes of Flash internal SIMM (Sector size 512K).
> Configuration register is 0x2102
>
> Also, There is nothing in their logs to indicate a memory issue.
>
> Any further ideas would be appreciated.
>
> Many Thanks in advance.
> Kieron
>
>
>
>
> _______________________________________________
> cisco-nsp mailing list cisco-nsp [at] puck
> 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
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

petelists at templin

May 3, 2012, 8:59 AM

Post #3 of 12 (1165 views)
Permalink

Re: 7606 to 6509 [BGP hold time issue] [In reply to]

On 5/3/2012 10:13 AM, Scott Granados wrote:
> You have an MTU mismatch.:)
>
> THis is my guess anyway because it really matches closely your issue.

+1, or perhaps you have an MTU problem on the underlying transport (both
ROUTERS agree on MTU, but the underlying circuit won't pass a full-sized
packet). Since the hellos aren't padded to full MTU, single-route
updates aren't big enough to fill a packet, etc., you don't trip the
issue unless you need to send more than about 5 routes to them (I often
saw #routes/#updates = ~5 as a customer).

pt

_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Kieron.Scantlebury at Level3

May 3, 2012, 9:11 AM

Post #4 of 12 (1172 views)
Permalink

Re: 7606 to 6509 [BGP hold time issue] [In reply to]

We matched MTU. It was one of the first things we attempted. We also lowered MTU to 1280 both ends. No change.

-----Original Message-----
From: Scott Granados [mailto:scott [at] granados-llc]
Sent: 03 May 2012 16:14
To: Scantlebury, Kieron
Cc: cisco-nsp [at] puck
Subject: Re: [c-nsp] 7606 to 6509 [BGP hold time issue]

You have an MTU mismatch.:)

THis is my guess anyway because it really matches closely your issue.

I ran in to this with almost the same set up using larger MTU sizes for the ethernet + tags. I had to use the IP MTU command under the actual interface (or subiff depending) and set to 1500.

You can easily tell by
show ip bgp nei a.b.c.d | inc data

look at the segment size and make sure that it makes with the MTU you have set including overhead.

In my case, I was getting number greater than 1460 which in my setup I knew wouldn't fly.

Hope that helps.

Thanks
Scott

On May 3, 2012, at 10:55 AM, Scantlebury, Kieron wrote:

> Hi Guru's
>
> I have a Cisco 7606-S with a 1 gig DIA link to our customers Cisco 6509 switch.
> This is directly connected just a few cabinets down in the same COLO.
>
> The link is stable and we have no errors.
>
> The problem we are seeing is that BGP is getting ripped down 3 minute
> (hold timer) - See below
>
> *FYI - The obvious has been checked. Hold timers match on each device. Tried adjusting MTU etc...
>
> May 3 05:00:10.490 BST: %BGP-5-ADJCHANGE: neighbor *** .***.***.***
> Up May 3 05:03:11.302 BST: %BGP-5-ADJCHANGE: neighbor ***
> .***.***.*** Down BGP Notification sent May 3 05:00:00.866 BST:
> %BGP-3-NOTIFICATION: sent to neighbor *** .***.***.*** 4/0 (hold time
> expired) 0 bytes
>
> I have done a few packet captures. It appears that the customers 6509 isn't acknowledging the BGP update packets and so our ASR try's to re-transmit packets (that are above 1300 bytes +) again and again. The customer is unable to do a PCAP so I cant Guarantee that the update packet is hitting his device.
>
> The customer requires the full routing table. Some 39000+ routes. BGP only drops when sending this table. If I limit these advertisements to say 1.23.0.0/16 le 32 the BGP stays stable. If I advertise a full 1.0.0.0/8 le 32 then it becomes unstable again.
>
> We do have a known issue on our 7606 at the moment, TCAM is full. This
> issue is being resolved this coming weekend. However I don't believe
> that this will be the cause of our BGP issue. Unless of course this
> issue is effecting the overall performance of our router. (That's for
> another team to worry about :))
>
> An idea that's been thrown around is that the customers 6509 doesn't have enough memory to support the full routing table. Here are some outputs from his switch.
>
> #####show proc mem | i BGP Router
> 396 0 4160646648 3294746732 284982876 0 0 BGP Router
>
> #####show ip bgp summary
> 408443 network entries using 48196274 bytes of memory
>
>
> #####show version
> cisco WS-C6503-E (R7000) processor (revision 1.3) with 983008K/65536K bytes of memory.
> Processor board ID FOX1350GH8H
> SR71000 CPU at 600Mhz, Implementation 0x504, Rev 1.2, 512KB L2 Cache
> Last reset from s/w reset
> 9 Virtual Ethernet interfaces
> 66 Gigabit Ethernet interfaces
> 1917K bytes of non-volatile configuration memory.
> 8192K bytes of packet buffer memory.
>
> 65536K bytes of Flash internal SIMM (Sector size 512K).
> Configuration register is 0x2102
>
> Also, There is nothing in their logs to indicate a memory issue.
>
> Any further ideas would be appreciated.
>
> Many Thanks in advance.
> Kieron
>
>
>
>
> _______________________________________________
> cisco-nsp mailing list cisco-nsp [at] puck
> 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
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

p.mayers at imperial

May 3, 2012, 9:36 AM

Post #5 of 12 (1164 views)
Permalink

Re: 7606 to 6509 [BGP hold time issue] [In reply to]

On 03/05/12 17:11, Scantlebury, Kieron wrote:
> We matched MTU. It was one of the first things we attempted. We also
> lowered MTU to 1280 both ends. No change.

Have you TESTED the MTU? Setting it is all fine and well, but this
really, really sounds like an MTU problem.

You want to use ping with "don't frag" set:

ping ip <dst> df-bit size 1500

The other thing could be some kind of firewall filter, or possibly CoPP
at the far end - if the far end has aggressive CoPP, a small amount of
BGP traffic might work, but a lot might get dropped. However, I'd be
surprised if this effect causes problems for long enough to let holdtime
expire.
_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

nick.kritsky at gmail

May 3, 2012, 11:46 AM

Post #6 of 12 (1163 views)
Permalink

Re: 7606 to 6509 [BGP hold time issue] [In reply to]

Is PMTUD enabled for this peer? Did you try to disable it?
Such behavior can also be explained by misbehaving active inline IPS
or firewall with crappy ALG, but I understand that you are using
direct link - right? No switches in between?

Nick

On Thu, May 3, 2012 at 8:36 PM, Phil Mayers <p.mayers [at] imperial> wrote:
> On 03/05/12 17:11, Scantlebury, Kieron wrote:
>>
>> We matched MTU. It was one of the first things we attempted. We also
>> lowered MTU to 1280 both ends. No change.
>
>
> Have you TESTED the MTU? Setting it is all fine and well, but this really,
> really sounds like an MTU problem.
>
> You want to use ping with "don't frag" set:
>
> ping ip <dst> df-bit size 1500
>
>
> The other thing could be some kind of firewall filter, or possibly CoPP at
> the far end - if the far end has aggressive CoPP, a small amount of BGP
> traffic might work, but a lot might get dropped. However, I'd be surprised
> if this effect causes problems for long enough to let holdtime expire.
>
> _______________________________________________
> cisco-nsp mailing list �cisco-nsp [at] puck
> 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
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Kieron.Scantlebury at Level3

May 4, 2012, 12:07 AM

Post #7 of 12 (1145 views)
Permalink

Re: 7606 to 6509 [BGP hold time issue] [In reply to]

Correct. No switches in between. Direct connection.

-----Original Message-----
From: cisco-nsp-bounces [at] puck [mailto:cisco-nsp-bounces [at] puck] On Behalf Of Nick Kritsky
Sent: 03 May 2012 19:47
To: Phil Mayers
Cc: cisco-nsp [at] puck
Subject: Re: [c-nsp] 7606 to 6509 [BGP hold time issue]

Is PMTUD enabled for this peer? Did you try to disable it?
Such behavior can also be explained by misbehaving active inline IPS or firewall with crappy ALG, but I understand that you are using direct link - right? No switches in between?

Nick

On Thu, May 3, 2012 at 8:36 PM, Phil Mayers <p.mayers [at] imperial> wrote:
> On 03/05/12 17:11, Scantlebury, Kieron wrote:
>>
>> We matched MTU. It was one of the first things we attempted. We also
>> lowered MTU to 1280 both ends. No change.
>
>
> Have you TESTED the MTU? Setting it is all fine and well, but this
> really, really sounds like an MTU problem.
>
> You want to use ping with "don't frag" set:
>
> ping ip <dst> df-bit size 1500
>
>
> The other thing could be some kind of firewall filter, or possibly
> CoPP at the far end - if the far end has aggressive CoPP, a small
> amount of BGP traffic might work, but a lot might get dropped.
> However, I'd be surprised if this effect causes problems for long enough to let holdtime expire.
>
> _______________________________________________
> cisco-nsp mailing list �cisco-nsp [at] puck
> 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 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
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

mack.mcbride at viawest

May 4, 2012, 10:03 AM

Post #8 of 12 (1146 views)
Permalink

Re: 7606 to 6509 [BGP hold time issue] [In reply to]

A couple of things come to mind.
1) does the 6500 or 7600 have COPP (previously mentioned)
2) does the 6500 or 7600 have uRPF enabled?
3) the route table being full on the 7600 could be causing the issue (interacts badly with uRPF and many other things)
4) Have you done BGP debugs on either device?
5) Are the interfaces between the devices error free?

LR Mack McBride

-----Original Message-----
From: cisco-nsp-bounces [at] puck [mailto:cisco-nsp-bounces [at] puck] On Behalf Of Scantlebury, Kieron
Sent: Friday, May 04, 2012 1:08 AM
To: Nick Kritsky; Phil Mayers
Cc: cisco-nsp [at] puck
Subject: Re: [c-nsp] 7606 to 6509 [BGP hold time issue]

Correct. No switches in between. Direct connection.

-----Original Message-----
From: cisco-nsp-bounces [at] puck [mailto:cisco-nsp-bounces [at] puck] On Behalf Of Nick Kritsky
Sent: 03 May 2012 19:47
To: Phil Mayers
Cc: cisco-nsp [at] puck
Subject: Re: [c-nsp] 7606 to 6509 [BGP hold time issue]

Is PMTUD enabled for this peer? Did you try to disable it?
Such behavior can also be explained by misbehaving active inline IPS or firewall with crappy ALG, but I understand that you are using direct link - right? No switches in between?

Nick

On Thu, May 3, 2012 at 8:36 PM, Phil Mayers <p.mayers [at] imperial> wrote:
> On 03/05/12 17:11, Scantlebury, Kieron wrote:
>>
>> We matched MTU. It was one of the first things we attempted. We also
>> lowered MTU to 1280 both ends. No change.
>
>
> Have you TESTED the MTU? Setting it is all fine and well, but this
> really, really sounds like an MTU problem.
>
> You want to use ping with "don't frag" set:
>
> ping ip <dst> df-bit size 1500
>
>
> The other thing could be some kind of firewall filter, or possibly
> CoPP at the far end - if the far end has aggressive CoPP, a small
> amount of BGP traffic might work, but a lot might get dropped.
> However, I'd be surprised if this effect causes problems for long enough to let holdtime expire.
>
> _______________________________________________
> cisco-nsp mailing list �cisco-nsp [at] puck
> 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 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 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
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

ismath.shaan at gmail

May 4, 2012, 3:13 PM

Post #9 of 12 (1138 views)
Permalink

7606 to 6509 [BGP hold time issue] [In reply to]

During the 3 minutes of the session holding up, do you see any packets in
the OutQ (show ip bgp summ)

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down
State/PfxRcd
172.16.2.1 4 64900 1754971 1714093 1406547 0 0
7w2d 8

As has been fairly pointed out, it looks like your 'fat' update packets are
likely dropped by either an MTU mismatch or a CoPP filter on the other
side. Its hard to know either way without further debugging (debug ip bgp
update) run during your off-hours

Shaan
_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Kieron.Scantlebury at Level3

May 8, 2012, 2:59 AM

Post #10 of 12 (1095 views)
Permalink

Re: 7606 to 6509 [BGP hold time issue] [In reply to]

MTU's been checked and confirmed on numerous occasions with the customer. Their control plane has no policing.

FYI. He has numerous other connections to the same device all receiving a full routing table and they all work fine. Its just our connection that's having the issue.

Its driving me round the bend :)

Cheers
Kieron

-----Original Message-----
From: cisco-nsp-bounces [at] puck [mailto:cisco-nsp-bounces [at] puck] On Behalf Of Shanawaz Batcha
Sent: 04 May 2012 23:14
To: cisco-nsp [at] puck
Subject: [c-nsp] 7606 to 6509 [BGP hold time issue]

During the 3 minutes of the session holding up, do you see any packets in the OutQ (show ip bgp summ)

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down
State/PfxRcd
172.16.2.1 4 64900 1754971 1714093 1406547 0 0
7w2d 8

As has been fairly pointed out, it looks like your 'fat' update packets are likely dropped by either an MTU mismatch or a CoPP filter on the other side. Its hard to know either way without further debugging (debug ip bgp
update) run during your off-hours

Shaan
_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck 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
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

ismath.shaan at gmail

May 8, 2012, 5:15 AM

Post #11 of 12 (1090 views)
Permalink

Re: 7606 to 6509 [BGP hold time issue] [In reply to]

Now that you are confident you have tried a lower MTU setting
satisfactorily, just revisiting a couple of points mentioned by others (at
the cost of sounding repetitive but always good to check)

1. Is BGP MSS or PMTUD explicitly set on either side? have you tried
disabling them
2. Is BGP max prefix set on the other side ?

On Tue, May 8, 2012 at 7:59 PM, Scantlebury, Kieron <
Kieron.Scantlebury [at] level3> wrote:

>
> MTU's been checked and confirmed on numerous occasions with the customer.
> Their control plane has no policing.
>
> FYI. He has numerous other connections to the same device all receiving a
> full routing table and they all work fine. Its just our connection that's
> having the issue.
>
> Its driving me round the bend :)
>
> Cheers
> Kieron
>
> -----Original Message-----
> From: cisco-nsp-bounces [at] puck [mailto:
> cisco-nsp-bounces [at] puck] On Behalf Of Shanawaz Batcha
> Sent: 04 May 2012 23:14
> To: cisco-nsp [at] puck
> Subject: [c-nsp] 7606 to 6509 [BGP hold time issue]
>
> During the 3 minutes of the session holding up, do you see any packets in
> the OutQ (show ip bgp summ)
>
> Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down
> State/PfxRcd
> 172.16.2.1 4 64900 1754971 1714093 1406547 0 0
> 7w2d 8
>
> As has been fairly pointed out, it looks like your 'fat' update packets
> are likely dropped by either an MTU mismatch or a CoPP filter on the other
> side. Its hard to know either way without further debugging (debug ip bgp
> update) run during your off-hours
>
> Shaan
> _______________________________________________
> cisco-nsp mailing list cisco-nsp [at] puck
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

--
�Twenty years from now you will be more disappointed by the things that you
didn't do than by the ones you did do. So throw off the bowlines. Sail away
from the safe harbor. Catch the trade winds in your sails. Explore. Dream.
Discover.�
_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Kieron.Scantlebury at Level3

May 9, 2012, 2:31 AM

Post #12 of 12 (1096 views)
Permalink

Re: 7606 to 6509 [BGP hold time issue] [In reply to]

FYI to all involved. This has been resolved. Moved physical cabling to a new port on our ASR and like magic. Sorted.

From: Shanawaz Batcha [mailto:ismath.shaan [at] gmail]
Sent: 08 May 2012 13:15
To: Scantlebury, Kieron
Cc: cisco-nsp [at] puck
Subject: Re: [c-nsp] 7606 to 6509 [BGP hold time issue]

Now that you are confident you have tried a lower MTU setting satisfactorily, just revisiting a couple of points mentioned by others (at the cost of sounding repetitive but always good to check)

1. Is BGP MSS or PMTUD explicitly set on either side? have you tried disabling them
2. Is BGP max prefix set on the other side ?

On Tue, May 8, 2012 at 7:59 PM, Scantlebury, Kieron <Kieron.Scantlebury [at] level3<mailto:Kieron.Scantlebury [at] level3>> wrote:

MTU's been checked and confirmed on numerous occasions with the customer. Their control plane has no policing.

FYI. He has numerous other connections to the same device all receiving a full routing table and they all work fine. Its just our connection that's having the issue.

Its driving me round the bend :)

Cheers
Kieron

-----Original Message-----
From: cisco-nsp-bounces [at] puck<mailto:cisco-nsp-bounces [at] puck> [mailto:cisco-nsp-bounces [at] puck<mailto:cisco-nsp-bounces [at] puck>] On Behalf Of Shanawaz Batcha
Sent: 04 May 2012 23:14
To: cisco-nsp [at] puck<mailto:cisco-nsp [at] puck>
Subject: [c-nsp] 7606 to 6509 [BGP hold time issue]

During the 3 minutes of the session holding up, do you see any packets in the OutQ (show ip bgp summ)

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down
State/PfxRcd
172.16.2.1 4 64900 1754971 1714093 1406547 0 0
7w2d 8

As has been fairly pointed out, it looks like your 'fat' update packets are likely dropped by either an MTU mismatch or a CoPP filter on the other side. Its hard to know either way without further debugging (debug ip bgp
update) run during your off-hours

Shaan
_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck<mailto:cisco-nsp [at] puck> https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

--
"Twenty years from now you will be more disappointed by the things that you didn't do than by the ones you did do. So throw off the bowlines. Sail away from the safe harbor. Catch the trade winds in your sails. Explore. Dream. Discover."

_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads