Wrong /24 Announcement at UU.net / BGP IOS Bug ?
Hello.. one of our customers (germany.net, AS6751) is announcing us 151.189.0.0/16. We announce this to our both upstreams ECRC (AS1273) and Ebone (1755). Since a few days a lot of german ISPs ask us, why 151.189.0.0/24 is routed via UU.net to the USA and then goes back to germany. We checked our cisco-routers an finaly i found a Customer of UU.net with a looking glass: (http://zeus.lyceum.com/cgi-bin/nph-bgp-routes)
QUERY: bgp 151.189.0.0 FROM: BR1.ATL1.lyceum.net.
BGP routing table entry for 151.189.0.0/24, version 9891827 Paths: (1 available, best #1, advertised over IBGP) 701 1800 1755 1755 1755 5549 5549 6751 157.130.64.121 from 157.130.64.121 (137.39.2.42) Origin IGP, valid, external, best
ok lets see bacK: Sprint (1800) doesnt have this /24 but the /16 as it should be: icm-bb4-pen#show ip bgp 151.189.0.0 255.255.255.0 % Network not in table icm-bb4-pen# the same applies to EBONE (AS1755): frankfurt-ebs1>show ip bgp 151.189.0.0 255.255.255.0 % Network not in table frankfurt-ebs1> an we (AS5549) also dont see any /24 out of 151.189.0.0/16 So the question is: why does UU.net announce 151.189.0.0/24 and from where do they get it. The worse thing is, that all uu.net customers get this )(&%&$()& /24 from the hub in Frankfurt. The Space 151.189.1.0 - 151.189.255.255 is visiable at uu.net via 151.189.0.0/16.. So what happens here, could this be an ios bug ? We didnt touch our configuration towards ebone and they dont play with their configuration every day :-) Any ideas ? hints ? Winfried PS: for the german isps, we fixed it by announcing only at de-cix the 151.189.0.0/24 additionally to 151.189.0.0/16 and it works, but i am still looking for an answer to my questions :-) ? -- Winfried Haug | seicom.NET & SCHWABEN.DE | Tel. +49 7121 9770- 0 Laiblinsplatz 12 | Internet+ISDN access & consulting | Fax. +49 7121 9770-19 72793 Pfullingen | Access in STGT + RT + TUE + BB + LB | Rack +49 7127 989-X haug@schwaben.net| 150*ISDN (64kb/X.75) / 100 * K56flex | Rack +49 711 9675-X haug@seicom.NET |SAP-OSS * FTP * TELNET * NETNEWS * IRC | Rack +49 7121 709-X * 10 MBit DE-CIX * 2 MBit INXS * 5 MBit ecrc/ebone * 2 Mbit Belwue * 2 Mbit WIN
I had a whole load of hastle with this about 2 yr ago, (one of our upstreams is AS701 aswell), where my routers "aparently" announced a /24 at some point which the withdraw got lost deep in UUnet. To fix this temporarily, announce the /24 and then withdraw it (toward UUNET in your case) I think this was happening when I was using IOS10.3 and my config said something like router bgp XXXX network 194.x.y.0 255.255.255.0 network 194.x.0.0 255.255.0.0 summary-only ... And thus the route did get briefly announced and withdrawn by me. I also have some recollection of an IOS bug where withdraws did get lost which was spotted in the AS7007 problem.. Richard In a previous message Winfried Haug wrote:
Hello..
one of our customers (germany.net, AS6751) is announcing us 151.189.0.0/16. We announce this to our both upstreams ECRC (AS1273) and Ebone (1755).
Since a few days a lot of german ISPs ask us, why 151.189.0.0/24 is routed via UU.net to the USA and then goes back to germany.
Hi Vinny! As i am thinking about this, i came to the idea that mostly uu.net applies filters to their downstreams e.g. there are not filtering by as - they filter by access-list what i presume is that they use a access-list xyz permit 151.189.0.0 255.255.255.0 instead of (the correct one): access-list xyz permit 151.189.0.0 255.255.0.0 note the difference ? It's probably time for them to call the uunet support to fix this. Winfried Haug wrote:
Hello..
one of our customers (germany.net, AS6751) is announcing us 151.189.0.0/16. We announce this to our both upstreams ECRC (AS1273) and Ebone (1755).
Since a few days a lot of german ISPs ask us, why 151.189.0.0/24 is routed via UU.net to the USA and then goes back to germany.
We checked our cisco-routers an finaly i found a Customer of UU.net with a looking glass: (http://zeus.lyceum.com/cgi-bin/nph-bgp-routes)
QUERY: bgp 151.189.0.0 FROM: BR1.ATL1.lyceum.net.
BGP routing table entry for 151.189.0.0/24, version 9891827 Paths: (1 available, best #1, advertised over IBGP) 701 1800 1755 1755 1755 5549 5549 6751 157.130.64.121 from 157.130.64.121 (137.39.2.42) Origin IGP, valid, external, best
ok lets see bacK:
Sprint (1800) doesnt have this /24 but the /16 as it should be:
icm-bb4-pen#show ip bgp 151.189.0.0 255.255.255.0 % Network not in table icm-bb4-pen#
the same applies to EBONE (AS1755):
frankfurt-ebs1>show ip bgp 151.189.0.0 255.255.255.0 % Network not in table frankfurt-ebs1>
an we (AS5549) also dont see any /24 out of 151.189.0.0/16
So the question is: why does UU.net announce 151.189.0.0/24 and from where do they get it. The worse thing is, that all uu.net customers get this )(&%&$()& /24 from the hub in Frankfurt. The Space 151.189.1.0 - 151.189.255.255 is visiable at uu.net via 151.189.0.0/16..
So what happens here, could this be an ios bug ?
We didnt touch our configuration towards ebone and they dont play with their configuration every day :-)
Any ideas ? hints ?
Winfried
PS: for the german isps, we fixed it by announcing only at de-cix the 151.189.0.0/24 additionally to 151.189.0.0/16 and it works, but i am still looking for an answer to my questions :-) ?
--
Winfried Haug | seicom.NET & SCHWABEN.DE | Tel. +49 7121 9770- 0 Laiblinsplatz 12 | Internet+ISDN access & consulting | Fax. +49 7121 9770-19 72793 Pfullingen | Access in STGT + RT + TUE + BB + LB | Rack +49 7127 989-X haug@schwaben.net| 150*ISDN (64kb/X.75) / 100 * K56flex | Rack +49 711 9675-X haug@seicom.NET |SAP-OSS * FTP * TELNET * NETNEWS * IRC | Rack +49 7121 709-X * 10 MBit DE-CIX * 2 MBit INXS * 5 MBit ecrc/ebone * 2 Mbit Belwue * 2 Mbit WIN
Hi !
Hi Vinny!
As i am thinking about this, i came to the idea that mostly uu.net applies filters to their downstreams e.g. there are not filtering by as - they filter by access-list what i presume is that they use a hmmm... this could be a solution, but from what source does uunet generate this filter-list ? The Ripe-Database contains this route object:
route: 151.189.0.0/16 descr: CALLISTO origin: AS6751 notify: guardian@seicom.net notify: guardian@germany.net mnt-by: AS6751-MNT changed: wh@seicom.net 19980126 source: RIPE
access-list xyz permit 151.189.0.0 255.255.255.0
instead of (the correct one):
access-list xyz permit 151.189.0.0 255.255.0.0
note the difference ?
yes sure... but the question is, why did uunet change their filters within the last days without action from us or our customer ? And the magic is, the rest of 151.189.0.0 (e.g 151.189.10.0) is seen via 151.189.0.0/16...
It's probably time for them to call the uunet support to fix this.
great !, 2 Tickets are already open, and no response from uunet. A company who is about to control 60% of the us-internet market can manipulate a lot of things and make a lot of money!. I would say at least 50% of the german internet isps are connected to uunet in Frankfurt. With their wrong announcement, their customers got germany traffic over a internation link and paid for this. Whom did they pay ? right uunet.... i think this wasnt a wanted effect currently but it shows what could happen and who gets money for these mistakes. I dont care this /24 in the us, because from our view it makes no difference, but for the german isps it made a big difference. We corrected it by announcing this /24 at mae-ffm, inxs and de-cix but it cant be right that we have to change our announcement because the world-leading isp has wrong filters. And calling uunet in Frankfurt leads into a 10-minute voice claiming your call is important to us... bla bla bla... i think we gonna sent all 30seconds a mail to help@uu.net :-) hopefully their tracking systems beaks down and they are pleased to answer :-) or should we announce 198.6.1.0/24 and route it to /dev/nul... or should we dig a hole and put our uu.net problems there into .... Winfried - frustrated PS: even a mail from the german uu.net people (thanks to them!) is stil without response... -- Winfried Haug | seicom.NET & SCHWABEN.DE | Tel. +49 7121 9770- 0 Laiblinsplatz 12 | Internet+ISDN access & consulting | Fax. +49 7121 9770-19 72793 Pfullingen | Access in STGT + RT + TUE + BB + LB | Rack +49 7127 989-X haug@schwaben.net| 150*ISDN (64kb/X.75) / 100 * K56flex | Rack +49 711 9675-X haug@seicom.NET |SAP-OSS * FTP * TELNET * NETNEWS * IRC | Rack +49 7121 709-X * 10 MBit DE-CIX * 2 MBit INXS * 5 MBit ecrc/ebone * 2 Mbit Belwue * 2 Mbit WIN
Winfried Haug wrote:
Hi !
(snip)
hmmm... this could be a solution, but from what source does uunet generate this filter-list ?
they generate it by hand and then uploading it via tftp (as far i know)and you know that this is sometimes problematic because some tftp makes out of 1 2 3 4 the thing: 4 2 3 1 (or vice versa), e.g. screwing up the list. and if they have an older announcement of 151.189.0.0 255.255.255.0 in that list, it gets before the new one - BASH!
yes sure... but the question is, why did uunet change their filters within the last days without action from us or our customer ? And the magic is, the rest of 151.189.0.0 (e.g 151.189.10.0) is seen via 151.189.0.0/16...
theyx have to change all filters, when a new customer is coming in. Do you see a new customer onFFM1 or FFM2 the last weeks ? (probably)
It's probably time for them to call the uunet support to fix this.
great !, 2 Tickets are already open, and no response from uunet. A company who is about to control 60% of the us-internet market can manipulate a lot of things and make a lot of money!.
right. the idea is to call worldcom (i think you/they get the service from them) and as far i know we probably switch away from uunet in the future for just this reasons e.g. it does not make many sense when misannouncements happen) I have similar problems with uunet breaking my aggregates to let uunet more specific! that breaks mostly with my downstram customers routing going to usa over our own lines and flooding back over the uu.net uplink.
I would say at least 50% of the german internet isps are connected to uunet in Frankfurt. With their wrong announcement, their customers got germany traffic over a internation link and paid for this. Whom did they pay ? right uunet.... i think this wasnt a wanted effect currently but it shows what could happen and who gets money for these mistakes.
and both sides have to pay !!!
We corrected it by announcing this /24 at mae-ffm, inxs and de-cix but it cant be right that we have to change our announcement because the world-leading isp has wrong filters.
right. i agree.
And calling uunet in Frankfurt leads into a 10-minute voice claiming your call is important to us... bla bla bla...
i know, probably its time to get a new announcement at the incoming queue"your call is important to us so do your money!!!" (just kidding)
i think we gonna sent all 30seconds a mail to help@uu.net :-) hopefully their tracking systems beaks down and they are pleased to answer :-) or should we announce 198.6.1.0/24 and route it to /dev/nul... or should we dig a hole and put our uu.net problems there into ....
put a "teergrube" on all their networks... (for non-german, teergrube is a spam filter wholet the ports open till 5 -6 hours to track spam)
Winfried - frustrated
PS: even a mail from the german uu.net people (thanks to them!) is stil without response...
vinny: it's weekend - so not many people work only the 24/7 staff - and they are mostly quite busy doing weird things.. Jan
theyx have to change all filters, when a new customer is coming in. Do you see a new customer onFFM1 or FFM2 the last weeks ? (probably) dont know. we are no customer of uunet. We have been there (via our former upstream for nearly 2 years) and we know, why we left... We had one complete routing desaster per month leading in a nearly complete loss of connectivity for all uunet customers in ffm....
right. the idea is to call worldcom (i think you/they get the service from them)
and as far i know we probably switch away from uunet in the future for just this reasons
e.g. it does not make many sense when misannouncements happen)
yes, that why i stated, that i dont think that this is wanted by uunet, but shows what could happen :-)
got germany traffic over a internation link and paid for this. Whom did they pay ? right uunet.... i think this wasnt a wanted effect currently but it shows what could happen and who gets money for these mistakes.
and both sides have to pay !!! yes, but uunet has more lines, more money etc... they need not to care for this..
put a "teergrube" on all their networks... (for non-german, teergrube is a spam filter wholet the ports open till 5 -6 hours to track spam)
:-)
without response...
vinny: it's weekend - so not many people work only the 24/7 staff - and they are mostly quite busy doing weird things..
the problem is open for 48 hours now, without response... if i would be a uunet customer with a e1 breaking down, must i also wait more than 48 hours for a response... and they have 24*7 and they are doing crazy things within a netblock they dont administrate... Winni -- Winfried Haug | seicom.NET & SCHWABEN.DE | Tel. +49 7121 9770- 0 Laiblinsplatz 12 | Internet+ISDN access & consulting | Fax. +49 7121 9770-19 72793 Pfullingen | Access in STGT + RT + TUE + BB + LB | Rack +49 7127 989-X haug@schwaben.net| 150*ISDN (64kb/X.75) / 100 * K56flex | Rack +49 711 9675-X haug@seicom.NET |SAP-OSS * FTP * TELNET * NETNEWS * IRC | Rack +49 7121 709-X * 10 MBit DE-CIX * 2 MBit INXS * 5 MBit ecrc/ebone * 2 Mbit Belwue * 2 Mbit WIN
participants (3)
-
Jan Czmok -
rpaļ¼ insnet.net -
Winfried Haug