DNS, BGP, IPv6 and more!

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 !

BSNL AS9829 – A rotten IP backbone

Today I met a good friend and he has recently moved back into Rohtak (like me!) and was crying over BSNL’s issues. He has issues of unstable DSL due to last mile and I told him that even if last mile works well, BSNL still has got ton of issues with their IP backbone traffic.


It’s Sunday late night out here in India and I am having really pathetic connectivity with just everywhere except Google. With Google only key difference I noted is that my TCP session to Google’s services is terminating at Mumbai and not Delhi anymore.

First and formost, I did trace to spectranet.in (which is last company I was working for) to see how is my latency with server hosting it:

Clearly this seems to be going via NIXI but as soon as I hit NIXI IP (configured at destination network), the latency jumps up. This clearly is a symbol of bad return path. Since I do not have access to AS10029 network anymore and no one from my ex-colleagues would be awake at this time, I cannot see return trace easily.

I tried looking for my IP (coming via DHCP) is from orignated by BSNL AS9829. Let’s look for this IP at NIXI:


Clearly BSNL isn’t announcing this IP at all at any of NIXI’s. This is bad and becomes “worst” because BSNL doesn’t peers with any of other networks except Google. It just buys transit from Tata, Airtel etc inside India and that’s pretty much it.

Let’s look at who BSNL is announcing this route at Oregon route views:

We can see AS6453 which is Tata Comm’s International ASN and AS6762 which is AS6762 (Telecom Italia).

Some interesting facts:
  1. BSNL isn’t peering with any networks in India except Google (as far as I can see). This includes no large content networks or even large telcos. Yes, it does has local Akamai nodes but that’s pretty much it.
  2. BSNL is currently announcing very limited prefixes at all NIXI’s and my IP coming from doesn’t seem to be announced at any of NIXI’s at all.
  3. BSNL is announcing just to AS6453 Tata and AS6762 – Telecom Itlaia.
  4. Tata Communications usually does not sell any Indian capacity / Indian routing table via AS6453 and so AS6453 is used for buying transit outside India while AS4755 (VSNL) is used for domestic transit.
  5. Telecom Italia transit also is one BSNL buying outside and transporting over to India.


There’s nothing wrong in #4th and #5th but IP backbone design with a combination of all above is quite bad and leads to very degraded experience. As of now all non-Google traffic is getting routed to BSNL from outside India ! 

This includes traffic from India as well. So yes, India to India traffic is getting routed from outside India. Here are some traces to show that:

Trace from my friend’s ISP in Gujarat taking upstream from Tata:



So clearly packets are getting routed from Gujarat to Haryana via New York!


Let’s look at trace from Airtel’s PoP in New Delhi and Mumbai via their looking glass:



trace from Airtel Mumbai to BSNL Haryana

Clearly traffic coming from outside.



Some of fixes for this issue:
  1. BSNL keeps announcing routes at NIXI.
  2. BSNL keeps announcing routes to domestic transit and not just an International one.
  3. A better and open IXP model in India which removes the burden of “x-y” pricing as followed by NIXI on a inbound heavy network like that of BSNL.
  4. Likely BSNL is having capacity issues at NIXI Noida since NIXI just moved off to new location and BSNL is still working to build out transport to that. Even if that works, the trouble would be still with Western India / Southern India etc.


I have pretty much lost all hopes with BSNL that it will ever work. With hope that my new leased line circuit would be ready in upcoming days, time for me to get some sleep and get prepared for another day of high latency internet!


Disclaimer: This blog post (and blog as whole) is in my personal capacity and has nothing to do with my employer. It does not necessarily reflect views of my employer. And to be true this blog post is mine post as a frustrated customer of BSNL!

Subscribe to my blog

Enter your email address: