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
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
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
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
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
Hello, everyone.
Do distribute lists applied on an ABR prevent Type 1 LSAs from becoming Type 3 LSAs in a different area?
My book says that they donât but my lab produces a different output.
A distribute list on an ABR does not prevent Type 1 LSAs from becoming Type 3 LSAs in a different area because the Type 3 LSA generation occurs before the distribute list is processed.
In this topology, R1-XR has two networks - 1.1.1.1/32 and 1.1.1.2/32. If I configure this on R4:
It wonât propagate this prefix to area 1 or area 2
Once I remove the distribute list command, the route is back
So whatâs the truth here? What the book says or what my lab produces? 
Thank you!
David
Hello David
Wow, as always, your scenarios are very specific, and itâs always interesting to see how OSPF behaves in these particular setups. Well, here goesâŠ
What the book says is true, but it is stated too broadly, I think. Although it is true, it does not take into account your specific scenario. I believe the book should be reworded like so:
An OSPF distribute-list does not remove or block Type 1 LSAs from the LSDB. However, on a Cisco ABR, an inbound OSPF distribute-list can prevent the route from entering the ABRâs routing table, and because Type 3 LSAs are generated based on the ABRâs usable routing information, the ABR may then stop advertising that prefix as a Type 3 LSA into other areas.
So both the text and your scenario are related, but they are talking about different points in the process.
In your topology, R4 receives 1.1.1.1/32 from Area 0 as intra-area OSPF information. When you apply:
ip prefix-list CISCO2 seq 5 deny 1.1.1.1/32
ip prefix-list CISCO2 seq 10 permit 0.0.0.0/0 le 32
router ospf ...
distribute-list prefix CISCO2 in G1
you are not preventing R4 from having the Type 1 LSA in its Area 0 LSDB. Thatâs what the book is saying. Area 0 still has to maintain a consistent LSDB. But you are preventing R4 from installing that route into its own routing table. Since R4 no longer has 1.1.1.1/32 as a usable OSPF route, it does not generate the corresponding Type 3 summary LSA into Area 1 and Area 2.
That is why R2 and R3 lose 1.1.1.1/32, while 1.1.1.2/32 remains. Your output confirms exactly that.
So the book is correct in the sense that a distribute-list does not directly filter Type 1 LSAs from the LSDB. However, your lab is also correct: on Cisco IOS, an inbound OSPF distribute-list on an ABR can indirectly prevent Type 3 LSA generation because it prevents the ABR from installing the route in the routing table. Thatâs what the book is not addressing. Since the ABR has no usable route for that prefix, it does not advertise it into the other areas as a Type 3 LSA.
As a general rule, for such scenarios, it is preferable to use the filter-list feature rather than distribute-lists. This feature filters Type 3 LSA generation between areas, whereas distribute-lists control what enters the local routing table. Although you can do similar things with both, the filter-lists are cleaner solutions.
I hope this has been helpful!
Laz
Hello Laz.
Thank you, I appreciate it!
David