07-05-2008 10:24 PM - edited 03-06-2019 12:00 AM
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?
Solved! Go to Solution.
07-06-2008 06:59 PM
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,
07-06-2008 02:45 AM
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
07-06-2008 08:42 AM
07-06-2008 09:51 AM
what is your problem?
07-06-2008 12:03 PM
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
07-06-2008 03:12 AM
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.
07-06-2008 12:19 PM
yes..this makes sense and this is exactly the situation i have but for some reason conversion is not happening on the NSSA ABR...
07-06-2008 12:42 PM
on both NSSA ABRs, or only on one of them?
07-06-2008 12:46 PM
well only one ABR (with the highest RID) is designated with translating the LSAs and it's not doin in
07-06-2008 01:57 PM
could you show the configurations?
07-06-2008 02:07 PM
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
07-06-2008 02:23 PM
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
07-06-2008 02:51 PM
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
07-06-2008 06:59 PM
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,
07-06-2008 09:25 PM
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?
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