We had the exact same problem a month ago and reported it to TAC. They didn't find the reason and the issue disappeared after a reboot of the router. Roughly 14 days later, the problem came back. Then I decided to upgrade to SRC-train instead.
I would recommend upgrading to SRC-train instead, since SRB has a security breach in the http implementation (if you should use this to access the router). ______________________________________ Med venlig hilsen / Kind regards Lars Lystrup Christensen Director of Engineering, CCIE(tm) #20292 Danske Telecom A/S Sundkrogsgade 13, 4 2100 København Ø -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of M Usman Ashraf Sent: 29. januar 2009 19:42 To: Andrei Radu Cc: [email protected] Subject: Re: [c-nsp] 7600/SRB4 not sending bgp updates Hi, We had a similar problem on a 7609 box running SRB2. Whenever we used to add prefixes in a prefix list being advertised to an eBGP peer via a route-map, soft resetting the peer by "clear ip bgp neighbor X.X.X.X soft out" used to result in no prefixes being advertised at all. We had to remove the route-map configuration and then had to re-enter these configurations to advertise prefixes again. Upgraded to SRC, and the issue was resolved. -- Regards, M Usman Ashraf On Wed, Jan 28, 2009 at 6:43 PM, Andrei Radu <[email protected]> wrote: > Hello everybody, > > I've been have a ton of trouble with one of our 7600es (everyone who > hasn't please stand up :P) used as a border/exchange router. So > basically this box does OSPF/LDP and iBGP towards the rest of the > network and eBGP to a number of external peers. > > The problem is that for new neighbors configured in a certain > peer-group the router does not send any updates, although it shows > prefixes as being advertised in the output of the "show ip bgp > neighbor A.B.C.D advertised-routes" command. In the output of "show ip > bgp neighbor A.B.C.D" the update counter remains at a steady 0: > > Message statistics, state Established: > InQ depth is 0 > OutQ depth is 0 > Sent Rcvd > Opens: 1 1 > Notifications: 0 0 > Updates: 0 19 > Keepalives: 30 37 > Route Refresh: 0 0 > Total: 31 57 > > and the total prefixes remains also at 0: > > Sent Rcvd > Prefix activity: ---- ---- > Prefixes Current: 504 2 (Consumes 104 bytes) > Prefixes Total: 0 2 > Implicit Withdraw: 0 0 > Explicit Withdraw: 0 0 > Used as bestpath: n/a 2 > Used as multipath: n/a 0 > > I was able to reproduce this behavior using a bgp session with a test > router, and also found a workaround: configuring new peers in a > different peer-group with only the name and the name of the output > route-map changed, this forced the router to place the new neighbors > in a different update-group. Everything seemed to work ok until > earlier today when the workaround peer-group started behaving > identically :( . > > I am sure it is a SRB4 bug and it looks kind of similar to the bgp > ghost bug seen on the SXH train, my bigger problem is I cannot open a > TAC case for this box as it is out of smartnet support. > > Was anyone else hit by this ? Does anyone have a more stable > workaround (short of reloading the box :) ) ? The only thing I could > find in the bug toolkit was CSCsm57494 which also seems similar but > does not contain too many details. > > Best regards, > -- > Andrei > > "2+2=5, for extremely large values of 2 !" > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
