Spotted on local-route-server.is.co.za today:
* 41.203.16.0/22 168.209.255.8 0 3741 2905 65419 i
* 41.203.20.0/23 168.209.255.8 0 3741 2905 65419 i
* 41.203.22.0/23 168.209.255.8 0 3741 2905 65419 i
* 41.203.24.0/21 168.209.255.8 0 3741 2905 65419 i
* 41.204.216.0/22 168.209.255.8 0 3741 2905 65419 i
* 41.204.220.0/23 168.209.255.8 0 3741 2905 65419 i
* 196.22.132.0/22 168.209.255.8 0 3741 2905 65419 i
* 196.22.136.0/21 168.209.255.8 0 3741 2905 65419 i
* 196.30.125.0 168.209.255.8 0 3741 2905 65419 i
It looks like Hetzner is announcing these to MTN Business (previously Verizon Business SA) using an autonomous system number from the private range (64512 to 65535). That is perfectly reasonable as long as MTN Business strips the private ASN when they announce these routes on the Internet.
Doing this is easy (neighbor x.x.x.x remove-private-AS), and as far as I can tell, they get it right on their links to SAIX and Verizon Business Europe/US, but as you can see, not on their link to Internet Solutions.
{ 4 } Comments
Well actually there are 2 entities at fault here.
1. Hetzner for advertising this to Verizon/MTNBusiness
2. Verizon/MTNBusiness for forwarding this to IS
Hi David
Actually, no, it’s not Hetzner’s fault. They are responsible in the sense that they must have explicitly ask Verizon for this BGP setup, but there is nothing unusual about using private ASNs, as long as:
* The ISP coordinates the allocation of numbers to avoid duplication.
* The private ASN is removed from the AS-path when the prefixes are announced to peers and transit providers.
You are however correct about two entities being at fault…
I neglected to mention that Internet Solutions should be filtering this kind of trash out on their border routers, and they aren’t.
Regards,
Simeon.
Ah alright, I actually thought it should be filtered on Verizon;s side before they send it to IS’s border routers.
Seems like it’s all fixed now.
Post a Comment