Any logical reason for unnecessary entries on BGP server

[Pada]

I would like to know if there is a local reason to why the public-route-server.is.co.za reports so many unnecessary (redundant/encapsulated/adjacent) routing entries, which you can get your hands on when you telnet in to public-route-server.is.co.za and query: show ip bgp.

Now I'm particularly interested in why they have to many redundant/adjacent routing entries. If you use their list of routing entries, you will have like 1400+ entries in your routing table, which can be reduced to roughly 700 when you remove those that are encapsulated by other routes or by combining adjacent routes.

eg.
41.0.0.0/16 encapsulates 41.0.5.0/24, 41.0.6.0/24, ..., 41.0.x.0/24

The only thing that I can guess that makes sense to have encapsulated/adjacent routes, is to use different entries to provide more detailed routing info that the ISP requires to route the traffic to/from those IP ranges?

 

[cenuij]

The only thing that I can guess that makes sense to have encapsulated/adjacent routes, is to use different entries to provide more detailed routing info that the ISP requires to route the traffic to/from those IP ranges?

I guess something like that ...

BTW, you can get information on who a certain ip (range) belong to by querying the Afrinic database at http://whois.afrinic.net/cgi-bin/whois. According to them, "The IP Block 41.0.0.0/16 has been assigned to Vodacom Bussiness for ISP bussiness" (sic), and 41.1.0.0/16 "Assign to the Vodacom Wimax BU". Seems like the whole 41.0.0.0/8 and 196.0.0.0/8 ranges belong to Africa?

Also, some of the routes from IS seems not to be known in this database, while others are not truly local (as in South Africa local), but assigned to businesses in Namibia or wherever. For eg 139.92.100.0/24, according to RIPE at http://www.db.ripe.net/whois it belongs to a range assigned to "AT&T Global Network Services Europe". Maybe in some way all of them are somehow connected to IS? Dunno ...

 

[Tinuva]

I believe I found your answer on a blog from a guy who used to work at UCT:

http://localloop.co.za/archives/91

I refer specifically to point 2, but read the whole blog post:

# What happens during a failure:
This scheme works well when the link between the customer and the primary ISP fails: the /17s disappear from the global BGP tables, and the remaining /16 being advertised via the backup ISP is selected by everyone (including the primary ISP).

If the primary ISP experiences a partial failure, for example, if their international link goes down, but the national peering keeps working, then the backup ISP still sees the /17s coming from the customer via the primary ISP, but traffic directed from international networks to the customer arrives at the backup ISP via the /16 route.

What happens now? Does the backup ISP send this traffic via the /17 routes? It turns out in the UCT setup, Verizon Business South Africa discards that traffic. Perhaps they do some filtering to prevent transit between their upstreams and their peers?

If you work for Verizon and you understand why this happens, please drop me a comment.

A possible work-around could be to monitor reliable international beacon prefixes (or just the total number of prefixes) on the primary link, and withdraw the /17s if they disappear.

 

[Pada]

Also, some of the routes from IS seems not to be known in this database, while others are not truly local (as in South Africa local), but assigned to businesses in Namibia or wherever. For eg 139.92.100.0/24, according to RIPE at http://www.db.ripe.net/whois it belongs to a range assigned to "AT&T Global Network Services Europe". Maybe in some way all of them are somehow connected to IS? Dunno ...

Fragtion gave me scripts that he's using to route the local traffic. He got his routing info from http://ip.ludost.net/cgi/process?country=1&country_list=za+na+mu+zw+zm+sz+ls+bw+mz&format_template=prefix&format_name=&format_target=&format_default=, which includes routes for South Africa, Namibia, Mauritius, Zimbabwe, Zambia, Swaziland, Lesotho, Botswana and Mozambique. Even the one for South-Africa only from that IP <-> Country database at LUDOST.NET site includes a couple of routes that aren't on the IS server and vice versa.
The cool thing about the LUDOST.NET queries are that they remove all the unnecessary routing entries by combining adjacent/removing encapsulated routes!

Like 213.62.240.0/24 belongs to South Africa Network Of Realtime Travel Connections & 213.62.241.0/24 belongs to South Africa Johannesburg Network Of Amadeus Southern Africa - both of which aren't in the IS public-route-server. Also, the IS public-route-server includes a couple of 31.xxx.xxx.xxx/24 routes, which belongs to United States AT&T Global Network Services.
I used http://whois.domaintools.com/ to lookup the origins of the IP's.
Now the question is, where should we get our local IP ranges from?

I believe I found your answer on a blog from a guy who used to work at UCT:

