07-17-2019 04:30 AM
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.
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?
Solved! Go to Solution.
07-17-2019 09:12 AM - edited 07-17-2019 09:32 AM
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.
07-17-2019 05:47 AM
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
07-17-2019 06:49 AM
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
07-17-2019 08:27 AM
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
07-17-2019 09:12 AM - edited 07-17-2019 09:32 AM
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.
07-17-2019 09:25 AM - edited 07-17-2019 10:13 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide