28 Apr

Tanzania Telecom leaking Telia routes to Tata

Last night I was looking at routing tables and saw a interesting case where for a specific route.


Here’s what I got from Tata’s AS6453 looking glass:

Router: gin-ldn-core4
Site: UK, London, LDN
Command: show ip bgp

BGP routing table entry for
Bestpath Modifiers: deterministic-med
Paths: (4 available, best #4)
Multipath: eBGP
17 18 19

33765 1299 3549 9829, (received-only)
ix-3-1-2.core4.LDN-London. from ix-3-1-2.core4.LDN-London. (ix-3-1-2.core4.LDN-London.)
Origin IGP, valid, external

4755 9829
mlv-tcore2. (metric 3605) from l78-tcore2. (
Origin IGP, valid, internal

4755 9829
mlv-tcore2. (metric 3605) from l78-tcore1. (
Origin IGP, valid, internal

4755 9829
mlv-tcore2. (metric 3605) from ldn-mcore3. (ldn-mcore3.)
Origin IGP, valid, internal, best


The first route in table seems pretty weird. AS path isย 33765 1299 3549 9829 i.e clearly AS33765 sitting in middle of AS6453 and AS1299. This must be a route leak since Tata AS6453 and Telia AS1299 are way too bigger then Tanzania telecom and hence there’s no possibility of Tata transitting via Tanzania telecom. Though issue seems for just one specific route for BSNL which Tanzania telecom is learning from Telia, which further is getting from Global Crossing AS3549 (one of upstreams of BSNL).ย 

As per RADB both Telia and Tata Comm are upstreams of AS33765.

anurag:~ anurag$ whois -h whois.radb.net as1299 | grep 33765
import: from AS33765 action pref=50; accept AS-33765
export: to AS33765 announce ANY
mp-import: afi ipv6 from AS33765 accept AS-33765
mp-export: afi ipv6 to AS33765 announce ANY
anurag:~ anurag$
anurag:~ anurag$
anurag:~ anurag$ whois -h whois.radb.net as6453 | grep 33765
import: from AS33765 action pref = 50; accept AS33765
export: to AS33765 announce ANY
anurag:~ anurag$


With hope that you are not leaking routes between two tier 1 networks, time for me to start my day! ๐Ÿ™‚

26 Apr

IRINN | APNIC inetnum range confusion

Last week I saw an interesting post at APNIC mailing list about IRINN (recently formed NIR in Indian region).ย 


Poster Jimmy was concerned about IRINN’s netname

inetnum: –
descr: Broadcast addresses
descr: These addresses cannot (should not) be routed on the Internet.
country: IN
admin-c: IH1-IN
tech-c: IH1-IN
remarks: send spam and abuse report to info@irinn.in
mnt-by: IRINN-HM
mnt-lower: IRINN-HM
changed: hostmaster2@irinn.in 20130420
source: IRINN


As per first two lines entire IPv4 address space i.e (ranging from to was put as IRINN-Broadcast while expected was IANA broadcast (since IANA sits on top in this RIR & NIR hierarchy).

Right after that post IRINN came into action and changed values to:

inetnum: –
descr: Broadcast addresses
descr: These addresses cannot (should not) be routed on the Internet.
descr: http://www.apnic.net/db/RIRs.html
country: US
admin-c: HM20-AP
tech-c: NO4-AP
remarks: This is a placeholder object to ensure no objects are created
remarks: in the enclosing range.
mnt-lower: MAINT-APNIC-AP
changed: apnic-dbm@apnic.net 19991214
changed: hm-changed@apnic.net 20040926
source: APNIC


This had correct netname suggesting IANA but source is APNIC and moreover it got a really interesting inetnum i.e to This really sounded bit weird to me as I was expecting entire IPv4 address range here and start from rather then from sounds confusing.ย 


I did some testing and saw results from whois db were different based on query. I was getting range from to if I query APNIC db for while for (without /0) I was getting expected range to I posted about this in APNIC mailing list to figure out reason for these strange numbers.

I got a really interesting reply from Leo Vegoda from ICANN:

I agree that it seems quite odd. 255/8 is part of 240/4. In 240/4 the only address whose use has been defined is, which is used for limited broadcast. The rest of 255/8 does not (yet) have a defined use. You can find the details here: http://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xml

Regards, Leo

Right after his reply, Guangliang from APNIC posted clarification and actually fix too. ๐Ÿ™‚

Thanks to Anurag for pointing out this and Leo for your clarifications. The inetnum object – was created in 1999 to reflect that Broadcast reservation. We have now removed it from the APNIC whois database to avoid any confusion.

Best regards,



So yet another interesting case from internet world. Time for me to get back to work, have a good time ahead! ๐Ÿ™‚