OSPF Distribute-List Filtering

Lessons Discussion
41

Hi,

I am a bit confused with the example and two different approachs demonstrated :

  1. When distribute-list is applied on R3 , route entry not installed on R3, but it still exist in LSDB

  2. When distribute-list applied on R2, route entry not installed on R2, but LSA still floods to R3

Which approach should be used

42

Hello Kenny

In the first scenario, you are preventing the information in the LSDB to be installed in the routing table on R3. Specifically, you are preventing R3 from installing the route to 1.1.1.1 into its routing table. This is the preferred method. The result is that if a packet arrives at R3 with a destination of 1.1.1.1, the packet will be dropped. The route is still in the LSDB, and if there are other routers in the topology, they will be able to normally install this destination in the routing table.

In the second case, R2 removes the route, however, R2 is an intermediary device that, based on the LDSB that it shares with R3, is a next-hop IP for the 1.1.1.1 network. This is a problem because R3 will send packets destined for 1.1.1.1 to R2. But if R2 does not have this destination in its routing table, due to the distribution-list filter, traffic reaching R2 will be dropped. Such a scenario should be avoided.

This is why distribute list filtering for OSPF must be applied with caution.

I hope this has been helpful!

Laz

43

Hello,
Can we also use distribute-list R1_L0 out on R1 to filter the network 1.1.1.1 for R3 ?

44

Hello Abdul

Yes, you could do that. Just keep in mind that even though the result for R3 is the same, the result for R2 is different. In the case of the lesson, R2 learns about the 1.1.1.1/32 network. If you implement it as you suggest, then R2 will not learn about 1.1.1.1/32. Where you apply the distribute-list and in which direction will influence which routers know about that particular network.

I hope this has been helpful!

Laz

45

Hello,

That is what I also thought should happen. I labbed it up and found that if I want to block the 1.1.1.1/32 network for R3, it will only work
if I apply the distribute list in on R3. Please correct my understanding if wrong:

  1. Distribute list in for 1.1.1.1/32 on R1 will not work because it is a connected network. It will show up in the routing table as C . (nothing to do with OSPF)
  2. Distribute list out for 1.1.1.1/32 on R1 will not work because R1-R2-R3 are in the same area and OSPF-LSDB should be same on all three devices.
  3. Distribute list in/out on R2 would create a black hole.

so the only place suitable would be on R3 in .

46

Hello Abdul

Yes, you are correct, my apologies. Because by definition, the OSPF LSDB must be the same for all routers in the area, you cannot filter routes that are shared between OSPF routers. You can only filter routes from entering the routing table. And that is something that you can only do at the local router itself.

Therefore, to correctly answer your question in your original post, no you cannot filter route 1.1.1.1/32 from entering the routing table of R3 by using a distribute list on R1. You can only filter routes from entering the local routing table by configuring a distribute-list on the local router.

I hope this has been helpful!

Laz

47

Hello Rene,

If we want to do opposite , like allow certain subnet and block rest of the other subnets to install at routing table within same area how we will be able to do that

48

Hello Md

In order to do what you suggest, the change that needs to be made must be applied to the Access List. It is the access list that is doing the matching.

So letā€™s say you want to allow only the 1.1.1.1 host and to deny everything else. The access list configuration would look like this:

R3(config)#ip access-list standard R1_L0
R3(config-std-nacl)#permit host 1.1.1.1    
R3(config-std-nacl)#deny any

This access list permits the 1.1.1.1 host address but denies everything else. I have put in an explicit deny statement, but all ACLs have a deny statement at the end anyway, so itā€™s not really needed, the behavior is the same. I just added that for clarity.

Once you create this ACL, you can then apply it with the distribute list in the same way:

R3(config-router)#distribute-list R1_L0 in

The result is that R3 will install the 1.1.1.1 host address in the routing table, but will deny all other entries. Does that make sense?

I hope this has been helpful!

Laz

49

Hi Rene ,

Please I would like to know what is a real difference between the command network 1.1.1.1 0.0.0.255 and redistribute connected although it is true that the metrics are not the same and what is the impact

50

Hello David

The main difference between the network 1.1.1.1 0.0.0.255 command and the redistribute connected command lies in the way they function.

The network command is used to specify which interfaces the routing protocol should run on. In your example, network 1.1.1.1 0.0.0.255 tells your router to enable the routing protocol on all interfaces that fall within the 1.1.1.1 - 1.1.1.255 IP address range. This results in two things:

  1. It allows the router to advertise all of the networks of all interfaces that fall within the address range
  2. It causes those same interfaces to participate in OSPF. That means that those interfaces actively attempt to create OSPF adjacencies by sending out OSPF hello packets.

On the other hand, the redistribute connected command is used to include the routes of directly connected networks into the routing protocol. This means that all interfaces, regardless of their IP address, will have their directly connected networks included in the routing updates. However, those interfaces wonā€™t actively participate in OSPF (i.e. no hello packets etc). Only their networks will be advertised.