http://localloop.co.za/archives/91

I refer specifically to point 2, but read the whole blog post:

Thanks Tinuva, that was more like what I was hoping for, although it doesn't exactly explain IS's case

 

[Gatecrasher]

Good find!

I guess the questions about ip.ludost.net that I have are:

• Is it reliable and frequently updated?
• Are the differences and omissions minor?
• Is "local" as effected by Telkom/IS restricted to za, or does it also include SADEC countries?

 

[Roman4604]

is to use different entries to provide more detailed routing info that the ISP requires to route the traffic to/from those IP ranges?

Exactly. The routes a particular ISP carries are not created by themselves, but are rather learnt from other ISPs/networks using BGP. Multiple redundant paths and the purposeful steering of traffic (specific IP nets/supernets/subnets) via these different paths will result in non-uniform routing tables.

Its just the way it is (all over the Internet), nothing you can do about it.

 

[Pada]

Good find!

I guess the questions about ip.ludost.net that I have are:

• Is it reliable and frequently updated?

It's updated frequently - like once a day:

IP address distribution by country (updated daily)

• Are the differences and omissions minor?
• Is "local" as effected by Telkom/IS restricted to za, or does it also include SADEC countries?

I would really like to know that too! And also if the local routes found at public-route-server.is.co.za are applicable to SAIX internet accounts...

 

[Locality]

Certainly some interesting discussion, and something I too have been trying to get my head around recently. Unfortunately there is no elegant solution that I've come across yet, that encompasses an all-around solution to these problems. An example even, that I'm aware of, are certain Namibian IPs that are accessible via IS local accounts, which would imply the possibility that, at least via IS, some neighbouring countries are regarded as local. What of the way in which SAIX handle such traffic though?..

One things for certain, there's certainly no clear cut way in which the Internet operates in Africa.

Having recently suggested to Gatecrasher, though, Maxmind (whose core business is geolocation) have indicated that it'd be acceptable to publically redistribute their ZA IP blocks in route format. I've written a Perl app which runs the blocks through the extension Net::CIDR::Lite, and outputs a CIDR notation. I've found this to be more accurate than ip.ludost.net even. I've made the routes available in CIDR and subnet masked format (for use with Route Sentry):

http://developers.locality.co.za/routes.txt
http://developers.locality.co.za/routes-rs.txt

I'm willing to make corrections to these routes files through suggestion too, so I'm all for making them as accurate as possible. Also, as would be obvious, they're hosted locally which is beneficial.

 

[Locality]

SADC routes accessible locally

To confirm prior suspicion about the role of SADC countries in local routes. I can confirm, based on brief testing of neighboring countries IP addresses, on a local IS account, that the following are accessible: Botswana, Lesotho, Mozambique, Namibia and Swaziland.

It'd be great if someone else could confirm this too. It's quite possible that SAIX local accounts would work too, as a quick tracert indicates that IS peers via SAIX for both Namibia and Botswana.

eg. http://www.telecom.na
eg. http://www.btc.bw

As a consequence you can now find SADC inclusive local routes databases, in the same formats as the current local routes database, on the developers wiki.

 

[hilton]

Locality, what's the difference between these two lists?

http://developers.locality.co.za/routes.txt

and

http://developers.locality.co.za/maxmind-routes.txt

I mean which one is more accurate?

 

[Locality]

I mean which one is more accurate?

http://developers.locality.co.za/routes.txt will always attempt to be the most accurate as its primarily used in existing scripts such as Gatecrasher's, for DD-WRT supporting routers.

The Maxmind local routes database is only updated, by Maxmind themselves, once a month, though corrections are made as they're cited, and is otherwise updated once a week.

 

[hilton]

http://developers.locality.co.za/routes.txt will always attempt to be the most accurate

Thanks very much for the input.

 

[Pada]

I'm still wondering why we aren't using 41.0.0.0/8 instead of 41.0.0.0/11, 41.112.0.0/12
41.138.64.0/21, etc.

If you dial a WebAfrica SAIX account with the "Use default gateway on remote network" option unchecked, it automatically adds 41.0.0.0/8 to route through that connection.

Like http://www.zanews.co.za with ip 196.220.43.90 isn't listed on the public-route-server.is.co.za, BUT using http://developers.locality.co.za/routes.txt list, it is encapsulated by 196.220.32.0/21. I've tested it and the page loads awfully slow using my OpenWeb local only account, and it doesn't load at all using the WebAfrica 200GB local only trial account
At least http://www.mg.co.za/zanews doesn't have any issues like that