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.34/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/
