Anyone starting out in their networking career will come across the loopback interface pretty quickly. So what are they and why do we use them so much? Well, the loopback interface is a logical interface (compared to a physical interface like a Fast Ethernet of Serial interface) and unlike a physical interface carries no electrical status so it is always UP but can be administratively shutdown. The state of a loopback when you create it is UP by default which is the exact opposite of a physical interface.
This screenshot shows us creating a new interface 'loopback0'. Notice that the interface goes into an 'up' state by default.
Lets have a look into it.Reason #1: Don't talk to strangers
Imagine a dynamic routing protocol is enabled on your LAN, it doesn't matter which one for the sake of the argument. If you have enabled the routing protocol then updates are being sent all the time to all nodes on that local network. Now what happens when an interface goes down? Of course the IGP will (hopefully) perform it's duty and work out another route around the failed interface but crucially the interface which is now down cannot be reached...what if you *always* connected to that interface and thats the one in your access-lists etc? What if that interface is the one which you are polling from your network monitoring? You've got an access problem and those RED lights on the NMS are not going away any time soon.
The loopback interface provides you with that fixed point of contact. Because the loopback *never* goes down (unless you tell it to using the administrative 'shutdown' command) using it (and adding the IP into your IGP) means you would always be able to telnet, SSH, SNMP and generally use the loopback for any communications you want. Of course if all of the physical interfaces on the router go down you've got no way of accessing it ;-)Reason #2: It's nice to know who your friends are.
IGP's get along with each other just fine but one of the first things they say to each other is 'Hello, my name is...'. So imagine if someone you know introduces themselves as Bob only to introduce themselves to you next time as Phil? Its confusing right...and a makes you wonder about their sanity! Well the router also introduces itself using something called the Router ID and if that changes, you can have issues.
Each IGP has a different way of working the RID (router-id) out. Some choose the locally connected IP address on that segment, others choose the lowest or highest IP address on the router, others may have a hardcoded one. Now we've already seen that then interfaces go down bad things can happen with IGP's and the RID is another bad thing.
Lets take OSPF for example. When you start the OSPF process it runs off and looks at the local router and it's associated IP addresses. Here is twitch No.1, it only looks at interfaces which are ACTIVE...inactive interfaces (shutdown ones) do NOT get chosen. So OSPF will look around for the highest IP address of any loopback interface first. Why? Well because OSPF knows how important it is to have the 'always up' interface as it's router ID - the guys designing OSPF were smart ;-) If there is no loopback interface then OSPF will choose the highest interface IP address, if there are no IP addresses then guess what....OSPF will NOT come up. Right so we choose our highest IP address for the router-ID and we are pretty happy with ourselves. Maybe now we setup another router and do what we need to do to get them talking to each other. The neighbor router will see the remote router's router-ID and use that in it's topology table. So when you come along as an admin and look at the output on that router you'll see all those routes learned from that router-ID. Right, now lets imagine that router-ID interface goes down and you as an admin are troubleshooting it. It just becomes a bit of a pain to locate that source router for those routes when you cannot directly connect to that source. Wouldn't it be awesome if instead of using that interface IP address for the RID that instead you used the loopback IP? that way the RID should always be available.
Here'a a walk through creating a router-id for OSPF. We've got two routers connected to each other using a common network 192.168.12.0/24. The router-id command is done under the OSPF process and asks us to put in an IP address. It could be any IP address, it doesn't even have to be one on the router, In our case we're going to use 192.168.255.1 which is the IP address we put under the Loopback0 interface.
After we configured an OSPF neighbor 192.168.255.2 with IP address 192.168.12.2 the neighbor relationship comes up. This is the debug of the OSPF process as it is established. We can clearly see the router ID (rid) of the neighbor R1 using the loopback0 IP address of 192.168.255.1
Here is the neighbor detail - again your can see the Neighbor ID which is the router ID and you can also see the IP address which it was learned from on the local subnet.
If we change the IP address of loopback 0 - the RID does NOT change, it is not TIED to the loopback interface, it just help tie everything together to the administrator. This is a blessing and a curse, I'll leave it with you to decide which.Reason #3: Don't let me down IGP, I'm depending on you.
When we are setting up an iBGP session the neighbor we are trying to connect to may not be directly connected across a local link. This is unlike an eBGP neighbor which is likely only one hop away. The iBGP neighbors depend on an IGP (like OSPF/EIGRP) to permit the neighbor relationship to form. Now we can, if we choose, use the interface IP address to create the neighbor relationship but what happens if that interface goes down...you got it...we lose the iBGP neighbor relationship.
Now the whole idea of using an IGP is that usually your router is part of a bigger picture and you are using the IGP to try to create some resilience to points of failure. iBGP depends on the IGP to provide the resilience to single interface failure but crucially by using a physical interface for the iBGP neighbor source/destination we are introducing a single point of failure. i.e. if the interface goes down, the relationship fails.
So, instead of using the physical interface as the neighbor source and destination we're going to use the logical loopback interface. This way the neighbors can depend on the IGP to work around any interface issues.
We'll go through a little BGP configuration using loopback's and router-ID's.
On R2 we'll configure the router-ID to use the IP address for the loopback 0 interface
Now lets configure an iBGP relationship between R1 and R2 using the loopback interface and depending on the underlying OSPF IGP for the routing.
Of course there is one final step because we are using the loopback interfaces as the source of the BGP traffic.
...wait a little while and...Reason #4: Administrative control, keep it safe.
Have you heard engineers talking about 'nailing' things up? What they mean by that is having a secure, safe and fixed point of reference. The last thing you need when all around you is going to the wall is a flapping interface. The loopback interface is solid and secure. The only way that interface is going down is is YOU tell it to. So using loopback interfaces as the source for telnet, SNMP traps, Syslog updates and management is THE best thing you can do as an administrator.
Build your entire messaging, management and access-control security around the loopback interface and you'll be OK.
Imagine as an example the best tool for the network admin, Telnet. Have you ever needed to hop from one IOS device to another because it has suffered from a catastrophic routing failure and it can only be accessed using the local link? Well take that example and lets run with it a little way. So you can access RouterA (192.168.12.1) from your network admin console, thats great, but now you need to get to RouterB (192.168.12.2). The access control list permits your administration console using Telnet but crucially you also permitted access using your networks loopback addresses.
You've standardised your IOS network devices to use addresses in the 192.168.255.0/24 subnet in their loopback interfaces for network administration functions. So because of that you can now telnet from 192.168.255.2 to 192.168.12.1 and be authorised because RouterB recognises that 192.168.255.0/24 network as a trusted source for VTY access.
Here is the access-list permitting your loopback interfaces
We've applied the access-list to the telnet VTY ports.
Telnetting from the local interface on R1 (192.168.12.1) to the interface on R2 (192.168.12.2) doesn't work...you're denied access.
We need to change the telnet natural source interface of Fa0/0 to that of the loopback interface to make this work but it's a good backdoor.
Some other loopback requirements are:
Exception dumps: during router failures the contents of RAM are dumped out to am FTP server. Server accesses may be sourced from the loopback interface using the 'ip ftp source-interface Loopback0' command
TFTP: Again, this is a security option for your TFTP service. By restricting TFTP server access using your loopback interface IP addresses. 'ip tftp source-interface Loopback0'/
NTP, Syslog, NetFlow, TACACS and SNMP are just some of the other service access functions which can be restricted to using the loopback interface as a source.Reason #5: When we wish to reduce our IP footprint.
Often a point to point link would use a /30 (CIDR) network to allow to two useable addresses to connect across that link. This helps to reduce the wastage a larger network (e.g. /24) might require. So one way to reduce the IP address wastage is to use the 'IP unnumbered' feature. An unnumbered link requires no IP address to be applied. The thing is that we have a point-to-point link so there is only ever going to be point A and point B, there is no other host in there. That being the case we can drop traffic onto the wire safe in the understanding that the traffic will only ever be delivered to the opposite end of the link.
IP unnumbered interfaces use the loopback interface for connectivity. This command can only be used on non multi-access links.
There are a lot of other great reasons why loopback interfaces are good but these are a good start. If you can secure your network and make it 'feel' more stable using loopback interfaces then you should do it. What about tunnels, VPN's...oh yes...all good stuff.
Good Luck with your studies.