How to Configure a Loopback Interface on Cisco (Step by Step)
A loopback is a virtual interface that lives entirely in software. Because there is no physical port, cable, or link partner that can fail, a loopback is always up/up the moment you create it — and that reliability is exactly why network engineers rely on it. You use a loopback to give a router a stable OSPF or BGP router-id, a management or peering address that never disappears when one physical link drops, and an easy way to simulate LANs or extra networks in a lab. This guide walks through creating a loopback on Cisco IOS / IOS XE, addressing it as a /32, advertising it into OSPF, and verifying it — plus the handful of mistakes that trip people up. The syntax is identical whether you are on real hardware or practicing in Cisco Modeling Labs.
Part of the Subnetting & IP Addressing learning hub
Step 1 — Create the loopback and assign a /32 address
Drop into global configuration and create the interface. Numbering starts at 0 by convention (Loopback0), but any number works and you can have many loopbacks on one router.
Unlike a physical interface, a loopback needs no 'no shutdown' — it comes up the instant it exists, and there is no cable or line protocol that can bring it down. That is the whole point: it stays up/up regardless of what happens to the physical topology.
Address it with a /32 mask (255.255.255.255). A loopback has no neighbors and no subnet, so it only needs to represent a single host address. Using a /32 avoids wasting address space and keeps the router from believing an entire subnet lives on a virtual port. In labs where you are deliberately simulating a LAN, you might use a shorter mask instead — but for a router-id or management address, /32 is standard.
R1# configure terminal
R1(config)# interface loopback 0
R1(config-if)# ip address 1.1.1.1 255.255.255.255
R1(config-if)# end
R1#Step 2 — Verify the interface is up/up
Confirm the loopback exists and is up/up. The first 'up' is the Status column (administratively up — the interface is not shut down). The second 'up' is the Protocol column (line protocol is up). A loopback should show up/up immediately; if it does not, someone has manually shut it down.
This up/up-no-matter-what behavior is why the next steps use the loopback for the router-id and for reachability: a physical interface's protocol goes down the moment its link fails, taking any address on it with it. The loopback's address survives.
R1# show ip interface brief
Interface IP-Address OK? Method Status Protocol
GigabitEthernet0/0 10.0.12.1 YES manual up up
Loopback0 1.1.1.1 YES manual up upStep 3 — Understand how the router-id is chosen (and pin it)
OSPF and BGP each pick a 32-bit router-id, written in dotted-decimal like an IPv4 address, to uniquely identify the router in the domain. The selection order is: (1) an explicit 'router-id' configured under the routing process always wins; (2) otherwise the highest IP address on any up loopback interface; (3) otherwise the highest IP address on any up active physical interface.
Because a loopback is always up and outranks physical interfaces, addressing a loopback like 1.1.1.1 is the classic way to get a stable, predictable router-id without hard-coding it. Best practice, though, is to still set it explicitly so it never changes if you add another loopback later — the explicit command removes all ambiguity.
The same loopback is also the preferred source for BGP peering: for iBGP you typically peer to a neighbor's loopback and set 'update-source Loopback0' so the session survives the loss of any single physical path between the two routers.
R1(config)# router ospf 1
R1(config-router)# router-id 1.1.1.1
R1(config-router)# end
! BGP example — peer to a loopback and source from your own:
R1(config)# router bgp 65001
R1(config-router)# neighbor 2.2.2.2 remote-as 65001
R1(config-router)# neighbor 2.2.2.2 update-source Loopback0Step 4 — Advertise the loopback into OSPF
A router-id identifies the router, but it does not make the loopback reachable. If you want neighbors to be able to ping or manage 1.1.1.1, you must advertise it into your routing protocol. Under OSPF, the 'network' command uses a wildcard mask (inverse of a subnet mask). The wildcard 0.0.0.0 means 'match this exact address,' so it enables OSPF on precisely the loopback interface and floods that address to neighbors.
Put it in the correct area — here area 0, the backbone. The loopback will appear in neighbors' routing tables as a /32 host route (more on that in the common problems).
R1(config)# router ospf 1
R1(config-router)# network 1.1.1.1 0.0.0.0 area 0
R1(config-router)# endStep 5 — Verify the router-id and the advertised route
Confirm the process actually adopted the router-id you expect. 'show ip protocols' lists the router-id near the top of the OSPF section, and 'show ip ospf' prints it on the first line as 'Routing Process "ospf 1" with ID 1.1.1.1'.
Then move to a neighbor and confirm the loopback arrived. It will show as a /32 host route learned via OSPF (code O). Reaching it end-to-end with a ping proves both the advertisement and the router-id work as intended.
R1# show ip protocols
Routing Protocol is "ospf 1"
Router ID 1.1.1.1
R1# show ip ospf
Routing Process "ospf 1" with ID 1.1.1.1
! On a neighbor (R2):
R2# show ip route ospf
O 1.1.1.1/32 [110/2] via 10.0.12.1, 00:01:14, GigabitEthernet0/0
R2# ping 1.1.1.1Common problems (and the fix)
1) The loopback is created but peers can't reach it. Creating the interface does not advertise it. If neighbors have no route to 1.1.1.1, you almost always forgot the 'network 1.1.1.1 0.0.0.0 area X' statement under OSPF (or the equivalent redistribution/network statement in your protocol). Advertise it, then re-check the neighbor's routing table.
2) You gave the loopback a /24 but it advertises as a /32. This is expected, not a bug. By default OSPF treats a loopback as a stub host and advertises it as a /32 host route no matter what mask you configured. If you are simulating a LAN and genuinely need the full subnet advertised with its real mask, change the OSPF network type on the loopback to point-to-point.
3) You changed the loopback (or added one) but the router-id didn't update. The router-id is selected once, when the OSPF process starts, and is not re-evaluated live. After changing a router-id or the loopback that feeds it, you must clear the process (which briefly tears down adjacencies) or reload for the new value to take effect. Confirm the prompt with 'yes'.
4) The interface shows administratively down. A loopback is up by default, so a down state means it was explicitly shut. Re-enable it with 'no shutdown' under the interface.
5) Duplicate router-ids across routers. If two routers end up with the same router-id (e.g., both loopbacks addressed 1.1.1.1), OSPF adjacencies and BGP sessions misbehave. Give each router a unique loopback address and, ideally, pin it explicitly with 'router-id'.
! Fix 2 — advertise the loopback's real subnet instead of a /32:
R1(config)# interface loopback 0
R1(config-if)# ip ospf network point-to-point
! Fix 3 — force the router-id to be re-read (tears down adjacencies briefly):
R1# clear ip ospf process
Reset ALL OSPF processes? [no]: yes
! Fix 4 — bring an accidentally shut loopback back up:
R1(config)# interface loopback 0
R1(config-if)# no shutdownFrequently asked questions
Should I use a /32 or a /24 on a loopback interface?
Use a /32 for router-ids, management, and peering addresses because it consumes a single host address and advertises as one exact route, which is the cleanest and most common practice. Use a shorter mask like /24 only when you deliberately want the loopback to simulate a whole LAN subnet in a lab. Note that OSPF advertises any loopback as a /32 host route by default regardless of the configured mask unless you change the interface's OSPF network type to point-to-point.
Why did my OSPF router-id not change after I configured a loopback?
OSPF only selects the router-id once, at process startup, so adding or changing a loopback afterward does not retroactively update it. You must either reload the router or run 'clear ip ospf process' to force the process to re-elect the router-id. To avoid this entirely, pin it explicitly with the 'router-id' command under the OSPF process rather than relying on the highest loopback IP.
What order does OSPF use to choose its router-id?
OSPF first uses a manually configured 'router-id' if present, which always wins. If none is set, it picks the highest IP address among up loopback interfaces, and if there are no loopbacks it falls back to the highest IP on any up physical interface. Because manual configuration and loopbacks are preferred, engineers use a loopback or an explicit router-id to keep the value stable and predictable.
Can a loopback interface ever go down?
A loopback stays up/up as long as it exists because there is no physical link to fail, but it can be taken down administratively with 'shutdown', which sets it to administratively down. It also disappears from the routing table if you remove the interface or its IP address. If a routing protocol is not advertising the loopback, remote devices still cannot reach it even though it is locally up.
How do I make other routers actually reach my loopback address?
Being up/up only makes the loopback reachable locally, so you must advertise its subnet through a routing protocol or a static route for remote devices to reach it. In OSPF this means the loopback's network must be covered by a 'network' statement under the process, or the interface must have 'ip ospf' enabled directly. Verify from a remote router with 'show ip route' for the /32 and a ping sourced appropriately, not just from the local box.
Practice this on graded Cisco labs
Reading is step one — build Subnetting & IP Addressing on real Cisco IOS and grade your own config, or try a free sample lab first.