Philip Ratzsch: April 2010 Archives

OSPF area types and LSAs seem to be somewhat misunderstood concepts. If you've read this far, you're probably already aware that OSPF makes use of areas to break up the potential administrative nightmare of running an IGP in a network. If you've read THIS far, you're probably also aware that area 0, the backbone area, has a special significance to OSPF. The other area types and the link state advertisements used to toss information around between the routers are where a lot of people get confused.

Standard Areas


A standard area is often described with a phrase like "A standard area is the most basic type of area". Well great - 'standard' in what way? Standard areas can be thought of as being the "equal opportunity employer" of OSPF areas as every router in the area knows about every route. This is just fine if the routers are high-powered enough to store every route and run the SPF calculations without getting bogged down. Type 1 and 2 LSAs are passed between routers to convey information regarding their own interfaces and their neighbors. Internal routes, communicated by type 3 LSAs, and external routes, communicated by type 5 LSAs are sent through all standard areas as well as the backbone area, which is a type of standard area. Type 3 LSAs can be sourced by any OSPF router whereas type 5 LSAs only ever come from autonomous system border routers. Autonomous system border routers are also responsible for generating type 4 LSAs. An area border router that has an interface in that area and an interface in the backbone area will inject the type 4 LSA into the backbone area to ensure the route to the autonomous system border router is known. Type 4 LSAs are only passed internally.

In summary, a standard area can contain LSAs of type 1,2,3,4, and 5.

Stub Areas


If an area can be thought of as a leaf node on a network then a stub area may be appropriate. A stub area can be handy if devices in it are low-powered, or simply have no need to know about every route. A stub area is similar to a standard area, but routers in it are not aware of externally-sourced routes directly. In terms of LSAs, that means that type 5 LSAs are not permitted in a stub area. A type 3 LSA is injected into the area by an area border router to act as a default route, allowing connectivity outside the stub area. The type 3 LSA provides the equivalent of an "All Points East" sign for stub area routers. Type 4 LSAs are not forwarded into a stub area, as the default route is used.

For a router to be in a stub area, the area must be configured as such on all routers involved:

Weasel(config-router)# area 3 stub

In summary, a stub area can contain LSAs of type 1,2, and 3.

Totally Stubby Areas


Totally stubby areas are a Cisco invention designed to take the concept of a stub area one step further. In addition to the lack of type 4 and 5 LSAs, type 3 LSAs, which carry information about internal routes are also prohibited. The concept of an injected default route still applies (the only instance of a type 3 LSA in a stub or totally stubby area) but it also covers internal routes. All traffic leaving the area does so using this default route. While I've never tried this in a lab, I've been told that one can have multiple 'default routes' (in stub, totally stubby, and not-so-stubby areas) and internal metrics will be used to select the least-cost route. If you've tried this, let me know.

To configure an area as a totally stubby area, use the no-summary argument when defining the area:

Vole(config-router)# area 4 stub no-summary

In summary, a totally stubby area can contain LSAs of type 1 and 2 as well as a type 3 LSA for the default route.

Not-so-stubby Areas


Yet another Cisco-concocted area type, the NSSA is a variant of the stub area type but is allowed to contain an autonomous system border router. Since type 5 LSAs are not permitted in stub areas of any type, a type 7 LSA is used. For the record, there is a type 6 LSA that is used by Multicast OSPF. MOSPF is an extension of OSPF designed to support (surprise!) multicast. At any rate, a type 7 LSA is essentially a type 5 LSA with a fake beard and glasses on. It performs the same function as a type 5, but is permitted through NSSAs. A hard-learned lesson for me was that by default an NSSA does NOT have a default route injected into it by an area border router. To have one (yes, please) the default-information-originate argument must be used:

Marmoset(config-router)# area 5 nssa default-information-originate

This comes in handy if one wishes to route traffic out of an NSSA.

If totally stubby area functionality is desired, all area border routers must be configured appropriately:

Marmoset(config-router)# area 5 nssa no-summary

Note that if an NSSA is configured to behave like a totally stubby area, a default route IS injected by the area border routers so the default-information-originate parameter is not necessary.

In summary, a not-so-stubby area can contain LSAs of type 1,2,7 and if configured for it, a type 3 for a default route.

Bonus Fact


Type 8 LSAs are very rarely used, but can carry BGP information over OSPF. I haven't the faintest idea how to use them, so don't ask.

LSA types 9 - 11 are called 'opaque LSAs' and are reserved for future growth. I plan to make use of them in my proposed "Kinda-stubby-but-only-if-you-squint-right" area.

While I'm pretty sure all of this is correct, it's possible that I either missed something or made a type somewhere. If you spot an error, please let me know so I can correct it.

IPv6 and OSPFv3

| | Comments (2)

Like most of you out there, I think about OSPFv3 and IPv6 regularly. Looking up 'regularly' in the Philip-English Dictionary we see it defined as "the day before yesterday while I was on my way home from work". Specifically, I was thinking "Huh - I don't know much about OSPFv3, and even less about IPv6".

IPv6 as I'm sure you're aware, was first proposed several years ago to put some of our out-of-work bits back to work. We've got bits everywhere with nothing to do, and here we are using a measly 32 of them in an IPv4 address. Cranking that number up to 128-bits allows us to take some of these bits off the street and make the internet more confusing to boot. It's really win-win.

With these two thoughts in mind, I decided to set up a little IPv6/OSPFv3 lab. Grabbing a spare 6504 and a couple of 4948s I set to work.

Lesson The First: any IOS version that has "ipbase" in it's name will not work. You'll be able to put an IPv6 address on a routed interface, but the command to enable IPv6 routing device-wide is missing. Go for "ipservices".

ipv6 unicast-routing is the universal command to enable (surprise!) IPv6 unicast routing. ipv6 cef could also be enable if you want to use uRPF (Unicast Reverse Path Forwarding).

Putting an IPv6 address on an interface is as straight-forward as it is in IPv4:


IPv6Lab1(config-if)#no switchport
IPv6Lab1(config-if)#no ip address
IPv6Lab1(config-if)#ipv6 address 2001:410:0:5::1/64
IPv6Lab1(config-if)#ipv6 ospf 1 area 0

Notice that the last command explicitly places the interface into OSPF area 0. Rather than say "All interfaces in network x.x.x.x/y go into area z" it's on an interface by interface basis. Personally, I think this makes it much clearer, but if there's any confusion there's always the fall-back command:


IPv6Lab1#sh ipv ospf int b
Interface PID Area Intf ID Cost State Nbrs F/C
Gi1/47 1 0 58 1 DR 1/1
Gi1/48 1 0 56 1 BDR 1/1

The bulk of the commands related to IPv6 differ only from their IPv4 counterparts in that one uses "ipv6" instead of "ip". A major gripe I have with Cisco (other than those currently displayed at dearcisco.com) is that sh ip int b shows nothing related to IPv6. Not even an indicator that the interface HAS an IPv6 address. sh ipv int b shows this information but in a much more vertical format rendering it easy to scroll off the screen. I recommend using sh ipv int b | e do|una as it filters out all the 'down' or 'unassigned' interfaces.

Getting back to configuring IPv6 addresses, the ipv6 address <blah> command can take an additional parameter of eui-64. This seems to work the MAC address into the IPv6 address which can be a bit confusing; suddenly there are a bunch of hex characters that weren't typed in. Anyway, on with the show.

OSPFv3 has some other little quirks that are handy to know. In previous versions, there was a hierarchy that OSPF would go through to select the router ID used by the device. First, it would check for a hard-set router ID. In the absence of a hard-set RID, the highest IP address on the loopbacks would be used. If no loopbacks are set, the highest IP anywhere on the device is selected. Obviously it doesn't make sense to have an OSPF process running if there isn't a layer 3 configuration on the device. With IPv6 and OSPFv3 one might think that the same logic would apply. It does. Identically. IPv6 addresses are not used for RIDs (possibly for sanity reasons) in OSPFv3. If no hard-set RID or IPv4 address is configured anywhere on the device OSPF will simply refuse to start. The day will come (if it hasn't already) when someone new to a configuration will remove the "pointless" IPv4 loopback on a device. It won't be a problem at first, but when either the chassis or the OSPF process reloads OSPF won't come back up. Brace for impact.

The moral of the story is the the output of sh ipv ospf nei will look shockingly similar to that of IPv4 and earlier versions of OSPF:


IPv6Lab1#sh ipv o n

Neighbor ID Pri State Dead Time Interface ID Interface
10.0.0.4 1 FULL/BDR 00:00:36 7 GigabitEthernet1/47
10.0.0.3 1 FULL/DR 00:00:35 54 GigabitEthernet1/48

While I won't bother repeating the commands of adding an IP address to an interface and adding an interface to an OSPF area, below are the end results of my fiddling. The topology is three devices arranged in a triangle, all IPed interfaces in area 0.


IPv6Lab1#sh ipv route
IPv6 Routing Table - Default - 8 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
B - BGP, R - RIP, I1 - ISIS L1, I2 - ISIS L2
IA - ISIS interarea, IS - ISIS summary, D - EIGRP, EX - EIGRP external
O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
C 2001:410:0:1::/64 [0/0]
via GigabitEthernet1/48, directly connected
L 2001:410:0:1::1/128 [0/0]
via GigabitEthernet1/48, receive
LC 2001:410:0:2::2/128 [0/0]
via Loopback0, receive
OE1 2001:410:0:3::2/128 [110/21]
via FE80::8A43:E1FF:FE08:7C3F, GigabitEthernet1/48
C 2001:410:0:5::/64 [0/0]
via GigabitEthernet1/47, directly connected
L 2001:410:0:5::1/128 [0/0]
via GigabitEthernet1/47, receive
O 2001:410:0:6::/64 [110/2]
via FE80::226:CBFF:FE30:8980, GigabitEthernet1/47
via FE80::8A43:E1FF:FE08:7C3F, GigabitEthernet1/48
L FF00::/8 [0/0]
via Null0, receive

As mentioned in other attempts at tutorials, I am by no means an expert. According to Cisco, I'm merely an "associate". No guarantees are made as to the accuracy of this information. I may be wrong - in fact, I probably am. Consult a physician before changing your dose.

About this Archive

This page is a archive of recent entries written by Philip Ratzsch in April 2010.

Philip Ratzsch: March 2010 is the previous archive.

Philip Ratzsch: May 2010 is the next archive.

Find recent content on the main index or look in the archives to find all content.