Strange BGP phantom announce remaining

I probably made a stupid mistake when changing my BGP announces but I
cannot see where.

We are a customer of Abovenet and Telia in France (we have AS 20766)
and we peer with AS 6461 and 1299. We announce one prefix,
80.67.160.0/19. All the looking glasses I've tried see that prefix,
including routers at Abovenet.

The strange is that people at Colt (try yourself on
route-server.colt.net) see two prefixes, 80.67.160.0/19 and
80.67.160.0/21. The second one, more specific, was indeed announced
but is no longer sent for six days.

Our routers seems correct and displays only one announce:

drowzee-bgpd> show ip bgp neighbors 62.4.73.26 advertised-routes
   Network Next Hop Metric LocPrf Weight Path
*> 80.67.160.0/19 62.4.73.30 50 32768 20766 i

Total number of prefixes 1

Does you have any idea why routers at Colt still see the old announce?
People at Colt have no idea. Abovenet checked on its side and sees
only the good prefix.

Configuration: Debian "woody", Linux kernel 2.4.9, Zebra routing
software 0.91 and 0.92a (hence the copy to the Zebra
list). http://lookinglass.gitoyen.net/ if you want to examine our
network.

Stephane Bortzmeyer wrote (on Nov 12):

Does you have any idea why routers at Colt still see the old announce?
People at Colt have no idea. Abovenet checked on its side and sees
only the good prefix.

Dodgy Cisco-ism probably. Use looking glasses and NOC's to find the one
router where the phantom prefix appears in a BGP table and (have someone)
drop the BGP session associated with it.

Failing that, re-advertise the prefix for a period of time (minutes
not seconds) and then withdraw it.

I have found IOS sometimes unable to "keep up" when it is faced with
a prefix that is withdrawn too quickly. Because "soft" configuration
maintains the same state the BGP engine sees, a soft clear doesn't solve
the problem. You have top dump all state for that session, ergo, drop
the BGP session or renew the phantom prefix.

Just my experience, and it's always been with other networks routers,
not mine.

Chris.

First, the problem disappeared because Colt cleared the router which
was deceived by a bogus announce from Telecom Italia. Thanks.

a message of 33 lines which said:

I probably made a stupid mistake when changing my BGP announces but I

Apparently, I made no mistake. According to analysis done by Jim Cowie
with data at http://gradus.renesys.com, the change was properly
done. But at least one router in Telecom Italia did not receive it.

There was nothing we could do, since it took place at a far away
location. Without the action from Colt, we could have try to
re-announce the more specific route for ten minutes (let it
propagate), then to withdraw it again, hoping it will clear it. Next
time, I'll try :slight_smile:

Does you have any idea why routers at Colt still see the old announce?

The question should have been "Why routers at Telecom Italia corrupted
Colt's database?". I received two hypothesis:

From the Telia support (very helpful, like the Abovenet one):

Cisco Bug Id CSCdt19638 :

"BGP bestpath change not sent to peers

Under rare circumstances, an updated Border Gateway Protocol (BGP)
bestpath may not be propagated to the BGP peers of a router.

Workaround: Enter the clear ip bgp * soft out EXEC command to update
the peers with the current bestpath attributes."

[The workaround did not work in our case, since it was not *our*
router that send the wrong info.]

From Neil J. McRae at Colt:

We saw this route from a peer that was announcing us a huge number of
routes that for some reason max-prefix didn't prevent from happening,
although after rebooting, the box did take the session down. My guess
is that the routes announced to us had sometype of corruption that
didn't send it through the max-prefix subroutine properly to detect
the number of routes being advertised.

Well, now it works, back to work.

Configuration: Debian "woody", Linux kernel 2.4.9, Zebra routing
software 0.91 and 0.92a (hence the copy to the Zebra

Nice software, no problem :slight_smile: