Monday, November 5, 2012

OSPF NSSA External LSA: Type 7

Still with me?  Good stuff!  We’re almost done.  Last up is the OSPF Type 7 NSSA External LSA.

The Not-So-Stubby Area is a later addition to the original OSPF protocol. As such the NSSA has its own RFC that describes its operation, and it has been updated from the original.  Below are the two RFC’s that original defined the NSSA, and the later update that’s been made to it.

http://tools.ietf.org/html/rfc1587 March 1994
http://tools.ietf.org/html/rfc3101 January 2003

To understand the purpose of the NSSA we must first go back and look at the OSPF Stubby area and the limitations that are placed on it. I’m not going to do that.  At least not right now.  I may do another post that actually dives into that sort of stuff but for now I’m sticking purely with examining the LSA line by line.

The Type 7 LSA is very similar to the Type 5 LSA in form and function. Like the Type 5 there are also two sub-types: Type 1 and Type 2.  And here they are:

  Routing Bit Set on this LSA
  LS age: 621
  Options: (No TOS-capability, Type 7/5 translation, DC)
  LS Type: AS External Link
  Link State ID: 10.1.1.3 (External Network Number )
  Advertising Router: 3.3.3.3
  LS Seq Number: 80000002
  Checksum: 0x8056
  Length: 36
  Network Mask: /32
    Metric Type: 1 (Comparable directly to link state metric)
    TOS: 0
    Metric: 20
    Forward Address: 10.0.23.3
    External Route Tag: 0

  Routing Bit Set on this LSA

  LS age: 621
  Options: (No TOS-capability, Type 7/5 translation, DC)
  LS Type: AS External Link
  Link State ID: 10.2.2.3 (External Network Number )
  Advertising Router: 3.3.3.3
  LS Seq Number: 80000002
  Checksum: 0xEC67
  Length: 36
  Network Mask: /32
    Metric Type: 2 (Larger than any link state path)
    TOS: 0
    Metric: 20
    Forward Address: 10.0.23.3
    External Route Tag: 0
I think this time I’m not going to bother going through every line. The Type 7 is close enough to the Type 5 that you can easily refer back to that post and see what’s going on here.  All of the previous discussion on Type 1 vs. Type 2 still apply here, as does the Forwarding Address field meaning.  However in Type 7 LSA the ASBR always attempts to set the FA to it’s internal interface IP of the NSSA that the route is being redistributed into whereas with a Type 5 the field is usually set to 0.0.0.0.  If you’re curious on the reasoning then I encourage you to read section 2.3 in RFC 3101,

I would like to point out a key difference that matters here.
  Options: (No TOS-capability, Type 7/5 translation, DC)
With Type 7 LSA’s there’s a specific bit called the P bit that’s used to tell an NSSA ABR whether or not it should translate the Type 7 LSA to a Type 5 LSA.  If the P bit is set then the ABR does the translation, if it is unset then it does not do the translation and the route is not propagated to the rest of the OSPF domain.

Cisco IOS does not provide a way to directly set this bit. If you wish to prevent the route from propagating throughout the entire OSPF domain then you can use the area range command with the not-advertise keyword on the ABR and you will achieve the same result.

And with that I’ll conclude my series on OSPF LSA’s. If you’ve made it through all of these then I’d like to take a moment to thank you for doing so.  I’m impressed that you’ve been able to deal with my blabbering on for so long.

The complete list of OSPF LSA breakdowns:

http://blog.brokennetwork.ca/2012/10/ospf-router-lsa-type-1.html
http://blog.brokennetwork.ca/2012/10/ospf-network-lsa-type-2.html
http://blog.brokennetwork.ca/2012/10/ospf-summary-lsas-type-3-4.html
http://blog.brokennetwork.ca/2012/11/ospf-external-lsa-type-5.html
http://blog.brokennetwork.ca/2012/11/ospf-nssa-external-lsa-type-7.html

2 comments: