Injecting routes with loopbacks
By stretch | Wednesday, September 17, 2008 at 4:56 a.m. UTC
This concept will not be new to anyone who has taken a CCIE practice lab, but I feel it's worthwhile to talk about since I hadn't encountered it in practice prior to my CCIE studies. In configuring labs (real or virtual), we typically seek to replicate only part of a much larger scenario; for example, we might build a lab mimicking only one distribution segment of a campus network of many similar segments. However, it may be a good idea to still inject the same routes that would be found in the real network to ensure the configurations being evaluated will work as expected if put into production.
Of course, no one wants to add a bunch of routers to a lab solely for the purpose of creating additional subnets. So how could we create, say, a thousand routes in lab with a finite number of router interfaces? Loopbacks! We can create an arbitrary number of virtual interfaces on a router, each pointing to an arbitrary subnet. No physical connectivity is required to emulate a large number of independent routes on a single device. Cisco IOS supports a large number of loopback interfaces; whether you would want to configure as many is another matter.
Router(config)# interface loopback ? Loopback interface number
Consider a lab with two OSPF neighbors, R1 and R2. You want to inject a number of dummy routes to experiment with route filtering; these routes don't actually carry traffic, they're just there to play with. We can create a bunch of loopback interfaces pointing to these dummy subnets on R1:
interface Loopback0 ip address 220.127.116.11 255.255.255.255 ! interface Loopback1 ip address 192.168.1.1 255.255.255.0 ! interface Loopback2 ip address 192.168.2.1 255.255.255.0 ! interface Loopback3 ip address 192.168.3.1 255.255.255.0 ! interface Loopback4 ip address 192.168.4.1 255.255.255.0 ! interface Loopback11 ip address 172.16.0.1 255.255.252.0 ! interface Loopback12 ip address 172.16.4.1 255.255.252.0
In a more complex lab, it would be beneficial to script the automatic configuration of loopback interfaces for a large number of routes, but that is beyond the scope of this article. The routes can be added to the OSPF domain a number of ways, but here simple redistribution is used. Route maps could be employed to emulate various metrics and next-hop addresses.
R1(config)# router ospf 1 R1(config-router)# redistribute connected subnets
Now R2 sees all these routes as if they were legitimate end subnets:
R2# show ip route ospf 18.104.22.168/32 is subnetted, 1 subnets O E2 22.214.171.124 [110/20] via 10.0.0.1, 00:04:32, FastEthernet0/0 172.16.0.0/22 is subnetted, 2 subnets O E2 172.16.4.0 [110/20] via 10.0.0.1, 00:04:32, FastEthernet0/0 O E2 172.16.0.0 [110/20] via 10.0.0.1, 00:04:32, FastEthernet0/0 O E2 192.168.4.0/24 [110/20] via 10.0.0.1, 00:04:38, FastEthernet0/0 O E2 192.168.1.0/24 [110/20] via 10.0.0.1, 00:04:38, FastEthernet0/0 O E2 192.168.2.0/24 [110/20] via 10.0.0.1, 00:04:38, FastEthernet0/0 O E2 192.168.3.0/24 [110/20] via 10.0.0.1, 00:04:38, FastEthernet0/0
This concept can be applied to any routing protocol to generate more routes than really exist in a network. On a large scale this method could be used to test convergence times and route capacity, but I find it helpful simply to experiment with filtering and summarization configurations.
About the Author
Jeremy Stretch is a network engineer living in the Raleigh-Durham, North Carolina area. He is known for his blog and cheat sheets here at Packet Life. You can reach him by email or follow him on Twitter.
Posted in Tips and Tricks
September 17, 2008 at 4:16 p.m. UTC
How about doing the same with Static Routes pointing to Null and redistributing Static in the OSPF process... It seems a little easier than coding all these loopback interfaces...
Either way, Its a great trick to remember..
September 18, 2008 at 11:41 a.m. UTC
I guess Loopbacks are more useful because they can be pinged to prove connectivity - static routes to Null0 cannot.
September 18, 2008 at 2:11 p.m. UTC
I think that sometimes we need to implement some networks as LSA 1 networks - when we are configure with redistribution it doesn't work. When we configure networks using network x.x.x.x x.x.x.x area x command the networks will be propagated with /32 mask. To propagate networks with other masks add command ip ospf network point-to-point - after that network will be propagated with mask configured on interface