In this blog post, I will talk about the effect of the distribute-list command on the operation of the OSPF routing protocol. This command can be applied in the inbound direction and in the outbound direction. When applied in the inbound direction, it filters routes to be installed in the routing table and, when applied outbound, it filters which routes are redistributed from other routing protocols or other routing sources, such as static or connected routes.
We will be using the following single-area OSPF topology consisting of two routers:
The LAN segments LAN1 and LAN2 are assumed to be stub networks, so the router interfaces attached to these LANs are configured as passive interfaces:
If we examine the routing table of R1, we can see that the 10.0.2.0/24 network (LAN2) has been learned via OSPF:
Likewise, R2 has learned the network 10.0.1.0/24 (LAN1) from R1 via OSPF:
Now imagine we want to prevent the network 10.0.1.0/24 from installing on R2’s routing table. If R2 removes this network from the Link State Database (LSDB) or if R1 stops announcing the network in its router-LSAs, the correct operation of the OSPF protocol would be altered (remember that one of the principles of a Link-state Routing Protocol is that all the routers must share the same vision of the network topology). But R2 can learn the network 10.0.1.0/24 from R1’s router-LSA, and decide later if it wants to install this network in its routing table or not. This is the purpose of the distribute-list command when applied in the inbound direction. Let’s see the effect on R2:
R2 has been configured with a standard access-list that deny the network 10.0.1.0/24 and has been referenced in the inbound distribute-list command. Let’s see the content of R2’s routing table after applying the distribute-list command:
We can see that network 10.0.1.0/24 is missing because it has been blocked by the distribute list. Let’s now examine the content of the router-LSA generated by R1 in R2’s LSDB:
As we can see, network 10.0.1.0/24 is still present in the LSDB. The distribute list applied has only prevented this network from entering R2’s routing table.
Let’s now examine another scenario. Imagine that R2 is redistributing into OSPF routes from other routing protocols (like EIGRP or RIP) or from other routing sources (like connected routes or static routes). For example, let’s create a loopback interface on R2 and assign it the IP address of 172.16.0.2/32. It will automatically create an entry in the R2’s routing table with a connected route to the host address of 172.16.0.2/32:
Let’s now redistribute this new connected route into OSPF:
We can verify that this new connected route has been redistributed into OSPF through an external type-5 LSA:
We can also verify that R1 has learned this external OSPF route:
Let’s now create another loopback interface on R2 and see the effect on R1’s routing table:
As we can see, R1 has learned a second external route to the new loopback interface IP address because R2 is redistributing all connected subnets into OSPF. In fact, if we examine the content of R2’s LSDB, we can verify that R2 is now generating two external type-5 LSAs:
If we want to prevent this new route from installing into R1’s routing table, we can use the distribute-list command in the outbound direction on R2. Let’s see how it works:
In order to configure this new distribute list, a second standard access list has been defined. This access list permits only the IP address of the first loopback interface (Loopback0) and denies any other IP addresses. This access list is referenced in the outbound distribute-list command. Let’s now examen in the content of R1’s routing table:
The external route to network 10.2.2.2/32 is gone, since has been filtered by the outbound distribute list on R2. Let’s now examine the new content of the R2’s LSDB:
We can verify that R2 has stopped generating the external LSA associated with the new loopback interface. The outbound distribute list filters which routes are inyected into the OSPF domain by the Autonomous System Border Router (ASBR), which is R2, in this case. Unlike the inbound operation of distribute lists, when applied oubound, the distribute lists modify how LSAs are flooded into the OSPF area.