NSSA ABR not translatingType 7 LSAs to Type 5

Answered Question
Jul 5th, 2008

i'm not sure why it won't translate, i have two NSSA ABRs, one of them (highest RID) shows that it should be translating the LSAs from 7 to 5 but does not. I do see Type 7 LSAs in the Database. This is on a 6509 running 12.2(18)SXF8. Has anyone seen this before?

I have this problem too.
0 votes
Correct Answer by Harold Ritter about 8 years 5 months ago

Andy,

Looking at the database entry for the type 7 lsa, we can see that the routing bit is not set. It could be that the forward address is not learnt via ospf or that the type 7 itself is not installed in the RIB (also learnt via another protocol with better AD).

Can you post the output of a "show ip ro 10.255.30.0" and "show ip ro 10.250.1.230".

Regards,

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.5 (2 ratings)
Loading.
Giuseppe Larosa Sun, 07/06/2008 - 02:45

Hello Singh,

does your router receive the type 5 LSA generated by the other NSSA ABR in area 0 ?

May you post the output of show ip ospf database about the type 7 LSA on both NSSA ABR routers ?

I wonder if seeing that the type 5 LSA is already in the database the router does not translate. May be because the other router is advertising a better metric or has done before.

hope to help

Giuseppe

singh.andy Sun, 07/06/2008 - 12:03

Type 7 LSA and not being converted to type 5 and those routes are not getting advertised out to the rest of the OPSF domain

a.alekseev Sun, 07/06/2008 - 03:12

http://www.ietf.org/rfc/rfc1587.txt

4.1 Translating Type-7 LSAs Into Type-5 LSAs

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 not an area border router this translation

algorithm should be skipped. All reachable area border routers in

the NSSA should now be examined noting the one with the highest

router ID. If this router has the highest router ID, it will be the

one translating type-7 LSAs into type-5 LSAs for the NSSA, otherwise

the translation algorithm should not be performed.

singh.andy Sun, 07/06/2008 - 12:19

yes..this makes sense and this is exactly the situation i have but for some reason conversion is not happening on the NSSA ABR...

singh.andy Sun, 07/06/2008 - 12:46

well only one ABR (with the highest RID) is designated with translating the LSAs and it's not doin in

lamav Sun, 07/06/2008 - 14:07

Singh:

If the P-bit isnt set, the ABR will not convert the type 7 LSA into a type 5 and propagate it.

One of the most common reasons for that is that the external route being redistributed into OSPF as a type 7 LSA has a forwarding address that is also external.

OSPF will not propagate a type 5 LSA into the OSPF domain that was derived from a type 7 LSA that also had an external forwarding address. It does this to mitigate routing loops.

So, go to the ASBR and do a sh ip route for the external route in question.

Then do a sh ip route for the forwarding address given in the type 7 LSA, and if it, too, is external, then there is your problem.

Let us know what you find...

Victor

singh.andy Sun, 07/06/2008 - 14:51

Doesn't look like this is case.

HQPCADS2#sh ip ospf database nssa-external 10.255.30.0

OSPF Router with ID (10.250.255.21) (Process ID 100)

Type-7 AS External Link States (Area 4)

LS age: 576

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

LS Type: AS External Link

Link State ID: 10.255.30.0 (External Network Number )

Advertising Router: 10.251.191.46

LS Seq Number: 80000062

Checksum: 0x24A3

Length: 36

Network Mask: /24

Metric Type: 2 (Larger than any link state path)

TOS: 0

Metric: 20

Forward Address: 10.250.1.230

External Route Tag: 100

HQPCADS2#sh ip ospf database summary 10.250.1.228

OSPF Router with ID (10.250.255.21) (Process ID 100)

Summary Net Link States (Area 0)

Routing Bit Set on this LSA

LS age: 563

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

LS Type: Summary Links(Network)

Link State ID: 10.250.1.228 (summary Network Number)

Advertising Router: 10.250.255.20

LS Seq Number: 80000004

Checksum: 0x989E

Length: 28

Network Mask: /30

TOS: 0 Metric: 2

LS age: 404

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

LS Type: Summary Links(Network)

Link State ID: 10.250.1.228 (summary Network Number)

Advertising Router: 10.250.255.21

LS Seq Number: 80000004

Checksum: 0x9C98

Length: 28

Network Mask: /30

TOS: 0 Metric: 3

HQPCADS2#

Forwarding address 10.250.1.230 is LSA type2 as shown in 10.250.1.228/30

Correct Answer
Harold Ritter Sun, 07/06/2008 - 18:59

Andy,

Looking at the database entry for the type 7 lsa, we can see that the routing bit is not set. It could be that the forward address is not learnt via ospf or that the type 7 itself is not installed in the RIB (also learnt via another protocol with better AD).

Can you post the output of a "show ip ro 10.255.30.0" and "show ip ro 10.250.1.230".

Regards,

singh.andy Sun, 07/06/2008 - 21:25

It's definately not in the routing table as i'm in the process of convertin from EIGRP to OSPF. I wasn't aware that it has to be in the Routing table for it for forward the LSAs. Is that the case?

Harold Ritter Mon, 07/07/2008 - 04:43

Andy,

It is definitely the case, hence the translation not taking place.

Regards,

singh.andy Sun, 07/06/2008 - 21:28

also where are you seeing that the routing bit is not set in the output? thanks

Harold Ritter Mon, 07/07/2008 - 04:45

Andy,

You would see the following if the bit was set on the specific LSA.

"Routing Bit Set on this LSA"

Regards,

singh.andy Mon, 07/07/2008 - 06:51

cool. thanks for the calrification. I guess i'll have to wait to see it working when i'm ready to turn off EIGRP.

Actions

This Discussion