How to See What OSPF Redistributes - Page 3

rookie R · ‎05-23-2025

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!

Royalty · ‎05-27-2025

Sorry to be a bit off topic from the actual question. Thoroughly enjoyed this thread! I would've previously simply just said that an ASBR is a router that originates Type-5 or Type-7 LSAs. Having read Paul's comments, I'd think more deeply now. Has been equally insightful to read the posts from Joseph and Rick

I suppose it wouldn't necessarily be incorrect to say that an NSSA ABR originates Type-5 LSAs - technically it is translating Type-7 to Type-5, but it is thus the originator of the Type-5? In my view, that definition blurs the distinction between what should properly be considered an ASBR: A router that sits at the boundary of the OSPF domain and redistributes routes contained in the RIB that were learnt from an external source (e.g., another routing protocol or static/connected routes). An NSSA ABR may translate Type-7 to Type-5, but it is not necessarily the creator or original originator of the external routes.

The OSPFv2 RFC 2328, in a couple of sections, makes claims that an originator of Type-5 LSAs are considered ASBRs.

List of AS-external-LSAs
These are part of the link-state database. 
These have originated from the AS boundary routers.

So referring back to my comment in the first paragraph - is an NSSA ABR an originator of the Type-5 (AS-external-LSA)? I would say so, even if technically it is 'translating'.

What is perhaps more interesting is that an NSSA ABR's Type-1 LSAs are created with the E-bit set, indicating that it is an ASBR. This is the case even if the NSSA ABR is not directly redistributing (not a self-originator) routing information from non-OSPF sources. This is also stated in RFC 3101 and 1857:

NSSA AS boundary routers may originate type-7 LSAs. 
 All NSSA area border routers must also be AS boundary routers since they all must
 have the capability of translating a type-7 LSAs into a type-5 LSAs

So as a true example, a Type-1 Router LSA does indicate an NSSA ABR, who is not a self-originator of external routing information, as an ASBR. So should the distinction perhaps be noted as whether a router is an 'NSSA internal ASBR' or just an 'ASBR'

I personally still think of an ASBR as the router performing redistribution from another routing protocol/information source. I have to say that in real life I have never heard an NSSA ABR also described as an ASBR just because 'it is an NSSA ABR'. It may functionally set the E-bit to indicate that it is an ASBR by nature of doing Type-7 to Type-5 translation, but for the engineers I have worked with, The ASBR has always been the one performing the actual redistribution, and at the 'boundary'.

I think there are multiple correct answers from my perspective, and as usual in many nuances with certain technologies, no clear cut answer that is 100 percent right/wrong?

Back to the original question about identifying the OSPF routers performing redistribution... I think everyone here has already summed it up perfectly.

Joseph W. Doherty · ‎05-27-2025

NB: only saw this after I posted my reply.

This is also stated in RFC 3101 and 1857:

NSSA AS boundary routers may originate type-7 LSAs. 
 All NSSA area border routers must also be AS boundary routers since they all must
 have the capability of translating a type-7 LSAs into a type-5 LSAs

For 1857 you meant 1587, I suspect.

Yes, what you're quoting is in RFC 1587, but is that exact, or similar, text found in RFC 3101?

From my skimming RFC 1587, I suspect that statement wasn't intended, exactly as written, because of all the other references to the differences between the NSSA border router and AS boundary router. What may have been intended, a NSSA capable ABR must have the capability to translate type 7 to type 5, even if it's an ASBR because if it's connected to a NSSA, that NSSA could have an internal ASBR. I.e. it could generate type 5 for the itself, as its own ASBR, but concurrently, need to translate type 7 to type 5 for NSSA internal area ASBRs.

In my prior reply, I mentioned that translation of type 7 to type 5 is sort of the equivalent of doing NAT. Consider, if some host is being NATted, would we say the network device doing the NAT is the actual host that's being logically communicated with? I.e. the NAT router is the mail server, the web server, John Doe's web browsing host, etc.? From the outside world, going by the IP address, it "looks" that way, but it's not the actual end host device.

Or, in the world of OSPF, if I use the ABR area # range command, is the summarized network prefix the actual network hosting a device I want to communicate with?

So, the NSSA option, changed how things actually worked, some are visible changes, like the type 7, some are "invisible", like translating to type 5. But, I don't think those changes were meant to fundamentally change the conceptional meaning of what an ASBR is.

IMO, it boils down to, before the NSSA option, whatever router initially created type 5s, that was an ASBR. With the addition of the NSSA option, an ASBR might originally generate (based on area kind) either type 5 or type 7, and, an ABR "seeing" type 7 must be capable of translating them to type 5. So, what's changed, simple identification of an ASBR, using type 5, no longer applies if the NSSA option is supported. Likewise, even within an area, other same area routers, including those NOT ABRs, if they "obtain" a type 7, they must know how to use it. (BTW, I found mention, for compatibility, the latter is "guaranteed" because all area router need to agree on the area kind.)

Royalty · ‎05-31-2025

