Hi, saw something interesting today... not a real problem, but "it should not do this". Maybe one of you has seen this and understands what the box is doing.
Background: there used to be a BGP prefix 195.24.120.0/21, which was "ghosted", and finally it's gone. So, BGP shows it's gone, but it does so in a weird way: Cisco-M-XXXI>sh ip b 195.24.120.1 % Network not in table On the neighbouring router, the /19 supernet is correctly displayed: Cisco-M-XXX>sh ip b 195.24.120.1 BGP routing table entry for 195.24.96.0/19, version 995286991 Local 0.0.0.0 from 0.0.0.0 (194.97.129.78) Origin IGP, metric 0, localpref 200, weight 32768, valid, sourced, best Community: 5539:440 5539:500 Back to the problematic one: Cisco-M-XXXI>sh ip b 195.24.120.1/19 BGP routing table entry for 195.24.96.0/19, version 647698906 ... Local 193.149.44.14 (metric 128512) from 193.149.44.14 (194.97.129.78) Origin IGP, metric 0, localpref 200, valid, internal, best Community: 5539:440 5539:500 Cisco-M-XXXI>sh ip b 195.24.119.1 BGP routing table entry for 195.24.96.0/19, version 647698906 ... Local 193.149.44.14 (metric 128512) from 193.149.44.14 (194.97.129.78) Origin IGP, metric 0, localpref 200, valid, internal, best Community: 5539:440 5539:500 Cisco-M-XXXI>sh ip b 195.24.120.1 % Network not in table so it clearly *has* the /19, it's just BGP refusing to look it up when asking for individual IPs from the former /21... Digging around, I found something: Cisco-M-XXXI>sh ip b pending-prefixes | inc 195.24 195.24.120.0/21 681600139 Not advertised to any peer ... so what is that? Why isn't it deleting the prefix right away (we have no dampening configured - and if we had, I'd expect "show ip bgp" to display the history entry, not "no prefix found")? At the end of this list, it shows 384 pending network entries using 45312 bytes of memory These nets will be cleaned up by the BGP Scanner once all update-groups have been converged. There is a bit of BGP churn on this router, but all BGP peers are "up" (so no "updates to some members of an update-group are stuck") and all BGP table versions in "show ip b su" are much higher than 681600139 - OTOH, one or the other peer is always slow enough so that not all of the peers seem to reach the exact same table version... This particular prefix would have never been announced to the "slow" eBGP peers anyway, as it was learned from upstream - and the iBGP update group actually *is* in sync. The box in question is at SXI8a, so maybe it's a bug in there and I really should be updating now... gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025 g...@net.informatik.tu-muenchen.de
pgpMmIoDj1wZL.pgp
Description: PGP signature
_______________________________________________ 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/