Hi,
I am a bit confused with the example and two different approachs demonstrated :
When distribute-list is applied on R3 , route entry not installed on R3, but it still exist in LSDB
When distribute-list applied on R2, route entry not installed on R2, but LSA still floods to R3
Which approach should be used
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
Hello,
Can we also use distribute-list R1_L0 out on R1 to filter the network 1.1.1.1 for R3 ?
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
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:
so the only place suitable would be on R3 in .
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
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
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