Apologies, a bit of a late response but do always read the reply! We definitely were both looking at the same sort of things! I do agree with your thoughts Joseph that we should not consider a router an ASBR just because other routers are viewing it as so, or as you've stated, if I understand correctly, the use of an NSSA means we can no longer count on a type-5 LSA origination as a true classification of an 'ASBR' router. It makes sense the RFCs could have contradictions in areas in terms of wording, and I suppose how others interpret the wording too? Especially given the addition of the NSSA feature after the original OSPFv2 specifications were written, as you have already noted, as there were many. The NSSA feature seemed to be mentioned only in the last RFC for OSPFv2 (2328), but again, there are two NSSA RFCs, one before 2328, one after. And 3101 seems to be a bit more careful in the wording? I'm not sure how my post sounded, I was going for a neutral both-sides argument. For me, all the points you made are all ones I can relate to nicely. My personal opinion agrees with you that an ASBR is the router that is truly sitting at the edge/boundary that is configured to redistribute from non-OSPF routing sources into OSPF. My unbiased or forgiving opinion is that I wouldn't want to say someone is wrong if they thought of a router acting as an NSSA ABR as an ASBR. It is very nuanced... I was fond of the analogy you made with politics in an earlier post!

@rookie R Was there anything with the original question(s) you are still uncertain of or need clarity on? Courtesy of asking since I've not contributed a whole lot and raided your post, I apologise!

Joseph W. Doherty · ‎06-03-2025

Hey, all, I've separately contacted one of our prior VIPs, @Peter Paluch, for his opinion on the question of a NSSA ABR doing type 7 to type 5 for a NSSA interior area ASBR, is also, itself, an ASBR.

Peter was kind enough to reply to my query, and his response is "classic" Peter, i.e. excellent, and well worth reading! So, I'm sharing it.

(NB: lines starting with a ">" are copies of some of what I wrote to Peter.

> Is a NSSA ABR doing type 7 to type 5 translations, an ASBR?

Yes, it is. Basic RFC2328 mandates that only ASBRs can be originators of AS-External LSAs (Type-5 LSA, or LSA5 for short). A translator ABR between an NSSA area and other areas originates LSA5s on behalf of existing LSA7s, so for all intents and purposes of OSPF, it is an ASBR.

You can even give this a try: You can configure a translating ABR to perform summarization (“summary-address”) or filtering (“distribute-list out”) of the advertised external networks in LSA5s, and it should work. Such operations are only valid on a true ASBR.

> The sentence I've highlighted in RED, appears to support the interpretation
> of a NSSA ABR translating type 7 to type 5 is, an ASBR.

Absolutely. An “ASBR” and an “AS boundary routers” – that is the same thing. You can check RFC 2328 for the acronym ASBR – it appears for the first time in Section 16.4 Step 3 and expands to the “AS boundary router”.

There are also other consequences of a router acting as an ASBR – it must indicate it in its LSA1 by setting the E-bit. This makes it clear to the entire area that that router is an ASBR. Other ABRs to other areas are then responsible to originate a LSA4 (ASBR-Summary-LSA) to other areas on its behalf.

> Further in my skimming of replacement RFC, 3101
> (https://datatracker.ietf.org/doc/html/rfc1587#page-5), I couldn't find
> an equivalent statement.

Upon skimming through RFC 3101, I have the feeling that during the rewrite, the authors wanted to avoid a possible confusion between an NSSA ASBR and a regular ASBR, and so they avoid talking about regular ASBRs almost completely. However, browse down in RFC 3101 to Appendix B:

bit E

When set, the router is an AS boundary router (E is for
external). ALL NSSA border routers set bit E in those
router-LSAs originated into directly attached Type-5 capable
areas. An NSSA's AS boundary routers also set bit E in their
router-LSAs originated into the NSSA. (See Section 3.1 for
details.)

This clarifies it. Every ABR between a NSSA and other areas must claim itself as an ASBR to Type-5 capable areas. It’s interesting that all, not just the translating ABRs, must set the E-bit, but this is probably to reduce the churn in other areas which would need to process an updated LSA1 (and possibly originate or flush related LSA4) anytime an ABR became or stopped being a translator.

@paul driver , substantially, it appears Peter shares your view, and he makes a compelling case that view is the what the OSPF RFCs intended too.

BTW, for those relatively new to these forums, Peter, I believe, was (and still is) considered by many (such as myself), as a superstar VIP, but, lost his VIP status when he became a Cisco employee, and also, Cisco appears to keep him so busy, he hasn't been able to keep as active in these forums; much to our loss.

Again, thank you Peter!

paul driver · ‎06-15-2025

@Joseph W. Doherty wrote:
Peter, I believe, was (and still is) considered by many (such as myself), as a superstar VIP.

100% agree Joseph, and very humble too, Never forget once at cisco live Barcelona using my VIP pass, he brought me an ice cream whilst i was doing a mock lab - I do believe he was trying to get me to relax - and it did the trick!

Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

Joseph W. Doherty · ‎06-15-2025

I've never have had the pleasure of personally meeting Peter, but Peter doing something like that isn't too surprising.

Richard Burts · ‎06-15-2025

I have had some personal contact and agree that this is very much in character for Peter.

HTH

Rick

Royalty · ‎06-29-2025

Joseph, thanks for sharing that—and to Peter for his insight! These conversations are definitely a lot of fun. Trawling through the weeds of specifics in different technologies and finding others with conflicting opinions. Paul and everyone have made some really great points that I highly value.

There is always quality information to come from Peter, whether it's here, in his presentations, or in the CCIE v5 OCG! Much respect...

MHM Cisco World · ‎06-14-2025

Any news about this issue

Did you try tag?

MHM