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(a)scruz.net
