Re: [c-nsp] Sanity check OSPF/BGP
Hello, For clarity's sake: Each of the 5 edge/peering routers have the full routing table installed and they are totally unaware of one another as far as BGP is concerned Downstream from there, the view from any of the four core routers is this: Neighbor V MsgRcvd MsgSent InQ OutQ Up/Down State PfxRcd PfxAcc 192.168.222.25 4 45082982171835006d05h Estab 812608 812608 192.168.222.26 4 5657384617313000 18d04h Estab 812623 812623 192.168.222.27 4 45082982171835006d02h Estab 812609 812609 192.168.222.28 4 5657384617313000 118d04h Estab 812625 812625 192.168.222.29 4 45082982171835007d02h Estab 812607 812607 The issue I was running into and asking about was regarding the delay between when OSPF closes (next-hop is no longer reachable) and when the next-hop that is no longer reachable stops being used as a route to a destination. Not only is the next hop unreachable once OSPF closes, there isn't even a route to that next hop anymore. So the reason I asked the question was to validate my thinking that if there is no longer a route to the next-hop than the router shouldn't be waiting for the hold timer to expire prior to selecting a different path. But I still need to validate a few things. Thanks, -Drew -Original Message- From: adamv0...@netconsultings.com Sent: Monday, October 12, 2020 10:40 AM To: Drew Weaver ; cisco-nsp@puck.nether.net Subject: RE: [c-nsp] Sanity check OSPF/BGP > Drew Weaver > Sent: Thursday, October 8, 2020 2:01 PM What I expect to happen is: > > The route to the peering edge router's loopback > interface is withdrawn when OSPF/OSPFv3 closes. > The core router will close the BGP session when the > route to the dead > peering edge router is withdrawn and will begin using one of the 5 > other copies of the same route that it has. > Number of things come to mind since you provided no details regarding the setup Case A) If all 5 peering points are not advertising best-external prefixes -then there's only a single path for each of the 700K prefixes in the entire AS via one of the 5 peering points. -in case one peering point fails all prefixes it offered a best path for will be withdrawn from all BGP speakers in the AS at OSPF convergence speeds, but then the remaining 4 peering points needs to realize they now have the overall best path for a given prefix and start advertising it to all BGP speakers in the AS -tedious process that converges at "BGP-speed". Case B) If all 5 peering points are advertising best-external prefixes and all BGP speakers in the AS already have all 5 paths available in RIB, but none of the BGP speakers has hierarchical FIB so there's a direct correlation between a prefix and it's NH, -in case one peering point fails all prefixes it offered a best path for will be withdrawn from all BGP speakers in the AS at OSPF convergence speeds, but now each BGP speaker will need to painstakingly update its FIB on a prefix by prefix bases for each of the each of the 700K prefixes. Case C) If all 5 peering points are advertising best-external prefixes and all BGP speakers in the AS already have all 5 paths available in RIB, and all BGP speakers not even have hierarchical FIBs but also PIC-CORE enabled where a backup path for each prefix is programmed in FIB, -in case one peering point fails all prefixes it offered a best path for will be withdrawn from all BGP speakers in the AS at OSPF convergence speeds and each BGP speaker will then just need to change 5 HN pointers to point to remaining 4 peering points in FIB. Note, The above assumes full mesh between all BGP speakers or otherwise assumes the RR infrastructure emulates full-mesh with regards to prefix distribution to all BGP speakers in the AS via one of the several available mechanisms. Adam ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] EOBC0/0 ifInErrors
--- Begin Message --- The EOBC is a proprietary shared bus, and full duplex doesn't exist. Collisions are going to occur, and they can result in receive errors. Overall I wouldn't worry about it unless there are other symptoms. That being said I haven't worked on the Cat6K for a long time and can't speak for TAC, take it for what it is worth. Jim -Original Message- From: cisco-nsp On Behalf Of Nick Hilliard Sent: Tuesday, October 13, 2020 7:04 AM To: Tim Rayner Cc: cisco-nsp Subject: Re: [c-nsp] EOBC0/0 ifInErrors Tim Rayner wrote on 13/10/2020 10:48: > If the EOBC0/0 interface that you're seeing runts on is running as > full duplex, and the interface that it connects to is running at half > duplex, that would do it, but EOBC is an internal interface which is h/d by default. I'm not sure if it's even possible to configure the interface discipline on the CLI, but maybe it is. Nick ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ --- End Message --- ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] EOBC0/0 ifInErrors
Tim Rayner wrote on 13/10/2020 10:48: If the EOBC0/0 interface that you're seeing runts on is running as full duplex, and the interface that it connects to is running at half duplex, that would do it, but EOBC is an internal interface which is h/d by default. I'm not sure if it's even possible to configure the interface discipline on the CLI, but maybe it is. Nick ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] EOBC0/0 ifInErrors
Eugene Grosbein wrote on 12/10/2020 20:28: > It seems so: [...] >Tx Errors/State: > One Collision Error = 306656 More Collisions = 1209541 [...] > Input Errors = 28517 > Output Drops = 0Giants/Runts = 0/28517 > uh, obviously collisions are a transmit phenomenon, but you're seeing rx > errors, so this isn't collisions. I don't know what the root cause is > here, but runts are not good on ethernet and usually indicate physical > cabling problems. As the EOBC interface is "cabled" via the crossbar at > the rear of the chassis, there are relatively few failure points. > Nick One possibility that springs to mind here is a duplex mis-match. If the EOBC0/0 interface that you're seeing runts on is running as full duplex, and the interface that it connects to is running at half duplex, then the half-duplex interface will record a collision and stop transmitting when it receives a frame overlapping with one that it is transmitting. Your full-duplex interface will only see the part of that frame that is transmitted before the collision is detected - which the full-duplex interface may record as a runt. It would be interesting to know what happens to the runt and collision stats if you can force both ends to full duplex, or both ends to half duplex. Tim ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] EOBC0/0 ifInErrors
Eugene Grosbein wrote on 12/10/2020 20:28: It seems so: [...] Tx Errors/State: One Collision Error = 306656 More Collisions = 1209541 [...] Input Errors = 28517 Output Drops = 0Giants/Runts = 0/28517 uh, obviously collisions are a transmit phenomenon, but you're seeing rx errors, so this isn't collisions. I don't know what the root cause is here, but runts are not good on ethernet and usually indicate physical cabling problems. As the EOBC interface is "cabled" via the crossbar at the rear of the chassis, there are relatively few failure points. Nick ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
