Type 7 LSA not translating to Type 5 LSA

[abioseibi]

In some lab scenario, I observed that the only ABR in a NSSA area was not translating some type 7 LSAs it had received to type 5.

After troubleshooting to investigate why this was so, I observed that the routes that were not translated from type 7 to type 5 on this ABR were routes the ABR had learned from another routing protocol (EIGRP) with a lower adminstrative distance.

I realised that if I lowered the AD of the of OSPF external routes on the ABR to a value below that of EIGRP or if I totally disconnected the EIGRP connection on the ABR , the type 7 to type 5 translation start to occur. There is no redistribution on the ABR but it does originate a default route since the area is NSSA.

I have read through the relevant RFCs and I dont see anywhere it states that translation from type 7 to type 5 doesnt occur for a route if that route has been learnt by the ABR from a protocol with a lower AD.

I shall appreciate any insights on this.

[Peter Paluch · Accepted solution]

Hello Abiose,

What you experienced is not obvious but logical and expected.

First of all, it must be stressed that LSA-7 received by an ABR are not simply rewritten into LSA-5 and sent on their way. Rather, the LSA-7 are first used to construct the routing table, and only afterwards, if there are Type-7 routes in this routing table, these Type-7 routes will be further advertised by this ABR into backbone area as Type-5 routes in LSA-5.

This is also implied in RFC 1587, Section 4.1:

   All type-7 routes that have been added to the routing table should be
   examined.  If the type-7 LSA (associated with the route being
   examined) has the P-bit set and a non-zero forwarding address, the
   following steps should be taken.

The most recent RFC 3101, Section 3.2 also mandates:

   This step is performed as part of the NSSA's Dijkstra calculation
   after Type-5 and Type-7 routes have been calculated.  If the
   calculating router is currently not an NSSA border router translator,
   then this translation algorithm should be skipped.  Only installed
   Type-7 LSAs and those non-default Type-7 LSAs originated by the
   router itself should be examined.  Locally sourced Type-7 LSAs should
   be processed first.

The basic idea behind this is that a router should not advertise a route it is not using itself. In your case, the OSPF ABR would be advertising an OSPF route that is not used by the ABR itself (whether the route learned via EIGRP is essentially identical to the Type-7 route or not is irrelevant - OSPF can only see that some of its routes offered to the routing table were not accepted, and hence it will not consider them for Type-7 to Type-5 translation). Advertising a route that is not actually used by the advertising router could lead to routing loops or blackholes, and should therefore be prevented.

I am not sure if this answers your question - please feel welcome to ask further!

Best regards,

Peter

[abioseibi]

Hi Peter,

Thanks for the reply.

If this is the case, it does make perfect sense and I clearly understand your explanation. Guess I should start to read the RFCs with a magnifying glass

It however objects my understanding of how LSAs are propagated by OSPF in which the routing table is derived from the from the database. Never knew of the condition that an entry in the database is derived only if it exists in the routing table.

So bottom line: If the Type-7 LSA is not installed the routing table as an OSPF route, then it doesnt get translated to Type-5. I think this should be made common knowledge.

Thanks once again.

Abiose

[Peter Paluch · Accepted solution]

Hello Abiose,

Thank you very much for your generous rating.

It however objects my understanding of how LSAs are propagated by OSPF  in which the routing table is derived from the from the database. Never  knew of the condition that an entry in the database is derived only if  it exists in the routing table.

This has to be properly understood. Surely, an entry in the database must exist before it exists in the routing table, because the routing table is the result of processing the database. However, with OSPF, there is a duality of link-state and distance-vector principle that somewhat complicates things.

With respect to a particular OSPF area, LSA-1 and LSA-2 determine its complete topology and are used to compute the routing table of the area. LSA-1 and LSA-2 must first be installed in the database and processed by the SPF algorithm to produce the routing table. An important fact to remember is that LSA-1 and LSA-2 originated by other routers  may not be modified by anyone else except their originators. That means that internal intra-area routes cannot be subjected to the check we've seen with LSA-7 because such a filtering of internal routes would constitute modifying foreign LSA-1 and LSA-2 which is absolutely forbidden. So even if a different route replaces an intra-area route learned from  OSPF in your routing table, your router still advertises that OSPF route  because it can not modify the received foreign LSA-1 or LSA-2 in which the  network is described (or better said, embedded). This is also the reason why a distribute-list in in OSPF generally affects your routing table only, but it does not affect the routing tables of routers around you.

On area borders, things change. As an ABR, you are responsible for describing internal intra-area and inter-area routes from one area to another. You do that in form of LSA-3 that are generated based on your routing table, not based on the link-state database. That means that the ABR first computes a routing table from existing LSAs associated with the particular area, and then it takes the intra-area and inter-area routes from this routing table and for each of them, it originates a new LSA-3 and floods it to other areas. There are some rules to avoid circular advertisement of inter-area routes between areas but this is the basic idea - you first have your routing table for an area, and only then you generate - or even regenerate - LSA-3 based on this routing table to represent it towards other areas.

