zombie routes to 3ffe:1ce1::/32 ?

[Daniel Hagerty]

[ Yes, both posts you made got through. ]

 > It appeared from source-routed traceroutes that the no-export-tagged
 > route propagated further than I expected it to, so I stopped bgp and
 > restarted it without this; however, I have reason to believe that the
 > route is still floating around in the 6bone bgp cloud..
 >
 > My understanding is that dropping the bgp connection should have
 > caused the bgp peer to withdraw any routes it learned from
 > me.. unfortuneately, that doesn't seem to have happened.

    An AS that forwarded that no-export tagged route across an AS
boundary is broken.  Since it didn't drop the annoucement on peering
reset, you probably have borked BGP implentation(s) upstream from you
(as opposed to a broken route-map stripping the no-export community
tag).

 > I have reason to believe that there are currently some "zombie routes"
 > to 3ffe:1ce1::/32 floating about as a result of this.
 >
 > Anyone have any advice as to what I can do from here to get the route
 > withdrawn for real?  (I'm using zebra bgp 0.80 on NetBSD+KAME).

    The short answer is "no" (though you might try tearing down
peering for 2 * holdtime or other silliness).  You have to get the
broken peer to withdraw the bogus annoucement.  I'm only seeing AS
10566 propagating the announcement, according to
http://lookingglass.imag.fr/.

    What's the deal with you announcing 3ffe:1ce1::/32 ?  I didn't dig
deeply, bug 3ffe:1c::/24 is a merit pTLA, and MIT is delegated
3ffe:1ce1::/48 .  Right now, unless you can provide a 100% up routing
guarantee between merit & MIT, you can black hole traffic for prefixes
outside your netblock.