Type5 to Type7 translation - completely lost

tinu_karkitinu_karki Member Posts: 21 ■□□□□□□□□□
in CCIE
I am doing one of the INE AT workbook exercises. In this scenario NSSA Area 1 has three routers - R6 - 150.1.6.6 (ASBR redistributing its loopback), R1 and R4 (ABR's). I am seeing some behaviour which makes no sense to me at all Sad


My assumptions are - if a P-bit is set to zero then an LSA7 cannot be translated to LSA5 and is only propogated within the NSSA. Secondly if translation is allowed then the ABR does the translation, if there are multiple ABR's then the one with the highest RID will do the translation. The observations below are not making much sense based on these assumptions:



1. So the first area of confusion for me is that for some reason the P-bit is set to zero, however a Type-5 LSA is still created, and another router in another area (Ricon_cool.gif can see the distributed route:

- First the output showing that R6 is not an ABR:

R6#sh ip ospf int br

Interface PID Area IP Address/Mask Cost State Nbrs F/C

Lo0 1 1 150.1.6.6/32 1 LOOP 0/0

Et0/1.146 1 1 155.1.146.6/24 10 BDR 2/2

Et0/1.67 1 2 155.1.67.6/24 10 BDR 1/1

R6#sh ip ospf border-routers



OSPF Router with ID (150.1.6.6) (Process ID 1)





Base Topology (MTID 0)



Internal Router Routing Table

Codes: i - Intra-area route, I - Inter-area route



i 150.1.1.1 [10] via 155.1.146.1, Ethernet0/1.146, ABR/ASBR, Area 1, SPF 15

i 150.1.3.3 [20] via 155.1.67.7, Ethernet0/1.67, ABR, Area 2, SPF 6



i 150.1.4.4 [10] via 155.1.146.4, Ethernet0/1.146, ABR/ASBR, Area 1, SPF 15



R4#sh ip ospf database nssa-external



OSPF Router with ID (150.1.4.4) (Process ID 1)



Type-7 AS External Link States (Area 1)



Routing Bit Set on this LSA in topology Base with MTID 0

LS age: 173

Options: (No TOS-capability, No Type 7/5 translation, DC, Upward)

LS Type: AS External Link

Link State ID: 160.1.6.6 (External Network Number )

Advertising Router: 150.1.6.6



R8#sh ip ospf data external



OSPF Router with ID (150.1.8.icon_cool.gif (Process ID 1)



Type-5 AS External Link States



Routing Bit Set on this LSA in topology Base with MTID 0

LS age: 1901

Options: (No TOS-capability, DC, Upward)

LS Type: AS External Link

Link State ID: 160.1.6.6 (External Network Number )

Advertising Router: 150.1.6.6



- Secondly I can see R6 creating the Type5 LSA even though its not an ABR (output above shows no interfaces in Area 0), I'm lost

R6#sh ip ospf database self-originate



OSPF Router with ID (150.1.6.6) (Process ID 1)



Router Link States (Area 1)



Link ID ADV Router Age Seq# Checksum Link count

150.1.6.6 150.1.6.6 775 0x80000009 0x00DDD7 2



Type-7 AS External Link States (Area 1)



Link ID ADV Router Age Seq# Checksum Tag

160.1.6.6 150.1.6.6 1023 0x80000002 0x0075D6 0



Router Link States (Area 2)



Link ID ADV Router Age Seq# Checksum Link count

150.1.6.6 150.1.6.6 1023 0x80000005 0x0022ED 1



Type-5 AS External Link States



Link ID ADV Router Age Seq# Checksum Tag

160.1.6.6 150.1.6.6 775 0x80000006 0x0089C0 0
· Share on FacebookShare on Twitter

Comments

  • fredrikjjfredrikjj Member Posts: 879
    R6 has an interface in area 2 which i assume is a normal area. When you redistribute on r6 it creates a type 7 in area 1 and type 5 into area 2. The translator doesnt translate the type 7 because a type 5 for the same prefix already exists via area 2. Thats what i think anyway, i could be wrong. I quickly reda some sections of the rfc and it does talk abort how the type 7 sometimes isnt translated if type 5 already exists.
    · Share on FacebookShare on Twitter
  • tinu_karkitinu_karki Member Posts: 21 ■□□□□□□□□□
    Hi Fredrikjj,

    You are right. I tested this theory by shutting down R6 area 2 interface, when this was done then an LSA5 for the prefix was still seen but had the ABR's ip address as the advertising router.
    · Share on FacebookShare on Twitter
  • fredrikjjfredrikjj Member Posts: 879
    I'm back home now and I did some tests. When I wrote my previous post I kind of assumed that it was the NSSA t7 to t5 translator that looked at the type 5 external in area 0 and said "this external already exists, I shouldn't translate the type 7 for the same prefix". That's not what happens. What actually happens is that when the ASBR injects an external prefix into both the NSSA area and the normal area at the same time, it does not set the P-bit on the NSSA prefix. It therefore isn't translated when it reaches the translator. That's indicated by the line "Options: (No TOS-capability, No Type 7/5 translation, DC, Upward)" in the LSA.

    This wouldn't necessarily be problem IF the forwarding address in the type 5 external was set to an address on the ASBR. If that was the case, routers could use the shortest path to the forwarding address to reach the ASBR, using type 1/2/3 LSA information. The forwarding address is not set in the type 5 LSA though, and it gets the default 0.0.0.0. Routers must therefore rely on the type 4 LSA to reach the ASBR, and only the normal area ABR injects type 4 LSAs, not the NSSA ABRs. This means that if you have this situation, you cannot use the NSSA area as transit to the ASBR from area 0's perspective. Hopefully this makes sense, I just got home from a dinner party :)

    I don't know if there's a solution to this yet. There's an "nssa-only" parameter on the redistribution command, and this does seem to prevent the type 5 external from being created, but it also clears the p-bit so the type 7 doesn't get translated.
    · Share on FacebookShare on Twitter
  • fredrikjjfredrikjj Member Posts: 879
    I messed around and came up with this: https://fredrikjj.files.wordpress.com/2015/04/forwardingaddress.png
    · Share on FacebookShare on Twitter
Sign In or Register to comment.