In terms of impact, using the network command allows for more granular control over which networks are included in the routing protocol. This can be useful in situations where you only want to advertise certain networks. The redistribute connected command is more of a blanket approach, including all directly connected networks.

The metrics are indeed different because they are used by the routing protocol to determine the best path to a destination. The redistribute connected command might assign a default metric to the routes it redistributes, which may not always be optimal. Therefore, itā€™s important to understand the network topology and the routing protocol behavior before deciding which command to use.

More information can be found at this NetworkLessons note on the topic.

I hope this has been helpful!

Laz

51

Hello ,

Thanks for the explanation

1 Like
52

Hi,

It seems that I can also filter based next hop with an extended ACL e.g. The following would prevent any prefix (you can be more specific) with a next hop of 155.1.1.1 from entering the routing tables:

ip access-list extended 100
deny ip host 155.1.1.1 host any
permit ip any any

router ospf 1
distribute-list 100 in

Iā€™m finding it difficult to locate Cisco documentation supporting this feature. It also works for EIGRP. Any opinions on this?

Sam

53

Hello Samir

Actually, your configuration will filter based on the advertising routerā€™s IP address, not the next-hop attribute. In OSPF and EIGRP, distribute-lists that reference extended ACLs match the following:

  • Source: IP of the router advertising the route (e.g., host 155.1.1.1).
  • Destination: Route prefix (e.g., host any matches any prefix).

So your config will block routes advertised by 155.1.1.1, not routes with a next-hop of 155.1.1.1.

(Be aware that this behavior changes depending upon the routing protocol being used. A distribute-list with an extended ACL works very differently for BGP. Take a look at this: https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13750-22.html#toc-hId--380920076)

If you want to filter based on next-hop, use route-maps with match ip next-hop, not distribute-lists with ACLs. For example:

route-map FILTER_NH permit 10  
match ip next-hop 155.1.1.1

Apply this route-map in the routing process like so: distribute-list route-map FILTER_NH in. This will work in both EIGRP and OSPF.

Indeed it is difficult. I havenā€™t been able to find documentation concerning the use of distribution lists with extended ACLs in IGPs like EIGRP and OSPF. I think your best bet is to test these out with each routing protocol and see how it works!

I hope this has been helpful!

Laz

1 Like
54

Hi Laz,

Thanks, I didnā€™t realise that, so itā€™s not actually the next hop IP for the route but the source IP of where it learnt it from (although both values could be the same).

For OSPF, is the source the RID of the router that originated the LSA? Or the IP address of the peer router that sent the LSA? Iā€™ll lab this up, but originator makes more sense.

Yeah, Iā€™m aware the extended ACL in a BGP distribute list acts like a prefix-list i.e. the acl represents network and mask. Itā€™s all very confusing.

Thanks again.

Sam

55

Hello Guys I have one question about this Paragraph
ā€œHowever OSPF routers only know what the topology looks like within the area. They donā€™t know what the topology looks like for other areas. For inter-area routes OSPF only knows the prefix and the ABR (Area Border Router) to reach it.ā€

I remember that un some point Rene told that OSPF is like a GPS and it knows all the network.

So Iā€™m a bit confuse now

58

Hello Samir

The best way to confirm (or dispute) this is to lab it up as you suggest. The specific scenario is quite specialized, since youā€™re using OSPF, with a distribute list acting directly on the OSPF process, using an extended access list. The router will interpret the source and destination IPs in very specific and very unintuitive ways, so itā€™s best to lab it up and let us know your results.

As mentioned before, this arrangement changes based on the routing protocol being used as well, so itā€™s difficult to get your head around.

Because of its unintuitive nature, the use of ACLs in distribute lists not recommended. A preferrable method is to use prefix lists.

I hope this has been helpful!

Laz

1 Like
59

Hello Daniel

OSPF is a link state routing protocol, and by definition, link state routing protocols build a map of ā€œthe whole networkā€ whatever that means. (Iā€™ll clarify that shortly). This map exists in each OSPF router as the Link State Database or LSDB. Once converged, each OSPF router participating in the same OSPF instance should have exactly the same map in its memory.

This allows for very efficient routing protocol operation, but not very efficient resource usage. More CPU and memory are used to process and store this LSDB than a distance vector routing protocol like EIGRP.

This high resource usage limits OSPF when the topology gets big. So the solution is to break it down into areas. Now when you do this, each OSPF router builds a map in its LSDB only for the local area. Through this map it has information about how to get to specific networks in other areas (via the ABR), but it doesnā€™t have any detailed information about the topology in other areas.

So although Rene did mention that OSPF has a full map of the topology like a GPS, this map is indeed limited to the area in which the router exists. Does that make sense?

I hope this has been helpful!

Laz