if the primary route becomes unavailable and routing falls over to the "nailed up" route, a bgp update is still sent. (if dampening is enabled) this update is recorded by ebgp peers as a "flap". i'd guess from your message below that when this occurs your router(s) are also changing the med attached to the prefix, which seems normal to me... i'd suggest you have a look at the stability of the interface to which the primary route is attached (?carrier transitions, interface resets, etc...?). you might also consider breaking the primary route (/20) into 2 /21 blocks internally and allowing the longer "nailed up" route to be the permanent source of the /20 advertisement. for example: rather than: ip route 204.147.224.0 255.255.240.0 <interface> !"primary" route ip route 204.147.224.0 255.255.240.0 null0 254 !"nailed up" route ! router bgp <as> network 204.147.224.0 mask 255.255.240 try this: ip route 204.147.224.0 255.255.248.0 <interface> !"primary" route ip route 204.147.232.0 255.255.248.0 <interface> !"primary" route ip route 204.147.224.0 255.255.240.0 null0 <admin. distance> !"nailed up" route ! router bgp <as> network 204.147.224.0 mask 255.255.240 although correcting the stability problem is the correct solution. -danny

I have a Cisco 7505 which is advertising about 50 routes to about 40 peers at mae-west, and a few others. One set of customers has been complaining that their connectivity is going away right at that router, and then coming back. Narrowed the set of customers down to a single CIDR block, at 204.147.224.0/20.

So, some of our peers are claiming that the route is flapping... that's weird, we have them all nailed up to static routes... especially the CIDR blocks. So I wrote a tool which you can peer a router with, and it watches the BGP traffic and prints anything it gets, formatted, to standard out.

My Cisco is sending fresh advertisements every 10-30 minutes for that route, and not for any other of the routes it has, and it appeared to be all the same, but on careful examination, it appears that each advertisement reflects a change in the MULTI_EXIT_DISC from 0x00000000 to 0x00000014 and then back again in the next advertisement.

What the heck am I seeing here? Is someone's flap damping code seeing the repeated advertisements and suppressing me? Is my Cisco going crazy?

-matthew kaufman matthew@scruz.net