DNS, BGP, IPv6 and more!

Good bye BSNL (AS9829) | New link at home!

A blog post dedicated to BSNL AS9829. It just tried so hard to become as irrelevant as it can from everyone’s life (and that doesn’t excludes me now).


So what really is BSNL btw?

  • A Govt of India telco sitting at a extensive fiber of over 600,000 Kms across the country (staying just unused and unavailable for anyone’s use!)
  • A telco which has an extensive last mile copper (which is very poorly maintained and barely works!)
  • A backbone with over 200Gbps of IP transit capacity (which completely sucks due to rotten routing)
  • An integrated telecom provider offering services from landline to DSL broadband, from leased line to datacenter services! (out of which everything fails miserably from product line to technical ground level operations)
  • An extensive manpower (which is terribly arrogant and from top to ground level staff anyone barely works!)
  • Although telecom industry just boomed, it went from 10,000 crore profits in 2004 to 8000 crore losses in 2015. And still politics goes around it!
  • While private sector was busy with focus on 4G LTE deployment, BSNL’s market share dropped below 10% in 2014
  • While private sector firms like Sterlite, Radius Infratel focused on FTTH rollouts, BSNL rolled out FTTH plans for 4000 INR/month for 50GB cap and FUP speed of (amazing) 512Kbps to ensure no one uses it
  • While Reliance Jio is about to come, Airtel is extensively launching 4G LTE, cool companies like ACT are getting more investment, BSNL is putting 6000 crore in public wifi infrastructure to give few mins of free wifi and with hop of users paying it afterwards. (Wow?!)


All above tells nothing but ways in which BSNL is 100% screwed up for now. I don’t expect it to ever pick up again. Politically, technically, and fundamentally it’s a mess.

I became BSNL broadband user in 2008 and it has been over 7 years of (painful and terrible) experience with them. As a company which put so much of infrastructure to connect India worked extremely hard to do as many stupid things as possible. For me trouble remained that in my city they were only wired telecom provider for retail services.


Last month I got a long haul circuit from Airtel (provisioned on fiber) between my city and a friend’s ISP PoP for 10Mbps bandwidth. Circuit is delivered at a Airtel BTS site location (slightly away from my home) and I have installed Microtik SXT Lite 5’s shooting link from there to my home (around 1km link with clear LoS). This is a usual long range fixed wireless RF link over un-licensed 5.8Ghz band. (Thankyou govt. of India for delicensing it in 2007 and making available for public use). Thanks to companies like Microtik and Ubiquiti for opening up world of good fixed wireless radios and antennas which really work great and are available for quite good prices. I got pair of SXT Lite5’s from Amazon.in at 7700 INR (~$116).

Fortunately BTS site has a private WISP tower and the owner of tower agreed to let me use his tower for my radio for reasonable price.



Some statistics about my new link


Airtel BTS site

Airtel BTS Site




LoS of tower (from home)




Radio at my rooftop

Radio on rooftop



(Water tanks pipes were tall enough that I didn’t had to mount any pole and used those pipes)


Closer look

Radio at home


Link quality checks

Radio link stats


I am getting end to end bandwidth of around 35Mbps between radios (while provisioned bandwidth is 10Mbps on backend). I am using 5Mhz of channel bandwidth with 802.11 protocol and usual WPA2-PSK works to have encryption between radios.

End to end latency between Rasberry Pi (connected via wired to my home router) to other end radio:


And lastly speedtest from a server far away from here:



(Note: Hided ISP name to avoid un-needed DDoS attack on them which are hitting my blog from few weeks)



Some thoughts on fixed wireless links

  1. Work great if LOS and free channels are there. India does has serious problem of very low unlicensed open spectrum permitted for outside use.
  2. Hard to predict capacity for large country like India – may work somewhere, may not somewhere.
  3. WISP stupidly use 20Mhz and HT beams of 40Mhz when even 5Mhz can do job for many of their links. (More “bandwidth” usage = reducing channels for others + more potential chances of interference).
  4. Links work well given 1st Fresnel zone is cleared. Special thanks to my friend Brough Turner for pointing this out. He runs an ISP based on this technology in Boston & surrounding areas. (Checkout netblzr)
  5. Fixed wireless is NOT mobile wireless (understand the difference!).
  6. Some other successful ISPs using this technology – MonkeyBrains in San Francisco (on unlicensed spectrum) and Webpass (using microwave links).
  7. Tikona in India used it a bit but with mesh to increase coverage and eventually got a network with latency & packet loss issues. Wireless links work well but for point to point and very little point to multi-point. Not good choice for a large network with wireless nodes acting as transport in between. Indian media as usual stupidly took technology as swiss knife solution to broadband issues. (checkout NDTV review of Tikona).
  8. Tech and NOG community across India have to support for more un-licensed spectrum for use in India. (Excellent article on this here)
  9. I am overall motivated by excellent paper – America’s Broadband Heros which gave very detailed understanding of technology and limitations
  10. I am overall happy with 2.5x increase in download speed but a whopping 20x increase in upload speeds. Fixed wireless has a good edge over upload speeds when compared to DSL


