OSPF Stub areas

Stub areas in OSPF are a way to improve scaling and reduce the amount of computing required on the routers. For routers in a non-backbone area it might not be necessary to have the information of all AS external routes. When a router in a non-backbone area wants to send traffic to a network that is outside the OSPF domain it most likely has to send the traffic to an ABR first. The router can therefore suffice with a default route to the ABR.

In a stub area AS external LSAs (Type 5) are not flooded. These are blocked by the ABR. Since ASBR summary LSAs (Type 4) are required to find ASBRs these are also blocked since the routers have a default route and need no knowledge of ASBRs.

When using stub areas consider the following:
– All routers in a stub area must be configured as such. If not they will not be able to form adjacencies.
– Virtual links can not be used inside, or traverse a stubby area
– No router in a stub area can be an ASBR
– Since stub areas use a default route sub-optimal routing can occur when the stub area has more than one ABR.

Totally stubby areas
Where a stub area blocks routes external to the OSPF domain, a totally stubby area contains only a default route, even to networks within the OSPF domain, but outside its own area. So a totally stubby area only knows about the networks within the area and has no knowledge of the rest of the network.
The ABR of a totally stubby area will not only block Type 4 and Type 5 LSAs, but will also block Type 3 Network Summary LSAs with the exception of a special Type 3 advertising the default route.

Not So Stubby Areas
One of the considerations of stubby areas is that they can not contain a ASBR. Not So Stubby Areas (NSSAs) allow for ASBRs to be contained in a stubby-like area. NSSAs have the same characteristics as stubby areas, but they allow for ASBRs. The ASBR originates Type 7 NSSA External LSAs within the area. These LSAs have a special flag, the P bit. If this bit is set to one the ABR will translate the Type 7 LSA into a Type 5 AS External LSA and send this into the rest of the OSPF domain. If the P bit is set to zero the external route will only be known in the NSSA.

OSPF LSA types

OSPF has several different LSA types. Each has its own purpose. For the CCIE R&S exam the following are required:

Type 1: Router LSA
Type 2: Network LSA
Type 3: Network Summary LSA
Type 4: ASBR Summary LSA
Type 5: AS External LSA
Type 7: NSSA External LSA
Type 9: Opaque LSA (link-local scope)

As you can see there are more. These are:

Type 6: Group membership LSA (not supported by Cisco)
Type 8: External attributes LSA
Type 10: Opaque LSA (area-local scope)
Type 11: Opaque LSA (AS scope)

Type 1: Router LSA
The Router LSA is the most basic of all LSA’s. It is sent by every router and contains a list of all interfaces, costs and neighbors of that router belonging to the area the LSA is sourced in. That means that a router which is member of two area’s sends two router LSA’s, one to each area.

Type 2: Network LSA
The Network LSA is originated by the Designated Router on a multi-access network. The DR represents the multi-access network and can be seen as a pseudo-node. So imagine a network with three routers connected to a ethernet switch. One of these routers will play the role as a single router connecting these three routers. In this regard a Network LSA is no different from a router LSA, but for it to be originated by a virtual router, the DR. This means that it contains all interfaces and neighbors of the virtual router. The cost is not advertised in this LSA since the cost from the pseudo-node to all attached devices is always 0.

Type 3: Network Summary LSA
Network summary LSA’s are sent by Area Border Routers (ABR). They contain information about one area and are advertised into another area. The ABR advertises the destinations it can reach into another area. This goes for non-backbone areas which are advertised into the backbone as for backbone information which is advertised into the non-backbone area. Default routes are also advertised with this LSA if they are external for an area.

The ABR will advertise the cost from itself to the destination in the LSA. If the ABR has multiple routes to reach the destination it will only advertise the destination once with the lowest cost. A router receiving this LSA will not run the SPF algorithm. It will accept the cost and add the cost for the router reaching the ABR to it. This will be included in the route table. This behavior is similar to distance vector routing protocols and will help scale the network.

Type 4: ASBR summary LSA
ASBR summary LSAs are also sent by ABRs. They contain a host route to an ASBR. They do not advertise routes to networks. This LSA can be used by routers in other area’s to determine the distance to the border of the AS. ASBR summary LSAs are identical to Network Summary LSAs.

Type 5: AS External LSA
AS External LSAs are used to advertise destinations outside of the OSPF network. They can only be originated by ASBRs. AS external LSAs are the only LSAs that are flooded throughout the whole OSPF network. This is also the reason why Type 4 LSAs are needed. The routers need to be able to find the ASBR.

Type 7: NSSA External LSA
NSSA External LSAs are similar to type 5 AS external LSAs. The difference being that they are not flooded throughout the OSPF network. NSSA External LSAs are only originated by ASBRs that are located in stubby areas. This is another method to make OSPF scale.

Opaque LSA
Opaque LSAs are used for application specific information. They can be used by either applications of OSPF itself to distribute information through OSPF dependent on the type of Opaque LSA used.

Distance vector vs. Link state routing protocols

Routing protocols are very important for a network to function. How would a router know


where to send a packet if there was no routing protocol. A network admin would have to configure this all by hand. Just imagine the administrative burden for a network with more than 10 routers…


There are several different routing protocols. These protocols can be divided into two categories (some might argue about this, but these two categories, at least, everybody agrees on). These categories are ‘Distance Vector’ and ‘Link State’. But what’s the difference between the two and which should you be using in your network?

Continue reading

ERSPAN on Cisco Nexus

Most network admins are familiar with span and rspan which makes it possible to troubleshoot traffic flowing through your switches.

The Nexus switches however, do not support rspan. This makes troubleshooting a switch a tad more difficult. Luckily they do support ERSPAN. ERSPAN stands for Encapsulated Remote Span. It makes span possible using a GRE tunnel to any routable address. This is even better that rspan!

What makes it even more usable is that the newest versions of wireshark natively support erspan. You can send all the span data to your own pc and analyze it from there.

To configure erspan you can use the following guide:


Kickstarting CentOS using PXE

There are many tutorials online for kickstarting a linux server, but they all cover part of the whole process. I’ll attempt to cover it all here.

First off, I’ll tell you my setup. I wanted to use PXE, kickstart and a local mirror to be able to install a lot of computers simultaniously. However, to be able to do this I tested the installation in Virtualbox with a virtual machine. Both my server and client are virtual. Second I would like to say that I’m a debian minded person. However, CentOS was required for this setup, so here we go.

One of the things I encountered was a VM which did not do any DHCP. The key here was that you need to select the right network adapter for the VM. I used the network bridge adapter which was virtualised as a PCnet-Fast III. Some others might work, but this one did it for me.

On your server you will need some software packages to be installed:

yum install httpd system-config-kickstart dhcp tftp-server syslinux

It’s possible that some are already installed. system-config-kickstart installes a gui kickstart editor. When your server doesn’t have a gui it’s useless. However, if it does, it’s easier to make a kickstart file with it.

As I also wanted a local yum repository I needed to sync a remote repository. This is not really neccesary, but when using this setup in an offline environment you’ll need it. Bear in mind that a repository for a single release is about 25GB.

rsync -avrt --delete --exclude "local*" --exclude "isos" \
rsync://mirrors.rit.edu/centos/6.2 /usr/local/share/CentOS/

This is going to take a while, but while it is syncing you can continue with the other configuration tasks.

Continue reading