bogus route: 2001::/16

Jan Oravec Jan Oravec <wsx@wsx6.net>
Fri, 18 Jan 2002 18:06:23 +0100


> It's 1103 and this is us, surfnet. I contacted Itojun offline because
> we are not announcing the prefix to 3274. We also do not see 2001::/16
> in our routing table. We don't see the route, Itojun still does. Could
> the other ASes in the path below have a check? I suspect it is a buggy
> BGP implementation somewhere which is holding the route.

We see 2001::/16, someone has buggy BGP implementation which creates such
"long paths", we can see a lot of them.

SKBYS-0000> sh bgp 2001::/16
BGP routing table entry for 2001::/16
Paths: (3 available, best #2, table Default-IP-Routing-Table)
  Advertised to non peer-group peers:
  2001:658:0:1::1 3ffe:80e8:1:3::2 3ffe:80ef:1:: 3ffe:80ef:100:: 3ffe:80ef:800:: 3ffe:80ef:900::
  5594 2200 2611 6774 4589 680 1275 762 6175 6435 109 1251 3265 7521 7521 7521 7521 4697 3425 293 4554 8954 10566 5408 2549 3274 1103, (Received from a RR-client)
    3ffe:80e1:8000:10::2 from 3ffe:80ef:1:: (195.168.1.69)
      Origin incomplete, localpref 100, valid, internal
      Last update: Fri Jan 18 13:35:32 2002

  6830 8733 2611 6774 4589 680 1275 762 6175 6435 109 1251 3265 7521 7521 7521 7521 4697 3425 293 4554 8954 10566 5408 2549 3274 1103, (Received from a RR-client)
    2001:730:3::1:e from 3ffe:80ef:300:: (62.140.29.9)
      Origin incomplete, localpref 100, valid, internal, best
      Last update: Fri Jan 18 12:59:03 2002

  6830 8733 2611 6774 4589 680 1275 762 6175 6435 109 1251 3265 7521 7521 7521 7521 4697 3425 293 4554 8954 10566 5408 2549 3274 1103, (Received from a RR-client)
    2001:730:3::1:e from 3ffe:80ef:900:: (62.140.29.9)
      Origin incomplete, localpref 100, valid, internal
      Originator: 62.140.29.9, Cluster list: 62.89.127.130 
      Last update: Fri Jan 18 12:59:00 2002

These announcements of these long paths are stable (actually 4 hours up).
We peer with 2611 and they are announcing us much different ASPATH for
2001::/16. If we receive different ASPATH from 5594 going thru 2611, it
means that something was corrupted on 5594, 2200 or 2611.

These long ASPATHs are very common on 6bone, it seems that some popular
implementation of BGP is broken. They are commonly appearing when prefix is
being removed from routing tables and may appear if implementation of BGP
has corrupted ASPATH loop-check.

Actually I am implementing BGP+IGP daemon, because except zebra there is no
decent routing daemon able to do very advanced routing we need for project.
We are now using slightly modified zebra, but it has still enough bugs.

Best Regards,

-- 
Jan Oravec
project coordinator
XS26 - 'Access to IPv6'  
jan.oravec@xs26.net