05-23-2025 09:30 PM
Hi all!
I have a couple of questions regarding ospf route redistribution:
1. How can I determine which ospf routers are being redistribute into other protocols? First, I thought show ip route would give me the answer, but apparently not. For example, the route to 22.22.22.22 appears as a static\connected route in the routing table. so would 'show ip ospf database' help in this case?
2.what exactly does ospf redistribute into other protocols? I assume maybe it's based on the LSAs?
3.can I use 'show ip route eigrp' to see which eigrp routes are being redistributed into other protocols? Similary, can I use show ip bgp to find out which BGP routes are being redistributed?
Below is the configuration of R2 for reference:
R2#show run
Building configuration...
Current configuration : 1228 bytes
!
! Last configuration change at 19:57:53 CST Sat May 24 2025
!
version 15.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R2
!
boot-start-marker
boot-end-marker
!
!
!
no aaa new-model
clock timezone CST 8 0
mmi polling-interval 60
no mmi auto-configure
no mmi pvc
mmi snmp-timeout 180
!
!
!
!
!
!
!
!
!
!
!
!
no ip domain lookup
ip cef
no ipv6 cef
!
multilink bundle-name authenticated
!
!
!
!
!
!
!
!
!
redundancy
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
interface Loopback5
ip address 22.22.22.22 255.255.255.255
!
interface Ethernet0/0
ip address 192.168.12.2 255.255.255.0
!
interface Ethernet0/1
no ip address
shutdown
!
interface Ethernet0/2
no ip address
shutdown
!
interface Ethernet0/3
no ip address
shutdown
!
router ospf 2
network 22.22.22.22 0.0.0.0 area 0
!
router bgp 2
--More--
*May 24 11:57:53.567: %SYS-5-CONFIG_I: Configured from console by console
bgp router-id 2.2.2.2
bgp log-neighbor-changes
redistribute ospf 2
!
ip forward-protocol nd
!
!
no ip http server
no ip http secure-server
!
!
!
!
control-plane
!
!
!
!
!
!
!
!
line con 0
exec-timeout 0 0
privilege level 15
logging synchronous
line aux 0
line vty 0 4
login
transport input none
!
!
end
R2#
R2(config-router)#do show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override
Gateway of last resort is not set
2.0.0.0/32 is subnetted, 1 subnets
C 2.2.2.2 is directly connected, Loopback0
22.0.0.0/32 is subnetted, 1 subnets
C 22.22.22.22 is directly connected, Loopback5
192.168.12.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.12.0/24 is directly connected, Ethernet0/0
L 192.168.12.2/32 is directly connected, Ethernet0/0
R2(config-router)#do show ip ospf data
OSPF Router with ID (22.22.22.22) (Process ID 2)
Router Link States (Area 0)
Link ID ADV Router Age Seq# Checksum Link count
22.22.22.22 22.22.22.22 8 0x80000001 0x005BCD 1
R2#show ip bgp
BGP table version is 2, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 22.22.22.22/32 0.0.0.0 0 32768 ?
Here is my configuration of the R2:
R2#show run
Building configuration...
Current configuration : 1228 bytes
!
! Last configuration change at 20:11:43 CST Sat May 24 2025
!
version 15.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R2
!
boot-start-marker
boot-end-marker
!
!
!
no aaa new-model
clock timezone CST 8 0
mmi polling-interval 60
no mmi auto-configure
no mmi pvc
mmi snmp-timeout 180
!
!
!
!
!
!
!
!
!
!
!
!
no ip domain lookup
ip cef
no ipv6 cef
!
multilink bundle-name authenticated
!
!
!
!
!
!
!
!
!
redundancy
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
interface Loopback5
ip address 22.22.22.22 255.255.255.255
!
interface Ethernet0/0
ip address 192.168.12.2 255.255.255.0
!
interface Ethernet0/1
no ip address
shutdown
!
interface Ethernet0/2
no ip address
shutdown
!
interface Ethernet0/3
no ip address
shutdown
!
router ospf 2
network 22.22.22.22 0.0.0.0 area 0
!
router bgp 2
bgp router-id 2.2.2.2
bgp log-neighbor-changes
redistribute ospf 2
!
ip forward-protocol nd
!
!
no ip http server
no ip http secure-server
!
!
!
!
control-plane
!
!
!
!
!
!
!
!
line con 0
--More--
*May 24 12:11:43.395: %SYS-5-CONFIG_I: Configured from console by console
exec-timeout 0 0
privilege level 15
logging synchronous
line aux 0
line vty 0 4
login
transport input none
!
!
end
R2#
Routing table:
R2(config-router)#do show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override
Gateway of last resort is not set
2.0.0.0/32 is subnetted, 1 subnets
C 2.2.2.2 is directly connected, Loopback0
22.0.0.0/32 is subnetted, 1 subnets
C 22.22.22.22 is directly connected, Loopback5
192.168.12.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.12.0/24 is directly connected, Ethernet0/0
L 192.168.12.2/32 is directly connected, Ethernet0/0
OSPF database:
R2(config-router)#do show ip ospf data
OSPF Router with ID (22.22.22.22) (Process ID 2)
Router Link States (Area 0)
Link ID ADV Router Age Seq# Checksum Link count
22.22.22.22 22.22.22.22 8 0x80000001 0x005BCD 1
BGP routing table:
R2#show ip bgp
BGP table version is 2, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 22.22.22.22/32 0.0.0.0 0 32768 ?
Thanks so much!
05-24-2025 01:40 AM
- Check the output from : show ip ospf 2
M.
05-24-2025 02:24 AM
Hello
When a rtr running ospf receives/advertises routes via redistribution then that rtr becomes an ASBR - basically an external border router between ospf and the other protocol (such as eigrp/bgp/isis)
to check the external routes of an ASBR you can check the Link State database (LSDB) for the advertised external LSAs
sh ip ospf database external = type 5 lsa =E1/2 routes
sh ip ospf database nssa-external = type7 lsa =N1/2 routes
05-24-2025 07:50 AM
When a rtr running ospf receives/advertises routes via redistribution then that rtr becomes an ASBR
Technically, believe an ASBR needs to redistribute into OSPF. If router is only injecting OSPF routes into another non-OSPF routing protocol, it's not an OSPF ASBR.
BTW, sometimes I've seen OSPF configurations, rather then including interface networks into OSPF, redistribute "connected". Shazam, that router becomes an ASBR. (I suspect this is done to avoid the "need" to configure an OSPF statement for every interface. [Also those that do this often seem unaware of some of the inherent. OSPF potential impacts. Not necessarily bad, just possibility unappreciated.])
05-24-2025 11:24 AM
Joseph makes a very good point, that you can not look at OSPF and find what it is redistributing to other protocols. You need to look at other protocols running on the device and see what they are learning via redistribution from OSPF.
The OP also asks what exactly does ospf redistribute into other protocols, is it based on LSAs? It is really not based on LSAs. The redistributed information would include the prefix, prefix length, and next hop. Other fields in the LSA are specific to OSPF and would not be useful for EIGRP, BGP, etc.
The OP also asks can I use 'show ip route eigrp' to see which eigrp routes are being redistributed into other protocols. The answer here is similar to the first question. You can not look at routes in a routing protocol and determine what is being redistributed from the source. You must look at the receiving routing protocol and see what it is learning via redistribution.
05-24-2025 12:13 PM
The redistributed information would include the prefix, prefix length, and next hop.
The quoted "route table" kind of information I had in mind.
Other information is also often included as part of the redistribution but that's somewhat a translation or setting of similar information used by different routing protocols, such as metrics to determine the best path. (This, too, can be an issue because different routing protocols can be very different in how they determine best path, and/or other topology considerations.)
Basically, redistribution is the information Rick describes, which is LCD for routing with additional information to satisfy the routing protocol being redistributed into.
Keep in mind, you could, concurrently, redistribute multiple sources into the same routing protocol, and, on the receiving end, nothing implicitly distinguishs the original source (kind). For example, an EIGRP receiver could not distinguish between routes being redistributed from OSPF or BGP. (However, we can sometimes explicitly tag routes being redistributed, so the receiver can distinguish between redistribution sources.)
The answer here is similar to the first question.
Rick's 3rd paragraph is perhaps clearer than my "ditto #1".
05-28-2025 01:40 AM
Thanks so much. would you mind answering another question for me? I am trying to understand exactly which prefixes get redistributed by the routing protocols:
If I want to redistribute OSPF into EIGRP,and there are 6 LSAs in the OSPF database, can I say that the 6 routes generated by these LSAs are the ones being redistribute into EIGRP?
Similary, if I want to redistribute EIGRP into OSPF, and there are 6 entries shown in the 'show ip eigrp topology' command,can I assume that these 6 eigrp routes are the ones being redistribute into OSPF?
05-28-2025 07:27 AM
If I want to redistribute OSPF into EIGRP,and there are 6 LSAs in the OSPF database, can I say that the 6 routes generated by these LSAs are the ones being redistribute into EIGRP?
6 LSAs wouldn't necessarily provide 6 routes, I believe, but by default, whatever the redistribution router has, for routes, in its LSDB, should be sent to EIGRP.
Logically, this applies to any routing redistribution but cannot say for sure about EIGRP topology information. For example, I assume a successor route known to EIGRP might be excluded during redistribution. @Richard Burts , though, is very knowledgeable on EIGRP.
I touched on this before, but think of what the redistribution router would show for "show ip route", if it only had just a single source kind for its route table. The latter avoiding conflicts, and AD resolution, for different route kind sources.
Also, I'm assuming route maps aren't being used.
Also, understand, redistribution routing protocol differences may impact what the recipient actually obtains. (For example redistribution of OSPF networks into RIP which are not classful.)
Also, you are considering LSAs, but they are per LSDB, and Cisco allows multiple per router. I recall (?) redistribution from OSPF might pull from all of them, but redistribution into OSPF is to a specific LSDB.
Did I mention, in an earlier reply, redistribution can be complex and it's easy to get wrong?
05-28-2025 09:40 AM
You ask an interesting question "exactly which prefixes get redistributed by the routing protocols". Unfortunately there is not a simple/direct answer for this. There are characteristics of the protocols which may affect what is redistributed, and certainly there are options available in the redistribute commands of the protocols that might affect what is redistributed. And Joseph has done a good job of explaining that there is not necessarily a one to one relationship of what you see in the routing protocol internal tables and routes that get redistributed.
05-27-2025 01:02 AM
@Joseph W. Doherty wrote:
Technically, believe an ASBR needs to redistribute into OSPF. If router is only injecting OSPF routes into another non-OSPF routing protocol, it's not an OSPF ASBR.
Hello Joseph
Would you say an ABR of an NSSA ASBR area is ALSO an ASBR due to it performing type7-5 translation?
05-27-2025 03:28 AM
Paul, I would say a NSSA ABR not the original source of the external route is not an ASBR, i.e. type 7 to 5 translation, alone, isn't sufficient.
Believe this Cisco TechNote, https://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/6208-nssa.html is the same understanding.
Of course, though, an ABR can also be an ASBR, including for a NSSA ABR, which is also shown in the above reference (compare the two network diagrams).
Do you have reason to believe otherwise, such as, perhaps how Cisco's OSPF displays 7 to 5 translated routes?
05-27-2025 06:40 AM
Hello Joseph
My assumption when you have a ABR running in between a NSSA, this ABR will perform the type 7-5 lsa translation and then flood those types 5 into its other areas, So surely this will then designate that ABR to be an ASBR for those other areas?
05-27-2025 06:57 AM
No, not conceptionally. Again, it's not the original router injecting external routes.
Also again, look at my prior referenced Cisco TechNote two diagrams where they only label a router as an ASBR if it's redistributing routes external to the OSFP domain.
Or, what my browser's AI describes:
ASBR stands for Autonomous System Boundary Router, which is a router that connects an OSPF network to other routing domains or protocols, allowing for the exchange of routing information. It plays a crucial role in importing and redistributing external routes into the OSPF network.
Paul, do you have any reference information that supports your assumption?
Lastly, a NSSA ABR could also be an ASBR, but not just for type 7 translation to type 5 coming from an ASBR within the NSSA.
05-27-2025 08:56 AM
Hello Joseph
Mainly just based my own studies and various labbing of the protocol.
We know flooding aspect a normal ASBR, will flood type 5 LSAs for external prefixes
So taking that one step further, An ABR of an NSSA will first translate type7-5s LSAs with their attached forward addresses (FAs) then will flood (not redistribute) those type 5 LSAs just as a normal ASBR will do, thus making it become an ASBR also?
When I get the time mate ill lab it up and share the results..
05-27-2025 09:39 AM
Paul, you appear to be assuming that a type 5 LSA always corresponds to an ASBR, but it doesn't.
Perhaps this AI summary will help:
In OSPF, LSA Type 5 and translated LSA Type 5 serve the purpose of advertising external routes, but they operate in different contexts and have distinct characteristics.
Origin: LSA Type 5 is generated by an Autonomous System Border Router (ASBR) to advertise routes that are external to the OSPF domain.
Flooded To: These LSAs are flooded throughout the entire OSPF domain, except for stub areas.
Purpose: They are used to advertise external routes, such as those learned from BGP or static routes, into the OSPF network.
Example: An ASBR might redistribute a BGP route into OSPF, creating a Type 5 LSA for that route.
Origin: Translated LSA Type 5 is generated by an Area Border Router (ABR) in a Not-So-Stubby Area (NSSA).
Flooded To: These LSAs are flooded from the NSSA into the backbone area and then throughout the OSPF domain.
Purpose: They are used to translate Type 7 LSAs, which are specific to NSSAs, into Type 5 LSAs so that external routes can be advertised to the rest of the OSPF domain.
Example: An ASBR in an NSSA generates a Type 7 LSA for an external route. The ABR in the NSSA then translates this Type 7 LSA into a Type 5 LSA and floods it into the backbone area.
Area of Origin:
Type 5 LSA: Originates from an ASBR and is flooded throughout the OSPF domain.
Translated Type 5 LSA: Originates from an ABR in an NSSA and is translated from a Type 7 LSA.
Area Restrictions:
Type 5 LSA: Not allowed in stub areas.
Translated Type 5 LSA: Allowed in all areas, including the backbone, after translation.
Purpose:
Type 5 LSA: Directly advertises external routes.
Translated Type 5 LSA: Facilitates the advertisement of external routes from an NSSA to the rest of the OSPF domain.
Memory and CPU Efficiency: Translating Type 7 LSAs to Type 5 LSAs helps minimize the memory and CPU usage of routers. In an NSSA, every ABR has two copies of every external route in its topology database: a Type 7 LSA in the NSSA area and a translated Type 5 LSA in the backbone area. The dedicated translator (the ABR with the highest router ID) handles the translation, which avoids unnecessary duplication and reduces overhead.
Type 5 LSA: Advertises external routes from an ASBR and is flooded throughout the OSPF domain.
Translated Type 5 LSA: Translates Type 7 LSAs from an NSSA into Type 5 LSAs, allowing external routes to be advertised to the rest of the OSPF domain.
This translation mechanism ensures that external routes can be effectively advertised while maintaining the efficiency and scalability of the OSPF network.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide