BGP configuration problem

vdarienz · ‎05-30-2011

Hi

i am not an expert on BGP, so probably the solution to my problem could be simple.

Anyway the customer is asking some support since it is having some problems on BGP.

The configuration is the following:

1941(IP 172.16.140.22)--with BGP peering with a 7600 (172.16.140.21)

It looks that the BGP is flapping between the two router.

This is what happens on 1941

*May 30 12:45:39.295: %BGP-5-ADJCHANGE: neighbor 172.16.140.21 Up

*May 30 12:45:39.295: BGP: ses global 172.16.140.21 (0x312D0630:1) read request no-op

*May 30 12:46:10.023: BGP: 172.16.140.21 connection timed out 30708ms (last update) 30000ms (hold time)

*May 30 12:46:10.023: BGP: 172.16.140.21 went from Established to Closing

*May 30 12:46:10.023: %BGP-5-ADJCHANGE: neighbor 172.16.140.21 Down BGP Notification sent

*May 30 12:46:10.023: %BGP-3-NOTIFICATION: sent to neighbor 172.16.140.21 4/0 (hold time expired) 0 bytes

*May 30 12:46:10.023: BGP: ses global 172.16.140.21 (0x312D0630:1) Send NOTIFICATION 4/0 (hold time expired) 0 bytes

*May 30 12:46:10.023: BGP: 172.16.140.21 local error close after sending NOTIFICATION

*May 30 12:46:10.023: BGP: nbr_topo global 172.16.140.21 IPv4 Unicast:base (0x312D0630:1) NSF delete stale NSF not active

*May 30 12:46:10.023: BGP: nbr_topo global 172.16.140.21 IPv4 Unicast:base (0x312D0630:1) NSF no stale paths state is NSF not active

*May 30 12:46:10.023: BGP: nbr_topo global 172.16.140.21 IPv4 Unicast:base (0x312D0630:1) Resetting ALL counters.

*May 30 12:46:10.023: BGP: 172.16.140.21 closing

while PE that is a 7600 seesm that is not sending any info

May 30 13:49:11.112: BGP: 172.16.140.22 received KEEPALIVE, length (excl. header) 0

May 30 13:49:16.204: BGP: Import timer expired. Walking from 179580 to 179580

May 30 13:49:17.496: BGP: 220.2.31.2 sending KEEPALIVE (io)

May 30 13:49:20.560: BGP: 220.2.31.2 received KEEPALIVE, length (excl. header) 0

May 30 13:49:21.352: BGP: 172.16.140.22 received KEEPALIVE, length (excl. header) 0

May 30 13:49:23.332: BGP(2): 172.16.117.211 rcv UPDATE about 3269:77:101.14.0.0/27 -- withdrawn

May 30 13:49:27.496: BGP: 220.2.31.2 sending KEEPALIVE (io)

May 30 13:49:30.560: BGP: 220.2.31.2 received KEEPALIVE, length (excl. header) 0

May 30 13:49:31.204: BGP: Import timer expired. Walking from 179580 to 179580

May 30 13:49:31.592: BGP: 172.16.140.22 received KEEPALIVE, length (excl. header) 0

May 30 13:49:32.868: BGP(2): 172.16.117.211 rcvd UPDATE w/ attr: nexthop 172.16.117.30, origin ?, localpref 100, metric 0, originator 172.16.117.30, clusterlist 172.16.117.211, path 1012, extended community RT:3269:77

May 30 13:49:32.868: BGP(2): 172.16.117.211 rcvd 3269:77:101.14.0.0/27 -- DENIED due to: extended community not supported;

May 30 11:49:33.640: %BGP-3-NOTIFICATION: received from neighbor 172.16.140.22 4/0 (hold time expired) 0 bytes

May 30 13:49:33.640: BGP: 172.16.140.22 reset due to BGP Notification received

May 30 11:49:33.640: %BGP-5-ADJCHANGE: neighbor 172.16.140.22 Down BGP Notification received

----------

In attach also the show run and version of the devices together with the complete log.

COuld you please help me with this problem?

Thanks
Vincenzo

Fabrizio Pedracini · ‎05-30-2011

Hi Vincenzo,

it looks like the 1941 does not get the updates the 7600 is sending right after the neigborship is established. The 1941 brings down the session due to hold time expired.

You might want to check "show ip bgp neighbor x.x.x.x" on both sides while the session is up. There are a lot of counters that can give you an idea of what's going on. Look for "Message statistics" and also look at the bottom for "max data segment" negotiated. Try to to do a ping on the point-to-point link with different packet size to see if there is any issue with big packets.

In case there is a problem with the max data segment negotiated you can lower it on the 1941 with the command "ip tcp mss <#>" (global config).

also, migh not be related.. any reason why you're using "neighbor 172.16.140.21 transport single-session" on the 1941 ?

hope this helps,

Fabrizio

vdarienz · ‎05-30-2011

Hi Fabrizo,

thanks for the reply, i will check the information you are mentioning. hoping it can solve the issue.

For what concerns the configuration of single session, it refers to a command added after, but nothing changes with or without it.

Just for information, anyway you don't see any config errors, right?

Thanks

Vincenzo