You have a /22, you want /24′s, 2 bits give you 4 sub-nets. Or you want one /24, so you break the /22 into two /24′s and a /23. Not rocket science. It’s the kind of thing you can do in your head and keep track of in a spreadsheet or a text file if you don’t have too many networks.

When you’re planning an IP addressing scheme, you probably have the luxury of time, to think about it. But what if you need to do this in a crisis situation? Fortunately it has never happened to me, but I can think of scenarios where you need to do this very quickly:

Apparently, if you use BGP to advertise a network to the Internet and specific hosts within that network become the target of a DDoS attack, one way to mitigate the attack could be to stop advertising the /24 sub-nets being attacked. Although this means the attacker still succeeds in taking down his intended targets (because he made you take them down), at least you can remove the attack traffic from your link, and the rest of your network can remain available.

Another scenario might be someone hijacking part of your network by advertising a more specific route than you are (either intentionally, or due to a BGP filtering misconfiguration). This happened to youtube last year.

Either way, you’ll need to split the network into at least two (in the case of a /23) sub-nets to get a /24, which is generally the longest prefix accepted on the Internet. In the former case, you want to withdraw the more specific network, and in the latter you want to advertise it.

To this end, I have written a script that accepts a list of networks (in CIDR format, one per line) from STDIN, and the desired sub-net as the first command line argument. It loops through the input subnets, looking for the one that overlaps with the desired prefix. If a network doesn’t match, the script just prints it out untouched, if it does, then the script will de-aggregate that network into the minimum number of sub-nets in order to get the desired sub-net as one of the outputs. It prints the surrounding pieces, and unless you specify “-exclude” as the second argument, the desired sub-net itself is also added to the output:

#!/usr/bin/python
# deaggregate.py - deaggregate a network for a specific subnet, yielding the minimum number of subnets
# Add -exclude to only output the surrounding subnets. Subnet is read from stdin, all non matching subnets
# are output untouched. Use as a filter, rinse, repeat.
# Simeon Miteff <simeon@localloop.co.za>
from IPy import IP
import sys
 
def split(ip,sub,exclude):
    if ip==sub:
        if not exclude:
            print ip
    else:
        a = IP(str(ip.net())+'/'+str(ip.prefixlen()+1))
        b = IP(str(IP(ip.net().int()|2**(32-(ip.prefixlen()+1))))+'/'+str(ip.prefixlen()+1))
        if a.overlaps(sub):
            print b
            split(a,sub,exclude)
        elif b.overlaps(sub):
            print a
            split(b,sub,exclude)
 
if __name__=="__main__":
    if len(sys.argv)<2:
        sys.stderr.write("Usage: %s CIDR_prefix [-exclude]\n" % sys.argv[0]) 
        sys.exit(1)
 
    sub = IP(sys.argv[1])
 
    exclude = False
    if len(sys.argv)==3:
        if sys.argv[2]=='-exclude':
            exclude = True
 
    for line in sys.stdin:
        pre = IP(line.strip())
        if not pre.overlaps(sub):
            print line.strip()
        else:
            split(pre,sub,exclude)

An example run:

simeon@capybara:~/personal$ cat routes.txt
10.0.0.0/10
192.168.0.0/16
simeon@capybara:~/personal$ python deaggregate.py 10.0.100.0/24 < routes.txt
10.32.0.0/11
10.16.0.0/12
10.8.0.0/13
10.4.0.0/14
10.2.0.0/15
10.1.0.0/16
10.0.128.0/17
10.0.0.0/18
10.0.64.0/19
10.0.112.0/20
10.0.104.0/21
10.0.96.0/22
10.0.102.0/23
10.0.101.0/24
10.0.100.0/24
192.168.0.0/16
simeon@capybara:~/personal$