Ending this blog post with Cacti graph of my home broadband connection for last one month. There’s high amount of systematic transfers of routing table data and some other stuff. I do keep a Rasberry Pi running all the time as home server. :)


Home Broadband Graph


Multiple IP’s on Linux servers

One of things which people often asked me around in past was on how to have multiple IPs on Linux machine under various circumstances. I know there are ton of blog posts about this but very few explain how it works and possible options under different use cases etc.


I will share router side and server side config with focus on how it should be done from server end. Assuming server side config to be for Ubuntu/Debian. You can find similar concept for CentOS.


Say you have a router on IP and server on IP on a /24 ( subnet. Assming that entire is available for server’s connectivity. Setup would be like:

R1 - Server 01 connectivity

Configuration so far is super simple. You have got placed on R1’s interface (g1/0) which connects to server01 and server01 has


and on server’s config is:


Now let’s say you want to add additional IP’s to the server. There can few ways:

  1. You may add more IP’s from this same pool i.e un-used IP’s from within
  2. You may add more IP’s from all together different pools say from


When adding new IP’s/additonal IPs to server, you must understand that they would be either via layer 2 (i.e those IP’s will generate ARP packets on the interface connected to the router) or would be layer 3 i.e routed IP’s which are routed “behind” an existing working IP (like in this case. Another case you can have is additonal IP’s which are eventually NATTed behind public IPs which I will also discuss in the end.


Layer 2 based addition

When IP’s are from layer 2 – they are are supposed to be present on the interface so that they reflect in ARP and hence machines on the LAN do IP to MAC conversion and route packets destination for those IPs. Currently connected interface here is eth0 and hence new IP’s should be eth0 only. Thus you can add those IP’s by creating so called “alias interface”. eth0 can have eth0:1, eth0:2 etc as alias. IP’s can also be added on same single eth0 interface.

Since entire pool is available for use between R1 and server01, this doesn’t needs any change at R1 end. On server end, we can add IP as:


Temporary addition (will get removed after reboot):


So there we go – two IP’s added on eth0 itself.



Let’s try to ping them from router:


And so it works. Now, if we examine ARP table for g1/0 interface of router (which connects to server01) we will find all these three IP’s which are in use by server.


Another way of doing same thing is by creating alias interface and adding IP’s on it. So we can add following in the /etc/network/interfaces:


Being those interfaces up using: ifup eth0:1 and ifup eth0:2. A logical question  – where to put gateway often comes up and confuses. Keep in mind as of now all IP’s are coming from same single device R1 and IP at R1 end is and hence single gateway in eth0 config is good enough to ensure that traffic to any IP outside pool can be routed via Let’s say you want to add IP from a completely different pool (for some reason) on server like Here you can do it via layer 2 by first defining an IP as secondary on R1 and add IP as alias on the server.


On Server01 end:


This simply ensures that both R1 and Server01 get in single broadcast domain which has broadcast address and hence can speak to each other. Again, in this case as well on router end – router gets ARP for IP and that tells how to reach. ARP table (IP to MAC address conversion) and forwarding of packets based on Mac (Mac table: Mac >> Interface conversion).


Another way of layer 2 setup can be by either patching an un-used extra port and have separate network on it (separate IP / subnet mask). You can also have a setup where you send tagged VLAN till server and untag it on the server. I will put blog post about it later on.


Layer 3 based addition

Due to scalability as well as scarcity of IPv4 address issue, layer 2 based method isn’t the best one when it comes to adding of additional IP’s. Layer 3 setup is simply where additional IP’s are “routed” behind a working single public IP.

So e.g thought it’s better to use /30 for P2P (infact /31!) but let’s keep same case going. We have on R1 and on Server01 and both are in /24. Now to allocate say to server, we can route this IP behind


So setup on R1:


This will ensure that all packets going towards (single IP) are routed to which is on server01. Next, we can add this IP on existing loopback interface lo or a new alias of loopback as lo:1.

ip -4 addr add dev lo for temporary addition (removed after reboot) and

auto lo:1
iface lo:1 inet static


So how exactly this works? It’s important to understand it as it explains key difference between IP’s added on interface Vs IP’s routed. Let’s see “sh ip route” output for and


Here clearly there’s a “directly connected route” while for there’s a static route towards


Some of key comparison point layer 2 Vs layer 3 based setup:

  1. With layer 3 method you can have as many IP’s as want on server without getting into CIDR cuts. So e.g if you want to add entirely new pool to server, you would need at least 2 IP’s (a /31). If you want just 3 IP’s then you would need a /29 (consuming 8 IPs) and so on. This approach has issue as it wastes lot of IPs and that becomes critical when we are almost out IPv4. In IPv6 that’s no issue at all.
  2. With layer 3 you can have a setup where addition of IP’s doesn’t really creates any layer 2 noise (ARP packets). So e.g you can use just and then route entire behind server. This will ensure that server can use without generating any ARP for it and router will just have one single routing table entry for that enture /24. ARP would be just for single IP which is used to connect R1 with the server.



I hope this will help you !

Subscribe to my blog

Enter your email address: