How to See What OSPF Redistributes

[rookie R]

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!

[paul driver]

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?

[Joseph W. Doherty]

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.

[paul driver]

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..

[Joseph W. Doherty]

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:

OSPF LSA 5 vs Translated

 

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.

LSA Type 5

• 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.

Translated LSA Type 5

• 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.

Key Differences

• 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.

Why Translation is Needed

• 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. 3

Summary

• 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.

[paul driver]

Hello
you appear to be assuming that a type 5 LSA always corresponds to an ASBR

Not at all Joseph-  what i’m saying is in scenarios when an ABR of an ASBR is performing LSA translation and then type 5 flooding it is in retrospect also becomes ASBR.

[Joseph W. Doherty]

Not at all Joseph-  what i’m saying is in scenarios when an ABR of an ASBR is performing LSA translation and then type 5 flooding it is in retrospect also becomes ASBR.

Well, you might be alone in that belief, because the ASR isn't actually doing the initial redistribution into the OSPF domain. Have you found anyone else saying the same?

It's sort of like also saying, every downstream router that continues to pass along the type 5 LSAs are also ASBRs (which I doubt you would).

Or consider it this way, when you reach the actual ASBR, your packet can now exit the OSPF domain and enter the external AS, for the route being advertised.  But, if a packet, with an external route, reaches the NSSA ABR, doing the translation, it cannot be immediately forwarded into the external AS, it still needs to be forwarded to the actual ASBR, which may be multiple NSSA area router hops away.

Or consider, within an area, all the routers use interior area routes to reach the ASBR, they don't go to the ABR (unless it's also the ASBR).

All the above aside, other than an ABR translating type 7 to type 5 LSAs, what's the conceptional reason or advantage "making it" an ASBR?

Again, if a packet wants to transit to the external route, it needs to reach the ASBR, which may, or may not, also transit an ABR.

Lastly, consider an OSPF router with two non-zero areas connected to it, but not area zero.  You do know, if, per chance, a packet from area X wants to reach area Y, and it transits the router with X and Y area interfaces, again without area zero, the packet can jump between the areas.  However, this doesn't make that router an ABR.

As an area zero connection and non area zero connection(s) is fundamental to being an ABR, doing external AS redistribution, not translation, appears to be fundamental to being an ASBR.

[Richard Burts]

This has been a very interesting discussion. In thinking about it I believe that it may be helpful to focus on the "B" of ASBR. The ASBR is at a Boundary of OSPF and something else (which could be another dynamic protocol or might be static, or?). I am not clear what (if anything) we should designate for the router that translates type 7 to type 5. But I do not believe that it would be a Boundary.

[Joseph W. Doherty]

I am not clear what (if anything) we should designate for the router that translates type 7 to type 5.

I've just been perusing RFC 1587 (obsolete) and RFC 3101.

Those RFCs refers to such a router as "NSSA border router".  These are ABRs that support the (optional) NSSA.

BTW, came across this rather old community posting: 

https://community.cisco.com/t5/routing/ospf-nssa-type-7-to-type-5-translation/td-p/1409611

Which addresses the same question, i.e. is the NSSA border router, doing (just) translation, also an ASBR.

Initially, in that thread, a NSSA border router is not considered an ASBR, until RFC 1587 is quoted.

However, if you peruse more of RFC 1587, I think the  RFC quote was just poorly worded, and isn't correct.

If you read the newer RFC 3101 section 2.4, the noted RFC 1587 wording has been removed (i.e.

All NSSA area border routers must also be AS boundary routers

) to further make clear the NSSA border router isn't an AS boundary router, unless, it's directly dealing with an AS boundary.  I.e. translation of type 7 to type 5, alone, doesn't make it an ASBR.

Interestingly, with a NSSA capable ASBR, it can generate either type 5 or type 7, depending on area type, but it's an ABR function to translate type 7 to type 5.

ABR and ASBR are distinct roles, and of course, both roles might be supported by one router, but it still seems to me, an NSSA border router only doing type 7 to type 5 translation, is not an ASBR.

BTW, what I suspect makes this issue/question somewhat confusing, the NSSA was added as an option to OSPF, and its design appears to attempt to minimize or capitalize on how OSPF already worked.  For example, we cannot have type 5 LSAs in the new NSSA, because they are using built on stub area rules, so we create a whole new LSA type, type 7, but once we get to the ABR, why not just "reuse" type 5 LSAs?  The rest of OSPF can continue to work as if the ASBR was actually generating the type 5 LSAs.  (In a way, we're doing "NAT" for LSA types rather than IP addresses.)  Only the NSSA ASBR and NSSA ABR, really need to "know" about type 7 LSAs and its additional rules, like what if the NSSA has multiple ABRs.

[paul driver]

Hello Joesph
TBH external path selection can be and is sometimes to me ambiguous , Especially given all the various criteria that can be involved in say a NSSA path determination across single/dual ABRs -  same/differing FAs (quad /non quad 0s) , route-preference, cost, filtering and obviously the dreaded RFC compatibility

All the above can be gleaned by RFCs and online documentation and test books etc..and  I might be as you say be  on my own in this instance but when I do my own labs I know then with some degree of certainly what I am seeing actually is correct.

Please review the attach file,, it clearly shows that an ABR (RTR3) that is attached to a NSSA ASBR (RTR4), performing type7-5 translation and the OSPF DB is clearly stating that RTR3 ABR  is also an ASBR, the other RTRs (1&2) in the BB and non BB areas also see the same, with RTR2 also creating the type4 summary for RTR3

[Joseph W. Doherty]

Paul, as I did find that old forum posting, on the question of is an ABR doing the 7 to 5 translation an ASBR, you're not totally alone in the belief that it is.

One long standing statement that supports this belief, might be "If it walks like a duck and quacks like a duck, it's a duck."

I totally agree it sure looks like it's an ASBR duck.  (I don't believe I said otherwise and, hopefully, didn't imply otherwise, either.)

It may seem I'm asking:  "are you going to believe me or your darn lying eyes"?  If so, that's correct.

Unfortunately, my "red pill" writings, apparently were insufficiently potent for you to "see" that a NSSA ABR only doing 7 to 5 translation is also an ASBR is just a construct of the OSPF "matrix".

Perhaps the final take away might be, not only avoid discussions on religion or politics, but also avoid discussions of NSSA ABRs doing 7 to 5 translations being ASBRs.  ; )

Seriously though, a very interesting discussion, although possibly much more than @rookie R expected.

[Joseph W. Doherty]

#1 You would need to check each OSPF router for active redistribution into other routing protocols of interest or you would need to examine the contents of other routing protocols for the OSPF redistributed routes, although the latter can be hit or miss for various reasons.  Examination of just the route table is also very hit or miss, for various reasons.

#2 That router's OSPF "route table" for a specific OSPF router process.  (EDIT note, my prior statement implied the whole route table, which isn't the case.  But, you need to be aware there are scenarios where you can incorrectly redistribute routes already redistributed by another router.  BTW, this article and this article might be worth reading.  Neither directly addresses OP questions, but both, somewhat, touch upon some redistribution consideratios that get into my "various reasons", above.  Redistribution can easily become complex.)

#3 Ditto #1.

BTW, more complex redistribution scenarios (like multiple routers doing redistribution and/or mutual redistribution and/or using same links, in multiple routing protocols, concurrently) are an aspect of networking that's rather easy to get wrong and mess up a network.

[Royalty]

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]

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]

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!