It requires the IPy module (apt-get install python-ipy). To handle multiple desired sub-nets, run the script again for each subsequent sub-net, using the output of the previous run as the input. Note that your (and your upstream's) filters might need to be updated (unless your original prefix is allowed with something like "le 24").

I've added this to the code page. Thanks for listening :-)

ZA Internet Map (click for full size image)

• Only local autonomous systems are included. I’ll probably include the first international upstreams, in the next version.
• Only the inbound path (international transit, probably) as seen from RouteViews OIX is shown. This means peering links are not indicated. That might also change in the next version.
• This is not an ISP map, like Greg Massel’s, because it includes all autonomous systems, including non-ISP’s such as customers/end-users running BGP. I’m toying with the idea of colour-coding different types of ASes.
• There are likely to be errors. If you spot them, please let me know so that I can correct my scripts.

It seems their transit via First National Bank’s own network went down. FNB, in turn, buys transit via IS and MTN Business. FNBConnect’s transit via Telkom SA (SAIX) is still working though, so they are reachable from MTN Business (and the rest of the Internet) via SAIX.

Spot the odd one out...

In the graph on the right I’ve used green to indicate the links and ASNs we know for sure are getting the FNBCONNECT route. Orange indicates the links and ASNs of unknown status, while red shows what is definitely not working.

We at least know that their transit to IS via FNB worked when I first blogged about FNBCONNECT:

* 41.183.0.0/16 168.209.255.8 0 3741 17148 37028 i

So which is more likely, SAIX screwed up their outbound filters on their peering links to IS but not to MTN Business, or IS screwed up their inbound peering filters and its only showing now because their preferred route was via their customer?

This is possibly the third time I’ve noticed a peering problem involving IS, where no problem existed between IS’ peer and another peer (like SAIX or MTN Business).

The end result? IS is routing like we’re back in 1996!:

local-route-server>traceroute 41.183.0.0

1 ar2-rba-tnr-gi0-3-11.ip.isnet.net (196.34.7.195) [AS 3741] 0 msec 4 msec 4 msec
2 core1b-rba-gi1-0-5.ip.isnet.net (196.26.0.181) [AS 3741] 4 msec 4 msec 4 msec
3 mi-za-rba-p5-gi0-1-101.ip.isnet.net (168.209.164.49) [AS 3741] [MPLS: Label 2594 Exp 1] 172 msec 172 msec 176 msec
4 mi-uk-dock-p3-po2-0.ip.isnet.net (168.209.224.65) [AS 3741] [MPLS: Label 2859 Exp 1] 172 msec
5 core1a-dock-gi1-0-0-101.ip.isnet.net (168.209.164.0) [AS 3741] 184 msec 176 msec
6 core1b-dock-gi0-0-2.ip.isnet.net (168.209.246.1) [AS 3741] 176 msec * 172 msec
7 gi8-13.mpd01.lon02.atlas.cogentco.com (149.6.148.1) 180 msec 176 msec 172 msec
8 te4-2.ccr01.lon01.atlas.cogentco.com (130.117.1.201) 172 msec
9 vl3493.mpd01.lon01.atlas.cogentco.com (130.117.2.17) 172 msec
te3-1.mpd01.lon01.atlas.cogentco.com (130.117.3.225) 176 msec
vl3493.mpd01.lon01.atlas.cogentco.com (130.117.2.17) 172 msec
10 te1-2.ccr01.lon05.atlas.cogentco.com (130.117.49.94) 172 msec 176 msec
11 149.6.2.194 184 msec 180 msec 180 msec
12 rrba-ip-esr-1-ge-6-0-0.telkom-ipnet.co.za (196.43.11.166) [AS 5713] 184 msec 184 msec 184 msec
13 first-national-bank-gw.telkom-ipnet.co.za (196.25.207.178) [AS 5713] 188 msec 188 msec 188 msec
=== snip ===


Update:
Dear Readers

I’ve decided that if I’m going to moan, complain, and accuse ISPs of FAILure on this blog, then I should at least follow my accusations up, and provide constructive post-mortem commentary (where possible). So here goes:

IS->FNBConnect traffic is flowing via FNB again. Also see the comment from Nick Treasure (IS).

Regards,
Simeon.

This is what Roelf Diedericks of Neology had to say about it:

Neology supplies IAP services to ISP’s in the local market, this includes radius, billing and RealSoon(tm), ADSL IPConnect termination for multiple ISP’s.

We will be offering the first consumer ADSL service with differentiated local, versus international radius accounting, and many other cunning differentiated traffic billing plans which cannot as yet be revealed :)

