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
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
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:
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
Hello ,
Thanks for the explanation
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 anyrouter 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
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:
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