cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2299
Views
9
Helpful
18
Replies

NSSA ABR not translatingType 7 LSAs to Type 5

singh.andy
Level 1
Level 1

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?

1 Accepted Solution

Accepted Solutions

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,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

View solution in original post

18 Replies 18

Giuseppe Larosa
Hall of Fame
Hall of Fame

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

Both routers have similar Databases. R2 shows that it should be converting.

what is your problem?

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
Level 7
Level 7

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.

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

on both NSSA ABRs, or only on one of them?

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

could you show the configurations?

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

Correction, do a 'sh ip ospf database external' to find the forwarding address for the route in question...

Read this link, too..

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a00800949f7.shtml#trouble_ext_lsa

Thanks

Victor

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

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,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

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?

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: