This topic is to discuss the following lesson:
Good Day Rene,
I was practice labs and i come across below redistribute and i failed to understood the metric 1544 2000 255 1 1500
R2(config)#router ospf 1
R2(config-router)#redistribute eigrp 100 metric-type 1 subnets
R2(config)#router eigrp 100
R2(config-router)#redistribute ospf 1 metric 1544 2000 255 1 1500
Kindly assist to elaborate on this.
Hi Dani,
Each routing protocol uses different metrics which are incompatible. When you redistribute something into EIGRP, you need to enter the K values manually.
Rene
Hi Rene,
Really enjoying the OSPF lessons! Just one query, the first output is what you had in the lesson and am just wondering why you chose the network statement for the loopback 0 as 1.1.1.0 0.0.0.255 area 0, instead of 1.1.1.1 0.0.0.0 area 0, as in the second output?
R1#show running-config | section ospf
router ospf 1
<strong>network 1.1.1.0 0.0.0.255 area 0</strong>
network 192.168.12.0 0.0.0.255 area 0
R1#show running-config | section ospf
router ospf 1
network 1.1.1.1 0.0.0.0 area 0
network 192.168.12.0 0.0.0.255 area 0
network 192.168.12.0 0.0.0.255 area 0
Regards,
Shannon
Hi Shannon,
It doesn’t matter much which of the two you pick, both will work. The network command basically checks the IP addresses that you have on your interfaces and if it falls within the range of your network command, it will activate OSPF on it.
If you use 1.1.1.0 0.0.0.255 as the network command then any interfaces that have IP address 1.1.1.X on it will run OSPF. If I have a loopback with IP address 1.1.1.1/32 then this will do the job. The problem is that a loopback with 1.1.1.2/32 will also be automatically advertised in OSPF since it matches the network command.
Because of this, it’s best to be as precise as possible with network commands to avoid running OSPF on interfaces that you don’t want. The network 1.1.1.1 0.0.0.0 command is a good choice.
If I’m doing labs where I don’t care about routing then I sometimes use network command 0.0.0.0 255.255.255.255. It’s the “shotgun approach” that enables OSPF on any interface.
Hope this helps!
Rene
Thanks Rene! Got it.
why does the LSA still flood to R3???
Within an area, the LSDB has to be same on all OSPF routers. We can’t filter LSAs within an area, the only thing we can do is to prevent a route from being installed in the routing table. That’s what we are doing here with the distribute-list.
Hello Rene,
One quick question. I am trying to use distribute-list in OSPF in outbound direction, but the command is being rejected and the below error message is showing up. Would you please describe why? Thank you so much.
R1(config-router)#distribute-list prefix cisco out gigabitEthernet 1/0
**% Interface not allowed with OUT in case of OSPF**
Best Regards,
Azm
1 Like
Hi Azm,
The LSDB has to be the same in the area so you can’t filter LSAs like that. The only thing you can do is an inbound filter that prevents a LSA from being installed in your routing table, that’s it.
Rene
2 Likes
Hello Rene,
Thanks for your reply. However, I still have a confusion. How does distribute-list work? does it filter LSAs or it resists routes from being installed in the routing table? Let’s say we are looking at topology like below and they are running OSPF:
Router A------------Router B-(inbound distribute-list)---------------Router C
Let’s say, Router C has a loopback 1.1.1.1 and it is advertised in OSPF. So if I apply an inbound distribute-list to block 1.1.1.1 on Router B, it does not install 1.1.1.1 route in its routing table. However, it passes the 1.1.1.1 route out to Router A. That means it is not filtering LSAs. It’s just not installing that route in its own routing table. So when a distribute-list is applied on Router C to the outbound direction, why would it filter LSAs? Please shed some light on it. Thank you so much in advance.
Best Regards,
Az
1 Like
Hello Azm
Yes, you are correct. The filtering that takes place is filtering of routes from entering the routing table. The filtering does not occur at the interface, but at the mechanism of adding routes to the routing table. Rene mentions the following in the lesson:
Since the LSDB within the area has to be the same we can’t filter LSAs within the area, we can however filter routes from entering the routing table. Filtering LSAs between areas on an ABR or ASBR is no problem.
So it is a matter of the definition of the word filter. Filtering in this case does not occur at the interface, but at the entering of routes in the routing table.
Filtering at the interface however, can occur between OSPF areas.
I hope this has been helpful!
Laz
3 Likes
Hi Rene,
Really enjoying the OSPF lesson, but i have a query…How R3 is receiving the 1.1.1.1 route in its routing table , after configuration of distribute list on R2.
Regards
Rahul
Hello Rahul
When you apply a distribute list filtering on specific routers using the distribute-list command with access lists, the application of that distribute list ONLY affects the router on which you are configuring it. So the distribute list on R2 affects on R2. It’s not like an access list that is added on R2 that will also block any updating of the 1.1.1.1 network on R3 as well. Notice that the distribute list is added to the router configuration and is not applied to any interface so no traditional access list functionality is occurring here.
Now in the lesson, Rene removed the distribute list from R3 so the 1.1.1.1 network returned into the routing table.
I hope this has been helpful!
Laz
Hi,
How can we do the same using ROUTE MAP
Thanks
Hello Sims
You can combine the use of a distribute-list with a route-map. Although there is no lesson here that shows how to do this in OSPF, you can see this achieved using EIGRP at the following lesson. The logic is very much the same.
If you want to find out more about filtering in OSPF using various methods including route-maps, take a look at the following Cisco documentation.
I hope this has been helpful!
Laz
Hi,
What does Ospf accept distribute-list with using IN INTERFACE but not accepting OUT INTERFACE? What is the difference between them? Does IN INTERFACE prevent a route to be seen in routing table or filtering LSA?
regards,
Hello Murat
This command is specifically used to filter networks received in updates. For this reason, on the in keyword can be used. Distribute lists cannot be applied in an outgoing direction.
This command does not filter OSPF routes from being entered into the OSPF database, but it only filters routes from the routing table. It does not filter or prevent link state packets from being propagated. Since it only affects the local routing table and not the database itself, the use of an out keyword becomes irrelevant.
I hope this has been helpful!
Laz
Hi Rene,
correct me if I am wrong, as of my knowledge for OSPF to send an LSA for an specific prefix, the prefix has to be in its Routing table. Just like when we are summarizing the on ABR and ASBR if the prefix are not found in routing table the whole summary adv will be dropped, in this scenario we implemented an distribution list where 1.1.1.1 is denied hence it can not be found in the routing table, how ever it is propagated through R2 to reach R3. Can you kindly explain this.
Thank You,
Teja
Hello Teja
First of all, in order for an LSA of a specific prefix to be sent, the prefix doesn’t have to be in the routing table, but it must be in the LSDB. This is the prerequisite. Now keep in mind that route filtering for OSPF can only take place at ABRs and ASBRs. This is because within an area, all routers must have the same knowledge of the topology. This is part of the fundamental functionality of OSPF.
Now in this lesson, we must begin with this premise, that nothing we can do can cause LSAs from being distributed between routers of the same area. However, what we can do is filter routes from entering the routing table.
In this lesson, distribute lists have been used to block certain routes which are in the LSDB from entering the routing table. This means that the distribute lists applied only affect the local router and do not affect the way in which LSAs are distributed among routers.
This is why even though a distribute list was used on R2 to “block” the 1.1.1.1 prefix, it only blocked it from entering the local routing table, and not from being propagated to the rest of the network. This is why Rene states that:
You have to be very careful if you use this command. If you are not careful you can end up in a scenario where you blackhole some traffic.
I hope this has been helpful!
Laz
2 Likes