Simply awaiting Telkom to do their bits at the moment.

So, while their AS is new to the routing tables, Neology is certainly not new to the local telecoms business.

It’s good to see someone has solved the (non-trivial) problem of accounting national and international traffic separately… this is something that IS wasn’t willing (or able) to do even when their customers specifically asked them for it on IS Labs.

* 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.

Since I’ve just updated the table using a fresh copy of IS’s “local” routing table (minus their African and Malaysian peers), we can check if opening the licensing floodgates has lead to many new South African networks popping up in the BGP table. There are four new ASNs, so the short answer is “not really”. The list follows:

AS35405 (Macquarie Bank)
This is an end user, so not due to regulatory changes. As you can see, they are dual homed (like most of the Banks are), but they’re running their second link in backup-only mode by announcing sub-prefixes on their primary link (similar to my setup for UCT). Datapro is their primary provider and Neotel is backup:
* 87.236.68.0/24 168.209.255.8 0 3741 36937 35405 ?
* 87.236.68.0/23 168.209.255.8 0 3741 11845 35405 ?
* 87.236.69.0/24 168.209.255.8 0 3741 36937 35405 ?

AS37028 (FNBConnect)
This is First National Bank’s new IPConnect-based ADSL service provider and VOIP operator. If I recall correctly, they would need at least an IECS license to do this, but they probably got the happy meal (IECNS+IECS) anyway. They transit through the bank’s original AS:
* 41.183.0.0/16 168.209.255.8 0 3741 17148 37028 i

AS37049 (South African Digital Villages (Pty) Ltd)
This one is a mystery so far. The name sounds like someone who wires up housing or office complexes and sells them bandwidth. They transit through SAIX:
* 41.222.136.0/21 168.209.255.8 0 3741 5713 37049 i

AS37079 (SMMT Online)
Finally, the winner of the Gauteng Online tender to provide connected computer labs for the province’s schools. They transit through Neotel:
* 41.154.0.0/16 168.209.255.8 0 3741 36937 37079 i

• As per Joe’s request, it is now sorted first by the equivalent number of class C networks (/24 prefixes) advertised, and then by the real number of networks. Unfortunately it also counts sub-prefixes, so for example, UCT’s overlapping /16, /24 and two /17s are counted as 513 /24s instead of 256. I hope to fix this soon. Fixed.
• As per Colin’s request, there is a script that renders the table as machine-processable CSV, here: http://www.localloop.co.za/za_asn.php.

Because the primary link was both fast (by South African standards) and very expensive, I had to figure out a way to provision the backup link on a budget that was non-existent by comparison. What I came up with was to get Amobia to install a point-to-point link from UCT to their sister company Frogfoot Networks, who agreed to sell IP transit based on per-gigabyte traffic volume, instead of bandwidth. With this deal, UCT could minimize costs by only using the backup link during a primary link failure. The IT managers were very supportive, and so this pet project of mine materialized within a few months.

I leaned three things due to the backup-only nature of the setup that (in my view) isn’t immediately obvious from the standard CC[NP|IE]-curriculum’s version of BGP multi-homing:

1. Influencing inbound path selection:
   The usual mechanisms for influencing BGP inbound path selection (applicable to separate upstreams, so MED doesn’t count) is to perpend your own ASN a number of times on the path you want less likely to be selected. Apart from the difficulty of getting the length right, the other problem with this approach is that there is no guarantee that someone else’s routing policy won’t override your carefully adjusted AS-path length. In fact, most network operators will apply a policy where they adjust the local preference of routes so that customer routes are used before peering routes, and peering routes are used before transit routes.

   This is usually not a train smash for a multi homed end-user site that wants to balance load over their Internet links. In fact, they might specifically want BGP to select the best path, both inbound and outbound. However, since I wanted the backup link to only be used during a failure, I chose to short-circuit all of the BGP route selection by advertising more specific routes (two /17s instead of one /16) via the primary link.

2. 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.

