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:

R1 OSPF configuration
R2 OSPF configuration

If we examine the routing table of R1, we can see that the network (LAN2) has been learned via OSPF:

R1’s OSPF routes

Likewise, R2 has learned the network (LAN1) from R1 via OSPF:

R2’s OSPF routes

Now imagine we want to prevent the network 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 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:

Inbound distribute-list configuration on R2

R2 has been configured with a standard access-list that deny the network 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:

R2’s routing table after applying the distribute list

We can see that network 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:

R1’s router-LSA

As we can see, network 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 It will automatically create an entry in the R2’s routing table with a connected route to the host address of

Loopback interface configuration on R2
Connected route to loopback 0

Let’s now redistribute this new connected route into OSPF:

Redistribution of connected subnets into OSPF

We can verify that this new connected route has been redistributed into OSPF through an external type-5 LSA:

Content of the R2’s LSDB after connected subnet redistribution

We can also verify that R1 has learned this external OSPF route:

R1’s OSPF routes after route redistribution in R2

Let’s now create another loopback interface on R2 and see the effect on R1’s routing table:

Configuration of a second loopback interface on R2
R1 OSPF routes after the creation of the second loopback interface on R2

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:

R2’s LSDB after creating a second loopback interface

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:

Outbound distribute list configuration on R2

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:

R1 OSPF routes after applying the outbound distribute list

The external route to network 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:

R2’s LSDB after applying the outbound distribute-list

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.