BGP Routes withdrawn
So i'm troubleshooting a lab in the route FLG and I can't seem to get it to do what I want. Does anyone know how to find out why a BGP update was withdrawn? I've played around with different debugs but haven't seen anything.
Here are the withdrawn debugs...any idea how to dig deeper?
*Mar 1 00:44:38.687: BGP(0): 192.168.5.5 rcv UPDATE about 192.168.25.0/24 -- withdrawn
*Mar 1 00:44:38.691: BGP(0): 192.168.5.5 rcv UPDATE about 192.168.26.0/24 -- withdrawn
*Mar 1 00:44:38.695: BGP(0): 192.168.5.5 rcv UPDATE about 192.168.24.0/24 -- withdrawn
Here are the withdrawn debugs...any idea how to dig deeper?
*Mar 1 00:44:38.687: BGP(0): 192.168.5.5 rcv UPDATE about 192.168.25.0/24 -- withdrawn
*Mar 1 00:44:38.691: BGP(0): 192.168.5.5 rcv UPDATE about 192.168.26.0/24 -- withdrawn
*Mar 1 00:44:38.695: BGP(0): 192.168.5.5 rcv UPDATE about 192.168.24.0/24 -- withdrawn
Cisco was my first networking love, but my "other" router is a Mikrotik...
Comments
-
aquilla Member Posts: 148 ■■■□□□□□□□Hi,
What's the topology? What is the config of all the routers involved? Any ACL's / prefix-lists or route-maps in place?Regards,
CCNA R&S; CCNP R&S -
Forsaken_GA Member Posts: 4,024BGP withdraws routes it announces when it loses the route from the routing table or when the peer it learned it from withdraws it, or when you configure an aggregate address and you're only advertising the summary.
So the first place to look is where are those routes coming from? Are they being learned from an internal IGP? If so, you may have bouncing adjacencies. If you're doing summary routes without discard routes, or redistribution at multiple points, you may be experiencing route feedback that eventually drives the metrics into an infinity condition, causing them to be withdrawn, and then relearned.
It all comes back to the underlying routing table. BGP is dependent on other sources for it's information, so find out where it's getting it's information from, and determine what the problem is there, and you'll likely solve your problem. -
Forsaken_GA Member Posts: 4,024Actually, let me amend that. BGP will only advertise the best path it has to a prefix to it's neighbors. So if it learned of a better route via the normal BGP path selection methods, that will also prompt it to withdraw it's previous routes. Whether or not it advertises new routes to replace those depends on whether or not the new best route is through the peer it just withdrew routes from (after all, if you tell me you have a route to a location, and I tell you that I have a better route to that location, it wouldn't make sense for you to tell me about the route I just told you about)
And of course, there's always the admin getting involved and doing some route filtering that can prompt withdrawals, but I suspect you'd know about it if that was the case