config look ok as far as i can see, i actually dont have bgp router-id set in the bgp config... you think if i add that with the loopback ip, it would make a difference?
config router bgp 65000 no synchronization bgp log-neighbor-changes bgp graceful-restart restart-time 120 bgp graceful-restart stalepath-time 360 bgp graceful-restart bgp dampening neighbor Backbone peer-group neighbor Backbone remote-as 65000 neighbor Backbone update-source Loopback1 neighbor Backbone version 4 neighbor Backbone send-community neighbor 10.10.10.2 peer-group Backbone neighbor 10.10.10.3 peer-group Backbone no auto-summary On Sat, Jul 19, 2008 at 12:29 PM, Oliver Boehmer (oboehmer) < [EMAIL PROTECTED]> wrote: > Hmm, "%BGP-5-ADJCHANGE: neighbor 10.10.10.3 Down BGP protocol > initialization" looks unexpected, not sure what's happening.. > just a hunch, but can you double-check your config regarding loopback > addresses, bgp router-id and things? Possibly add some bgp debug (deb > bgp all events, deb bgp all, deb bgp all keep) and see if something > weird pops up? > What does the neighbor's (10.10.10.3) log say? > > oli > > ________________________________ > > From: Christian Koch [mailto:[EMAIL PROTECTED] > Sent: Saturday, July 19, 2008 3:08 PM > To: Oliver Boehmer (oboehmer) > Cc: cisco-nsp > Subject: Re: [c-nsp] BGP Hold Time Expired, but why? > > > hmm, i didnt check cef/mpls on the new path, i should try that.. there > is connectivity between the loopbacks > > the session comes back up right after the timer expires.thats what > puzzles me > > actually 3-4 is about how long i kept it down for.. > > > Jul 16 14:29:22 EDT: %LINK-3-UPDOWN: Interface TenGigabitEthernet2/2, > changed state to down > Jul 16 14:29:22 EDT: %LINEPROTO-SP-5-UPDOWN: Line protocol on Interface > TenGigabitEthernet2/2, changed state to down > Jul 16 14:29:22 EDT: %OSPF-5-ADJCHG: Process 10, Nbr 10.10.10.2 on > TenGigabitEthernet2/2 from FULL to DOWN, Neighbor Down: Interface down > or detached > Jul 16 14:29:22 EDT: %LDP-5-NBRCHG: LDP Neighbor 10.10.10.2:0 (11) is > DOWN (Interface not operational) > Jul 16 14:29:22 EDT: %LINK-SP-3-UPDOWN: Interface TenGigabitEthernet2/2, > changed state to down > Jul 16 14:29:23 EDT: %LINK-SP-3-UPDOWN: Interface TenGigabitEthernet2/2, > changed state to up > Jul 16 14:29:23 EDT: %LINK-3-UPDOWN: Interface TenGigabitEthernet2/2, > changed state to up > Jul 16 14:29:23 EDT: %LINEPROTO-5-UPDOWN: Line protocol on Interface > TenGigabitEthernet2/2, changed state to up > Jul 16 14:29:23 EDT: %LINEPROTO-SP-5-UPDOWN: Line protocol on Interface > TenGigabitEthernet2/2, changed state to up > Jul 16 14:29:33 EDT: %LDP-5-NBRCHG: LDP Neighbor 10.10.10.2:0 (11) is UP > Jul 16 14:30:19 EDT: %OSPF-5-ADJCHG: Process 10, Nbr 10.10.10.2 on > TenGigabitEthernet2/2 from LOADING to FULL, Loading Done > Jul 16 14:30:37 EDT: %LDP-5-NBRCHG: LDP Neighbor 10.10.10.2:0 (4) is > DOWN (Discovery Hello Hold Timer expired) > Jul 16 14:31:39 EDT: %LDP-5-NBRCHG: LDP Neighbor 10.10.10.2:0 (4) is UP > Jul 16 14:32:38 EDT: %BGP-3-NOTIFICATION: received from neighbor > 10.10.10.3 4/0 (hold time expired) 0 bytes > Jul 16 14:32:38 EDT: %BGP-5-ADJCHANGE: neighbor 10.10.10.3 Down BGP > protocol initialization > Jul 16 14:32:45 EDT: %BGP-5-ADJCHANGE: neighbor 10.10.10.3 Up > > > > On Sat, Jul 19, 2008 at 3:24 AM, Oliver Boehmer (oboehmer) > <[EMAIL PROTECTED]> wrote: > > > No clue what's happening.. I've seen issues in the past with TCP > PMTUD > when the path converges over a link with a different MTU (which > is > happening in your case), but as BGP will not send packets larger > than > 4k, this shouldn't be an issue here. > > How long did you take down the link before bringing it back up? > I assume > longer than 3 minutes? Have you checked CEF and MPLS along the > new path? > You have IP connectivity between the loopbacks aR1 and bR2? Does > the > session come back up eventually, or will it stay down? > > oli > > Christian Koch <> wrote on Saturday, July 19, 2008 8:38 AM: > > > > sorry forgot to specify > > > > the bgp session from aR1 to bR2 is the session in question > > > > ck > > > > On Sat, Jul 19, 2008 at 2:21 AM, Christian Koch > > <[EMAIL PROTECTED]> wrote: > > > >> Hello - > >> > >> I have the following topology in lab, testing different > failure > >> scenarios. When i disconnect the link between aR1 and bR1, > what > >> would appear to be normal happens - ospf and ldp neighbor go > down. > >> > >> When i re-connect the link between aR1 and bR1, the interface > comes > >> back up, osfp/ldp neighbor is re-established. > >> > >> 3minutes later, bgp holdtime expires , and all links are up.. > >> > >> aR1-----------------bR1 > >>> | > >>> | > >>> | > >>> | aR2-----------------bR2 > >> > >> > >> Some Notes > >> - All Links 10GE > >> - Full ibgp mesh > >> - Peering is to loopbacks > >> - OSPF as IGP > >> - Loopbacks in OSPF > >> - MPLS Enabled on Interfaces > >> > >> > >> OSPF cost between aR1 and aR2 is 1 > >> OSPF cost between bR1 and bR2 is 1 > >> OSPF cost between aR1 and bR1 is 250 > >> OSPF cost betwen aR2 and bR2 is 500 > >> > >> MTU 9216 between aR1 and aR2, aR1 and bR1, aR2 AND BR2 > >> MTU 9182 between bR1 and bR2 > >> > >> > >> IOS on aR1 and aR2 is 12.2.33.SRB2 - SUP720 > >> IOS on bR1 and bR2 is 12.33.SRC - RSP720 > >> > >> > >> i am stumped, any ideas would be helpful in trying to > understand why > >> the bgp session is going down due to expired hold time, when > all > >> links are up.. > >> > >> thanks! > >> > >> ck > >> > >> > >> > >> > >> > >> > > > > > > -- > > ^christian$ > > > _______________________________________________ > > cisco-nsp mailing list [email protected] > > https://puck.nether.net/mailman/listinfo/cisco-nsp > > archive at http://puck.nether.net/pipermail/cisco-nsp/ > > > > > > -- > ^christian$ > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
