Injecting routes with loopbacks

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 1.1.1.1 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
1.0.0.0/32 is subnetted, 1 subnets
  O E2    1.1.1.1 [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.