3. Adding peering to the mix:
   You may have noticed that I mentioned that Frogfoot Networks is the backup ISP, but I’m talking about Verizon above. This is because the Friendly Frogs agreed that they would not bill UCT for peering (traffic between UCT and them and their customers). To make the route selection work, I worked with Warwick at Frogfoot to implement a system of route-maps that allows UCT to mark routes for transit or peering. UCT advertises both /17s and the /16 to Frogfoot, but marks the /17s with the “Don’t announce to your upstream” community.

An example of a route server in South Africa is local-route-server.is.co.za, which is used by geeks to get an up-to-date list of “local” IP networks by running the show ip bgp Cisco command. A popular use for this information is “split routing” – a trick you might use if you have more than one Internet connection, especially if one of them is local-only (split routing is described here and here).

Other route servers, like the one at SAIX and Verizon Business SA, are probably not as well known. You’re unlikely to need them unless you’ve advertised a new BGP route to your ISP, and you need to check that it’s being received by their peers and providers. For this reason I tend to forget the host names of these more obscure route servers.

After the third time I had to resort to Google to find Verizon’s route server, I started making a list, which I’ve now published here: http://localloop.co.za/route-servers

So how do you use them?

Lets look at a simple example: suppose we want to find out how Neotel is doing BGP-wise. We look up the IP address for www.neotel.co.za and then log onto the IS route server:

local-route-server>sh ip bgp 196.34.133.113
BGP routing table entry for 196.34.0.0/15, version 392335447
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x208
Not advertised to any peer
3741
168.209.255.8 from 168.209.255.8 (168.209.255.245)
Origin IGP, localpref 100, valid, external, best


That number, 3741 is the as-path, and it’s telling us that the route is originating from AS3741 (Internet Solutions). That doesn’t seem right… Neotel just being an IS customer? Lets try one of their DNS servers: ns0.neotel.co.za:

local-route-server>sh ip bgp 41.160.0.4
BGP routing table entry for 41.160.0.0/12, version 392335736
Paths: (1 available, no best path)
Flag: 0x208
Not advertised to any peer
3741 36937
168.209.255.8 (inaccessible) from 168.209.255.8 (168.209.255.245)
Origin IGP, localpref 100, valid, external
Community: 3741:1111 3741:2000


Thats more like it, now the as-path has two numbers: 3741 and then 36937, which turns out to be Neotel. As you’ve guessed by now, the as-path shows us the path of autonomous systems through which the route is being advertised. Now that we know Neotel’s ASN, lets get a list of all the routes from them:

local-route-server>sh ip bgp regexp 36937
BGP table version is 392337041, local router ID is 196.4.160.227
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
* 41.160.0.0/12 168.209.255.8 0 3741 36937 i
* 87.236.68.0/24 168.209.255.8 0 3741 36937 35405 ?
* 87.236.69.0/24 168.209.255.8 0 3741 36937 35405 ?


Ah, now a /12 is a decent block of IP addresses. Notice that this shows two other routes with 35405 at the end of the as-path. These are routes from Neotel customers, in this case, someone called “Macquarie Bank South Africa”. If we only wanted to see routes originating from Neotel, we could have used sh ip bgp regexp _36937$ instead (“_36937$” is in fact a special kind of regular expression: “_” is short for “^|[,{}() ]|$”).

Please let me know if I missed any local route servers. I know MTNNS has a looking glass on their website, but it’s been broken for a long time. I reported the problem to a NOC email address they give for “questions and comments”, but they ignored me (big surprise).

My intention with this blog is to write some posts and create some pages about networking and Internet in South Africa. Some of my ideas for topics are about industry issues, while others are purely technical, but lets just see where it goes…

The first actual content is my table of local (that is, South African) Autonomous Systems (usually this means: large Internet-connected networks). The list was compiled with AfriNIC’s list of assigned AS numbers as a starting point, and then cross-referenced with BGP tables, and info from various WHOIS sources (including RIPE, ARIN, AfriNIC and some IRR databases).

I’m hoping this is useful to someone. Please let me know what you think.

Cheers!
Simeon.