cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
171
Views
5
Helpful
5
Replies

OSPF type-7 to type-5 translation issue

I faced with some strange behaviour and I can't explain it to myself.
On scheme R2 doesn't translate type-7 192.168.33.0 to type-5. But type-7 1.1.1.1 is translated.

OSPF is enabled only on interfaces in colored rectangles and R1 redistributes connected subnets.

cisco-case.jpgscheme

R2#sh ip os data

...

                Type-7 AS External Link States (Area 0.0.0.7)

Link ID         ADV Router      Age         Seq#       Checksum Tag
1.1.1.1         192.168.3.2     900         0x80000005 0x00634E 0
192.168.33.0    192.168.3.2     900         0x80000005 0x0061CC 0

                Type-5 AS External Link States

Link ID         ADV Router      Age         Seq#       Checksum Tag
1.1.1.1         192.168.1.1     891         0x80000001 0x0014AE 0

So R3 have no infomation about 192.168.33.0/24:

R3#sh ip os data

...

                Type-5 AS External Link States

Link ID         ADV Router      Age         Seq#       Checksum Tag
1.1.1.1         192.168.1.1     965         0x80000001 0x0014AE 0

I suppose it is ralated with the fact that R2 also has interface in 192.168.33.0/24, but i can't find any explanation in documentation.
In addition all works as expected when area 7 is common area, not nssa. When there is no 7-to-5 translation.

Can someone explain this case?

1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted
Beginner

Re: OSPF type-7 to type-5 translation issue

Hi, Mikhail,

It is actually the correct behavior. The LSA7->LSA5 translation is governed by P-bit. Normally, it is set so translation is performed. However, if ASBR originates both LSA5 and LSA7, it clears P-bit. So in your case:
1) R1 is connected only to NSSA so it originated only LSA7 -> P-bit is set, translation occurs.
2) R2 is connected both to NSSA and backbone (or any other non-NSSA area in fact) -> LSA5 and LSA7 are generated -> no translation for LSA7 as P-bit is cleared.

The RFC description is below, the 2nd paragraph:
https://tools.ietf.org/html/rfc3101#section-2.4

 

Edit 1

Sorry, didn't read the topology carefully first time. The actual thing is that 192.168.33.0/24 is connected to R2. The prefix from LSA7 is not pushed into RIB so it is not translated. You can try static routes or other IGP (with lower AD, of course) pointing to 192.168.33.0/24 - the behavior would be the same: LSA7 prefix does not make it into RIB so it is not translated to LSA5.

5 REPLIES 5
Hall of Fame Expert

Re: OSPF type-7 to type-5 translation issue

Hello Mikhail,

>> I suppose it is ralated with the fact that R2 also has interface in 192.168.33.0/24,

if R2 is not running OSPF over the connected interface to 192.168.33.0/24 it is a conected route and in R2 IP routing table the connected route is installed and not the LSA type 7.

However, OSPF is link state.

Can you post the details of LSA type 7 for net 192.168.33.0/24 we need to look at  the NP bit that should be set (if unset it will not propagate) and to the forwarding address field (should be 0.0.0.0).

 

To be noted you have created a very special scenario.

 

Hope to help

Giuseppe

 

Re: OSPF type-7 to type-5 translation issue

Hello Giuseppe!
This scenario occured during some migration processes. But I found it interesting.

192.168.33.0/24 looks similar to 1.1.1.1

R2#sh ip ospf database nssa-external

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

                Type-7 AS External Link States (Area 0.0.0.7)

  Routing Bit Set on this LSA
  LS age: 1007
  Options: (No TOS-capability, Type 7/5 translation, DC)
  LS Type: AS External Link
  Link State ID: 1.1.1.1 (External Network Number )
  Advertising Router: 192.168.3.2
  LS Seq Number: 80000002
  Checksum: 0x694B
  Length: 36
  Network Mask: /32
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 20
        Forward Address: 192.168.3.2
        External Route Tag: 0

  Routing Bit Set on this LSA
  LS age: 1007
  Options: (No TOS-capability, Type 7/5 translation, DC)
  LS Type: AS External Link
  Link State ID: 192.168.33.0 (External Network Number )
  Advertising Router: 192.168.3.2
  LS Seq Number: 80000004
  Checksum: 0x75B6
  Length: 36
  Network Mask: /24
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 20
        Forward Address: 192.168.3.2
        External Route Tag: 0
Hall of Fame Expert

Re: OSPF type-7 to type-5 translation issue

Hello Mikhail,

we do not see any difference in the two LSA type 7.

network 192.168.33.0/24 is directly connected to the ABR this is the only difference.

>>

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

on ABR have the subnet part of NSSA area eventually using also a passive-interface command to have the prefix advertised in the baxckbone.

 

Hope to help

Giuseppe

 

Highlighted
Beginner

Re: OSPF type-7 to type-5 translation issue

Hi, Mikhail,

It is actually the correct behavior. The LSA7->LSA5 translation is governed by P-bit. Normally, it is set so translation is performed. However, if ASBR originates both LSA5 and LSA7, it clears P-bit. So in your case:
1) R1 is connected only to NSSA so it originated only LSA7 -> P-bit is set, translation occurs.
2) R2 is connected both to NSSA and backbone (or any other non-NSSA area in fact) -> LSA5 and LSA7 are generated -> no translation for LSA7 as P-bit is cleared.

The RFC description is below, the 2nd paragraph:
https://tools.ietf.org/html/rfc3101#section-2.4

 

Edit 1

Sorry, didn't read the topology carefully first time. The actual thing is that 192.168.33.0/24 is connected to R2. The prefix from LSA7 is not pushed into RIB so it is not translated. You can try static routes or other IGP (with lower AD, of course) pointing to 192.168.33.0/24 - the behavior would be the same: LSA7 prefix does not make it into RIB so it is not translated to LSA5.

Re: OSPF type-7 to type-5 translation issue

Hi, Iaroslav!
You are absolutely right. But in my case R2 is not ASBR. It is ABR. Thare is no any redistribution on R2.

 


@Iaroslav wrote:

 

Edit 1

The prefix from LSA7 is not pushed into RIB so it is not translated.


It seems you are right. Apparently it is said here :

https://tools.ietf.org/html/rfc3101#section-3.2

Only installed Type-7 LSAs and those non-default Type-7 LSAs originated by the router itself should be examined.
CreatePlease to create content
Content for Community-Ad
July's Community Spotlight Awards