This is something that is not made obvious enough: LSA-3 and LSA-4 are not truly flooded across the OSPF domain, contrary to the popular belief - rather, they are regenerated at each ABR. Only LSA-5 are generated only once and flooded without change throughout the OSPF domain. Hence, an ABR is in position of legally filtering networks when generating or regenerating LSA-3. This should also mean that the distribute-list in configured on an ABR that filters out certain OSPF intra-area or inter-area routes will actually have effect also on entire other areas - because it modifies the contents of the routing table from which LSA-3 are constructed.

Now, I have tested this on 12.4(15)T13 IOS and have possibly come across a bug. Consider the following scenario: routers R1, R2 and R3 connected in a row. R1/R2 are in area 0, R2/R3 are in area 2. R1 also has two stub interfaces: 192.0.2.0/24 in area 1 and 223.255.255.0/24 in area 0.

Without any filtering, the R2 routing table looks as follows:

R2(config-router)#do show ip route     
Codes: 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
Gateway of last resort is not set
O    223.255.255.0/24 [110/65] via 10.0.12.1, 00:00:07, Serial1/0
     10.0.0.0/24 is subnetted, 2 subnets
C       10.0.12.0 is directly connected, Serial1/0
C       10.0.23.0 is directly connected, Serial1/1
O IA 192.0.2.0/24 [110/65] via 10.0.12.1, 00:00:07, Serial1/0
R2(config-router)#

R3's routing table is:

R3#show ip route
Codes: 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
Gateway of last resort is not set
O IA 223.255.255.0/24 [110/129] via 10.0.23.2, 00:12:40, Serial1/1
     10.0.0.0/24 is subnetted, 2 subnets
O IA    10.0.12.0 [110/128] via 10.0.23.2, 00:12:40, Serial1/1
C       10.0.23.0 is directly connected, Serial1/1
O IA 192.0.2.0/24 [110/129] via 10.0.23.2, 00:00:10, Serial1/1
R3#

Now, on R2, I install a distribute-list that denies the inter-area network 192.0.2.0/24 and permits anything else:

ip prefix-list P seq 5 deny 192.0.2.0/24
ip prefix-list P seq 10 permit 0.0.0.0/0 le 32
!
router ospf 1
 distribute-list prefix P in

Now the routing table on R2 is:

R2(config-router)#do show ip route
Codes: 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
Gateway of last resort is not set
O    223.255.255.0/24 [110/65] via 10.0.12.1, 00:00:30, Serial1/0
     10.0.0.0/24 is subnetted, 2 subnets
C       10.0.12.0 is directly connected, Serial1/0
C       10.0.23.0 is directly connected, Serial1/1
R2(config-router)#

and on R3:

R3#show ip route
Codes: 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
Gateway of last resort is not set
O IA 223.255.255.0/24 [110/129] via 10.0.23.2, 00:07:33, Serial1/1
     10.0.0.0/24 is subnetted, 2 subnets
O IA    10.0.12.0 [110/128] via 10.0.23.2, 00:07:33, Serial1/1
C       10.0.23.0 is directly connected, Serial1/1
R3#

You can see that the 192.0.2.0/24 was actually filtered out both from R2 and R3.

The buggy behavior shows itself when I decide to filter out the network 223.255.255.0/24 on R2 which is identified as an intra-area route:

R2(config)#ip prefix-list P seq 6 deny 223.255.255.0/24
R2(config)#do show ip route
Codes: 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
Gateway of last resort is not set
     10.0.0.0/24 is subnetted, 2 subnets
C       10.0.12.0 is directly connected, Serial1/0
C       10.0.23.0 is directly connected, Serial1/1
R2(config)#

The network has disappeared from R2, however, it still is present on R3:

R3#show ip route
Codes: 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
Gateway of last resort is not set
O IA 223.255.255.0/24 [110/129] via 10.0.23.2, 00:09:37, Serial1/1
     10.0.0.0/24 is subnetted, 2 subnets
O IA    10.0.12.0 [110/128] via 10.0.23.2, 00:09:37, Serial1/1
C       10.0.23.0 is directly connected, Serial1/1
R3#

If the same logic was to be applied then the network 223.255.255.0/24 should not have been advertised from R2 to R3. This is also explained in great detail in RFC 2328, Section 12.4.3, of which I am quoting a part:

            Summary-LSAs are originated by area border routers.  The
            precise summary routes to advertise into an area are
            determined by examining the routing table structure (see
            Section 11) in accordance with the algorithm described
            below. Note that only intra-area routes are advertised into
            the backbone, while both intra-area and inter-area routes
            are advertised into the other areas.

So if the routing table on R2 as an ABR does not contain a particular internal OSPF route, it should not be advertised as LSA-3 to other areas. It has to be said, though, that these are such corner cases that I am not surprised that the implementations exhibit errant behavior.

So to sum it up: whenever an LSA is generated based on the contents of the routing table, an impresence of an OSPF-learned network in the routing table may cause the LSA not to be generated. This is valid for LSA-3 and LSA-7 that are to be translated to LSA-5.

Quite something to think about ... Sorry for the longer post.

Best regards,

Peter

[abioseibi]

It gets even clearer.

Thanks for taking the time out Peter. Much appreciated.

You should write a book (thats if you havent done so already) `OSPF- The Good, The Bad, The Not-commonly-seen`

[Peter Paluch]

Abiose,

You should write a book (thats if you havent done so already) 

LOL Thanks for encouragement... perhaps some day, I will!

It was a pleasure, as always.

Best regards,

Peter