Month: February 2016

OSPF NSSA Areas

In my last post, I mentioned that the stub areas are used to provide scalability. Basically, we focus on the stub and totally stubby areas.

But, what if we need redistribute routes from an external source in these stub areas?

It is important to remember that the redistribution is not allowed in stub areas.

In order to cope with this problem, OSPF provides a type of area that performs the same functions as Stub areas while allowing redistribution:  Not-So-Stubby-Areas or NSSA.

OSPF Not-So-Stubby-Areas:

The NSSA filters Type-5 LSAs, the same way the stubby areas does, however, redistribution is allowed.   What it does is generating a Type-7 LSA which is used to advertise the external routes to the ABR.   The ABR then translate the Type-7 LSA into Type-5 before flood it to the rest of the OSPF domain.   To configure an area as NSSA, use the area {area-id} nssa OSPF process command.     Now, a difference that should be mentioned is that NSSA does not automatically create a default route unlike stub areas unless explicitly configured to do so.  To generate the default route in NSSA, simply add the keyword default-information-originate to the NSSA command definition previously described.

OSPF Totally- Not-So-Stubby-Areas:

This type of area expands the NSSA capabilities, in essence, works like totally stubby areas.  It also filters Type-3 LSAs, however, redistribution is allowed.   To configure an area as Totally NSSA, use the area {area-id} nssa no-summary OSPF process command.     Now, this type of NSSA automatically creates a default route.

Let’s use the following topology to demonstrate the NSSA capabilities:

OSPF-NSSA-01

 

The relevant initial configuration files are as follows:

R1:

!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
ip ospf 1 area 30
!
interface Ethernet0/0
ip address 192.168.30.1 255.255.255.0
ip ospf 1 area 30
!
interface Serial1/0
ip address 192.168.16.1 255.255.255.252
serial restart-delay 0
!
router eigrp Branch-B
!
address-family ipv4 unicast autonomous-system 100
!
topology base
default-metric 10000 100 255 1 1500
redistribute ospf 1
exit-af-topology
network 192.168.16.0 0.0.0.3
eigrp router-id 1.1.1.1
exit-address-family
!
router ospf 1
router-id 0.0.0.1
redistribute eigrp 100 subnets
!

R2:

!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
ip ospf 1 area 0
!
interface Ethernet0/0
ip address 192.168.30.2 255.255.255.0
ip ospf 1 area 30
!
interface Ethernet0/1
ip address 192.168.10.2 255.255.255.0
ip ospf 1 area 0
!
router ospf 1
router-id 0.0.0.2
!

R3:

!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
ip ospf 1 area 0
!
interface Ethernet0/0
ip address 192.168.30.3 255.255.255.0
ip ospf 1 area 30
!
interface Ethernet0/1
ip address 192.168.10.3 255.255.255.0
ip ospf 1 area 0
!
router ospf 1
router-id 0.0.0.3
!

R4:

!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
ip ospf 1 area 0
!
interface Ethernet0/0
ip address 192.168.20.4 255.255.255.0
ip ospf 1 area 20
!
interface Ethernet0/1
ip address 192.168.10.4 255.255.255.0
ip ospf 1 area 0
!
interface Ethernet0/2
ip address 192.168.254.2 255.255.255.252
!
ip route 0.0.0.0 0.0.0.0 192.168.254.1
!
router ospf 1
router-id 0.0.0.4
area 20 stub no-summary
default-information originate
!

R5:

!
interface Loopback0
ip address 5.5.5.5 255.255.255.255
ip ospf 1 area 20
!
interface Ethernet0/0
ip address 192.168.20.5 255.255.255.0
ip ospf 1 area 20
!
router ospf 1
router-id 0.0.0.5
area 20 stub
!

R6:

!
interface Loopback0
ip address 6.6.6.6 255.255.255.255
!
interface Serial1/0
ip address 192.168.16.2 255.255.255.252
serial restart-delay 0
!
router eigrp Branch-B
!
address-family ipv4 unicast autonomous-system 100
!
topology base
exit-af-topology
network 6.6.6.6 0.0.0.0
network 192.168.16.0 0.0.0.3
eigrp router-id 6.6.6.6
exit-address-family
!

R7:

!
interface Loopback0
ip address 7.7.7.7 255.255.255.255
ip ospf 1 area 20
!
interface Ethernet0/0
ip address 192.168.20.7 255.255.255.0
ip ospf 1 area 20
!
interface Ethernet0/2
ip address 192.168.254.5 255.255.255.252
!
router ospf 1
router-id 0.0.0.7
area 20 stub
!

Let’s focus on Area 30. R6 connects to a remote office (Branch B), which operates with EIGRP. R1 performs mutual redistribution between OSPF and EIGRP.   Internet access is being provided to the Branch office from R4 in HQ.

Let’s take a look to the routing table in R6 and test reachability to R5 and R7.

OSPF-NSSA-02

As can be seen in the above output, the Branch office has routes to all segments; the loopbacks in R5 and R7 are reachable from R6.   Another thing to note is the presence of the default route in R6.   It was originated by OSPF in R4 with the command default-information originate and then redistributed into EIGRP from R1.

Now, let’s take a look at the Link-State Database in R1:

OSPF-NSSA-03

As seen in the above output, the default route, the loopback of R6 and the segment 192.168.16.0/30 (Link between R6 and R1) appear as type-5 LSAs.

Now, let’s change Area 30 to NSSA.

To do this, we have to define the NSSA in the border routers connecting the NSSA area (R2 and R3) and the internal routers (R1).

R1, R2, and R3:

!
router ospf 1
area 30 nssa
!

WARNING RGE

Be careful, this is a disruptive change.   Remember, the area types must match for the adjacencies to be formed.   Plan accordingly when making changes in the network.

After applying the changes, let’s take a look at the link-state database of R1 and R4:

OSPF-NSSA-03-1

OSPF-NSSA-03-2

As seen in the above outputs, the redistributed routes generate Type-7 LSAs in R1 then were translated by the ABR (R3) into Type-5 LSAs.   In this topology, R2 and R3 are ABRs for Area 30.  When multiple ABRs are present the ABR with highest Router-ID is elected as the translator for Type-7 into Type-5 LSAs.   R3 was elected translator.

Now, let’s take a look at the routing table in R6 and test reachability again.

OSPF-NSSA-04

It seems like everything is fine.  But wait a minute.  There’s no internet access in the branch office.    If you look closer, the default route has disappeared.   This is because NSSA does not automatically generate a default route.   But you may think, this was generated by R4, so why this happened?

Let’s take a look at the Link-State database in R1:

OSPF-NSSA-05

As seen in the above output, the Type-5 LSAs were replaced by Type-7 LSAs but the default route is not present.   This is because the ABR will not automatically inject the default route into an NSSA.  This has to be explicitly configured.

To solve this problem, we can add the keyword default-information-originate into the NSSA definition in both ABRs for load-balancing or we can choose one of the routers and force the internet traffic to use only one path.

Let’s try these two possibilities.

First, let’s originate the default route from R2:

R2:

!
router ospf 1
area 30 nssa default-information-originate
!

Now, let’s take a look to the routing table of R1 and see if the default route was injected:

OSPF-NSSA-06

As can be seen, the default route was injected as OSPF NSSA external Type 2 (O*N2).

Now let’s take a look to the LSA:

OSPF-NSSA-07

As shown in the output, the advertising router is R2 and was generated as Type-7.  The default route is now present (via redistribution) in the Branch (R6).

OSPF-NSSA-08

As shown above, the path to reach the internet (8.8.2.2) is via R2.   Now, let’s originate the default route in the other ABR (R3):

R3:

!
router ospf 1
area 30 nssa default-information-originate
!

Let’s take a look at the result in R1:

OSPF-NSSA-09

As can be seen, now R1 has 2 equal cost paths to reach the default route.

OSPF-NSSA-10

Another feasible solution would be turning Area 30 into a Totally-Not-So-Stubby-Area. This type of Area suppresses Type-5 and Type-3 LSAs.  It generates the default route as Type-3 LSA.

Let’s change only R2 and R3 to Totally-NSSA and check the results:

R2 and R3:

!
router ospf 1
no area 30 nssa default-information-originate
area 30 nssa no-summary
!

 

OSPF-NSSA-11

As seen in the above output, the default route appears as OSPF Inter-Area (O*IA).

OSPF-NSSA-12

The Type-3 LSAs were replaced by default-routes advertised by the ABRs.

It is time to close this long post. Thank you for visiting.

OSPF Stub Areas

In a multi-area OSPF network, stub areas are basically used to provide scalability.   OSPF scalability is achieved by reducing the flooding domain using areas and reducing the size of the routing table doing summarization.

Now, summarization and filtering are functions of the ABR.  This is due the hierarchical design of OSPF.   A way to reduce the routing information in an area is converting the area into Stub.

When configuring an area as Stub, the ABR will filter whatever LSA (Type-3, Type-4 and/or Type-5) which enter the area depending on the type of Stub Area that is configured.    The filtered LSAs in Stub areas are then replaced with a Type-3 default route (LSA Summarization).  Another consideration when configuring stub areas is that all routers within the stub area must be also configured as stub. Otherwise, they won’t form the adjacency.

OSPF Stub Area Types

There are four stub area types:

  • Stub Area – Filters Type-5 LSAs.
  • Totally Stubby Area – Filters Type-3 and Type-5 LSAs. These LSAs are summarized into a single Type-3 LSA which is the default route.
  • Not-So-Stubby Area (NSSA) – Filter Type-5 LSAs. Allows local redistribution in the area. The router doing redistribution in the NSSA area generates LSA Type-7 for the redistributed prefixes. The ABR translates the Type-7 LSA into Type-5 LSA when advertised to the backbone Area.  In NSSA, the ABR does not automatically originate a default route.
  • Totally-Not-So-Stubby-Area – Like Totally Stubby Area, filters Type-3, Type-4, and Type-5 LSAs and also allows local redistribution. It is, in essence, a combination of the Totally Stubby Area and NSSA.  It also generates Type-7 LSAs for the redistributed prefixes, the ABR translate this Type-7 into Type-5 LSAs when entering the backbone area. In Totally-Not-So-Stubby-Area, the ABR automatically originates the default route.

Today we will focus in the first two Stub Area Types.

To configure an area as Stub, use the area {area-id} stub [no-summary] OSPF process command.   The stub area must be defined in all routers participating in the stubby area.  The no-summary keyword is used to change from stub area to Totally Stubby Area.

Let’s use the following topology for the examples:

OSPF-STUB-01

As can be seen in the topology, the area 234 is defined as a stub area.  R1 and R5 are doing mutual redistribution between RIP and OSPF.

The initial configuration files are as follows:

R1:

!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
ip ospf 1 area 0
!
interface Ethernet0/0
ip address 192.168.12.1 255.255.255.0
ip ospf 1 area 0
!
interface Ethernet0/1
ip address 192.168.15.1 255.255.255.0
!
router ospf 1
router-id 0.0.0.1
redistribute rip subnets
!
router rip
redistribute ospf 1 metric 6
network 192.168.15.0
no auto-summary
!

R2:

!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
ip ospf 1 area 0
!
interface Ethernet0/0
ip address 192.168.12.2 255.255.255.0
ip ospf 1 area 0
!
router ospf 1
router-id 0.0.0.2
!

R3:

!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
ip ospf 1 area 234
!
interface Ethernet0/0
ip address 192.168.34.3 255.255.255.0
ip ospf 1 area 234
!
router ospf 1
router-id 0.0.0.3
!

R4:

!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
ip ospf 1 area 234
!
interface Ethernet0/0
ip address 192.168.34.4 255.255.255.0
ip ospf 1 area 234
!
router ospf 1
router-id 0.0.0.4
!

R5:

!
interface Loopback0
ip address 5.5.5.5 255.255.255.255
!
interface Ethernet0/1
ip address 192.168.15.5 255.255.255.0
!
router rip
network 5.0.0.0
network 192.168.15.0
no auto-summary
!

At this moment area 234 is a normal area.

Let’s take a look at the routing tables in R5 and R3 and test the reachability between them.

OSPF-STUB-02

OSPF-STUB-03

As can be seen in the above outputs, R5 is learning the redistributed OSPF routes from R1 with a metric of 6.   When doing redistribution between OSPF and RIP the seed metric is required.   RIP has a max-metric of 15.   Also, note R3 is learning redistributed routes from R5.   These routes are being advertised as “O E2” or OSPF External type 2 with a default metric of 20.

Now let’s take a look at the link-state database in R3:

OSPF-STUB-04

As can be seen in the above link-state database output, R3 has Type-1, Type-2, Type-3, Type-4 and Type-5 LSAs.   The Type-3 Summary information is coming from the ABR, detailing the summary information of the networks in Area 0. The Type-5 External LSAs details the redistributed routes, they were generated by R1, the Type-4 LSA details how to reach the ASBR (R1 – RID: 0.0.0.1) from where the Type-5 LSAs were learned.   Also, note the Type-5 External don’t have an explicit area (Area X) attached to the description in the database.   This is because the flooding scope of External Type-5 LSAs is the entire OSPF domain.

Let’s configure the area 234 as stub and let’s see what happens:

R2:

!
router ospf 1
area 234 stub
!

Let’s stop here for a moment and take a look on the adjacency between R2 and R4:

OSPF-STUB-05

As soon we changed the area 234 to stub, the adjacency with R4 went down.   What is the problem?   Let’s debug the hello packets and see what’s going on.

OSPF-STUB-06

According to the above output, R2 has received a hello packet with mismatched Stub/Transit area option bit.   When configuring stub areas, all participating routers must be configured as stub.   Thus, changing from normal to stub areas will tear down your adjacencies.

Let’s continue with the configuration.

R3:

!
router ospf 1
area 234 stub
!

R4:

!
router ospf 1
area 234 stub
!

Let’s take a look to the routing table and the link-state database on R3:

OSPF-STUB-07

OSPF-STUB-08

As can be seen in the above output, the routing table has changed.   Now the “O E2” OSPF external routes have disappeared.   Now the routing table has an Inter-Area default route (O*IA).

Also, note the “O IA” OSPF inter-area routes corresponding to the prefixes in area 0 are still present.

Now, let’s take a look at the link-state database:

OSPF-STUB-09

As can be seen in the above output, the Type-5 LSAs were filtered, thus, the Type-4 LSA was not generated by the ABR.

Totally Stubby Area

The Totally Stubby Area what it does is increase the filtering even more.  This type of areas filters inter-area (O IA) and external routes (O E1|E2).   To configure the area as totally Stub just adds the keyword no-summary at the end of the stub area configuration.  Because the Totally Stubby Area is an extension of stub areas, the no-summary keyword is only required in the ABR connecting the stub area.

Considering that the link between R2 and R4 is the only transit link between the backbone and the area 234, it would make sense to convert it into a totally stubby area.

So let’s make the change:

R2:

!
router ospf 1
area 234 stub no-summary
!

Finally, let’s take a look to the routing table and the link-state database:

OSPF-STUB-10

OSPF-STUB-11

As can be seen in the above outputs, now the inter-area (O IA) and the External (O E1|E2) routes were replaced with a single Inter-Area default route (O*IA).  The Type-3, Type-4 and Type-5 LSAs were filtered from the link-state database.   The full topology is still reachable because the inter-area and external routes fall into the default route.

OSPF-STUB-12

Despite the Stub and Totally Stub Areas seems attractive because of their low overhead, they also have important limitations of which I want to emphasize:

  1. Stub and Totally Stub areas do not support redistribution.
  2. Stub areas, in general, do not support Virtual-Links.

It is time to close this long post.

Thank you for visiting.

Interconnecting OSPF Discontiguous Areas

In a multi-area OSPF network, all areas must be connected to the backbone area Zero (0), otherwise, no inter-area communications are possible.  Now, since Area 0 is the backbone, it must be a contiguous area.

Let’s start today’s post with these two statements. There are situations in which these rules are broken, whether caused by design problems, hardware issues or some broken link and so on.

Today there are two scenarios that would like to mention:  Discontiguous backbone and discontiguous nonzero areas.

Interconnecting Discontiguous Backbone Area

Previously I wrote a post about how to solve situations where it is not possible to connect nonzero areas to the backbone using virtual links and the possibility of using GRE encapsulation for this purpose.    Both solutions can be applied to connect the backbone area.

Let’s use the following example to illustrate the problem and possible solutions.

OSPF-CONN-DISC-01

Let’s say we have the above network configured.    The routers are configured as follows:

 

R1:

!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
ip ospf 1 area 0
!
interface Ethernet0/0
ip address 192.168.13.1 255.255.255.0
ip ospf 1 area 0
!
interface Ethernet0/1
ip address 10.10.10.1 255.255.255.0
ip ospf 1 area 0
!
interface Serial1/0
ip address 192.168.12.1 255.255.255.0
ip ospf 1 area 0
!
router ospf 1
router-id 0.0.0.1
!

R2:

!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
ip ospf 1 area 0
!
interface Ethernet0/0
ip address 192.168.24.2 255.255.255.0
ip ospf 1 area 0
!
interface Ethernet0/1
ip address 10.10.20.1 255.255.255.0
ip ospf 1 area 0
!
interface Serial1/0
ip address 192.168.12.2 255.255.255.0
ip ospf 1 area 0
!
router ospf 1
router-id 0.0.0.2
!

R3:

!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
ip ospf 1 area 0
!
interface Loopback1
ip address 33.33.33.33 255.255.255.255
ip ospf 1 area 567
!
interface Ethernet0/0
ip address 192.168.13.3 255.255.255.0
ip ospf 1 area 0
!
interface Serial1/0
ip address 192.168.35.3 255.255.255.0
ip ospf 1 area 567
serial restart-delay 0
!
router ospf 1
router-id 0.0.0.3
!

R4:

!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
ip ospf 1 area 0
!
interface Loopback1
ip address 44.44.44.44 255.255.255.255
ip ospf 1 area 567
!
interface Ethernet0/0
ip address 192.168.24.4 255.255.255.0
ip ospf 1 area 0
!
interface Serial1/0
ip address 192.168.46.4 255.255.255.0
ip ospf 1 area 567
!
router ospf 1
router-id 0.0.0.4
!

R5:

!
interface Loopback0
ip address 5.5.5.5 255.255.255.255
ip ospf 1 area 567
!
interface Ethernet0/0
ip address 192.168.100.5 255.255.255.0
ip ospf 1 area 567
!
interface Serial1/0
ip address 192.168.35.5 255.255.255.0
ip ospf 1 area 567
!
router ospf 1
router-id 0.0.0.5
!

R6:

!
interface Loopback0
ip address 6.6.6.6 255.255.255.255
ip ospf 1 area 567
!
interface Ethernet0/0
ip address 192.168.100.6 255.255.255.0
ip ospf 1 area 567
!
interface Serial1/0
ip address 192.168.46.6 255.255.255.0
ip ospf 1 area 567
serial restart-delay 0
!
router ospf 1
router-id 0.0.0.6
!

R7:

!
interface Loopback0
ip address 7.7.7.7 255.255.255.255
ip ospf 1 area 567
!
interface Ethernet0/0
ip address 192.168.100.7 255.255.255.0
ip ospf 1 area 567
!
router ospf 1
router-id 0.0.0.7
!

The network is stable, no problems so far, life is good.

Let’s take a look to the routing table of R1:

OSPF-CONN-DISC-01-1

As can be seen in the above output, R1 has full visibility of the network.

Then after a while, Murphy’s Law occurs.  “If anything can go wrong, it will.”   A construction worker down the street accidentally breaks a fiber link.   It turns out that the link between R1 and R2 runs through the broken fiber. What would be the effect on this?   Yeah, you guessed right.   A discontiguous OSPF Backbone.

OSPF-CONN-DISC-02

Now, R1 has lost visibility of the networks advertised by R2 and vice versa.   R2 can reach the networks in Area 567 but is unable to reach any network advertised by R1.

Let’s take a look at both routing tables.

OSPF-CONN-DISC-03

OSPF-CONN-DISC-04

Have you noticed the difference?  But what about the routing table of R7?

OSPF-CONN-DISC-05

The routes to R1 and R2 are still reachable from there.   This is because R3 and R4 acting as ABR’s are able to advertise these routes.    Instead, R1 only see R3 as ABR and R2 only see R4 as ABR. Therefore, they only receive the routes from the routers in area 567.

Let me stop here to make a note on this:

This problem could be prevented by using Virtual-Links as a backup and for redundancy.  Let me explain this a little bit more.

If we had a pre-configured virtual link between routers R3 and R4 an LSA will trigger SFP recalculation when the construction worker broke the link.  Then the traffic between R1 and R2 will use Area 567 as transit to communicate.  In other words, the backbone will remain continuous due redundant links.   After the broken link was repaired, the SFP will be recalculated again and everything will be back to normal.

OSPF-CONN-DISC-06

Let’s take a look at the required virtual-link configuration:

R3:

!
router ospf 1
area 567 virtual-link 0.0.0.4
!

R4:

!
router ospf 1
area 567 virtual-link 0.0.0.3
!

With this little change, the problem will be solved and we will provide redundancy at the same time.

Let’s temporarily apply the solution to the network and take a look to the routing table of R1:

OSPF-CONN-DISC-07

As can be seen in the above output, R1 has full visibility again.  But note the difference for the routes 2.2.2.2/32, 10.10.20.0/24 and 192.168.24.0/24.  They are advertised as “O” or intra-area and reachable via the interface Ethernet0/0.   Meaning routed through the transit area.

This seems to be the right solution in this case. However, among the immediate network update plans is change the area 567 to Stub. This means that virtual-link technology cannot be used.  Virtual links are not supported in stub areas.  So what can we do to solve the problem and provide redundancy at the same time?  The solution could be creating a GRE tunnel and make it part of Area 0.

A GRE tunnel is a logical point-to-point interface which provides a way to encapsulate packets inside a transport protocol.   I will not go in-depth with this technology today.  However is necessary to mention some caveats using GRE.   For example, GRE adds 24 bytes to a packet, this may cause fragmentation.   Another important consideration is that it might introduce security issues because encapsulated packets may bypass access control lists (ACLs).   In the earlier version of IOS, only process switching was supported.    I’m mentioning this technology only as a feasible solution to the problem and the requirements on hand.

To configure the GRE tunnel between R3 and R4 we will need as a minimum a set of ip addresses to be assigned to the tunnels, source and destination ip addresses.

Let’s configure the tunnels with the following parameters:

R3:

!
interface Tunnel0
ip address 172.16.34.1 255.255.255.252
tunnel source Loopback1
tunnel destination 44.44.44.44
ip ospf 1 area 0
!

R4:

!
interface Tunnel0
ip address 172.16.34.2 255.255.255.252
tunnel source Loopback1
tunnel destination 33.33.33.33
ip ospf 1 area 0
!

The above configuration creates a GRE tunnel between R3 and R4.  The network 172.16.34.0/30 was designated for this purpose.  The source of each tunnel is the loopback1 on each router.   Because OSPF routing is enabled on these interfaces, we are using the loopbacks itself to route through the area 567.   The tunnel interfaces were also assigned to Area 0.

Let’s see what OSPF has to say about the interface:

OSPF-CONN-DISC-08

As can be seen in the above output, the interface Tunnel0 in R3 looks like a regular interface.  The network Type is Point-to-Point with a Cost of 1000.   The interface also sends Hellos every 10 seconds, with a Dead timer of 40 seconds.    It behaves as any other interface.

Let’s take a look again to the Routing table of R1 and R3.

OSPF-CONN-DISC-07

OSPF-CONN-DISC-09

As can be seen in the above output, R1 has full visibility again.  But note the difference for the routes 2.2.2.2/32, 10.10.20.0/24 and 192.168.24.0/24.  They are advertised as “O” or intra-area and reachable via the interface Tunnel0.   The tunnel interface is routing the packets through the transit area 567.

Finally, let’s trace a packet from 10.10.10.1 in R1 to 10.10.20.1 in R2:

OSPF-CONN-DISC-10

As can be seen in the above output, the trace works.  The packet is routed to 192.168.13.3 (R3), then through the GRE tunnel (172.16.34.2 in R4) which seems only one hop away and finally to 192.168.24.2 (R2).

As soon the link was restored, the regular path was chosen:

OSPF-CONN-DISC-11

Discontiguous Nonzero Areas

Having discontiguous non-zero areas is perfectly valid in OSPF.   It is normal to assume that OSPF areas are intended to be unique and that must be contiguous.  However we have to remember that the Area ID is used to build the SPT graph, in other words, is only used to create the neighbor relationship in OSPF.  The area ID is not present in the routing updates.

When an ABR generate and flood LSAs to the Backbone AREA, it summarizes LSA information from a given area into Type-3 LSAs. The next hop in the Type-3 LSA is a given ABR, not an area ID.    Routers in other areas are unaware of the source Area ID of the routes.  Thus, it is possible having multiple discontiguous non-zero areas.

For example, let’s take a look to the Type-3 Summary LSA corresponding to the loopback of R7 in our last example from R1.

OSPF-CONN-DISC-12

As can be seen in the above output, R1 is aware of the route 7.7.7.7/32 which was advertised to R1 from the ABRs (R3 and R4).    R1 is unaware of the Area ID from where the route was learned.

It is time to close this post. Thank you for visiting.

Interconnecting OSPF Areas – Virtual Links

In a multi-area OSPF network, all areas must be connected to the backbone area Zero (0), otherwise, no inter-area communications are possible.

Virtual-Links are OSPF tunnel interfaces used to solve situations where is necessary connecting a nonzero area to the backbone using another nonzero area as transit.

Let’s use the following example to illustrate the problem:

OSPF-CONN-VL1

Relevant Configuration:

R1:

!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
ip ospf 1 area 0
!
interface Ethernet0/0
ip address 192.168.12.1 255.255.255.0
ip ospf 1 area 0
!
router ospf 1
router-id 0.0.0.1
!

R2:

!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
ip ospf 1 area 0
!
interface Ethernet0/0
ip address 192.168.12.2 255.255.255.0
ip ospf 1 area 0
!
interface Serial1/0
ip address 192.168.24.2 255.255.255.0
ip ospf 1 area 24
!
router ospf 1
router-id 0.0.0.2
!

R3:

!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
ip ospf 1 area 0
!
interface Ethernet0/0
ip address 192.168.12.3 255.255.255.0
ip ospf 1 area 0
!
router ospf 1
router-id 0.0.0.3
!

R4:

!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
ip ospf 1 area 45
!
interface Ethernet0/0
ip address 192.168.45.4 255.255.255.0
ip ospf 1 area 45
!
interface Serial1/0
ip address 192.168.24.4 255.255.255.0
ip ospf 1 area 24
!
router ospf 1
router-id 0.0.0.4
!

R5:

!
interface Loopback0
ip address 5.5.5.5 255.255.255.255
ip ospf 1 area 24
!
interface Ethernet0/0
ip address 192.168.45.5 255.255.255.0
ip ospf 1 area 45
!
router ospf 1
router-id 0.0.0.5
!

As can be seen from the diagram, R2 and R4 have interfaces in multiple areas. R2 has an interface in Area 0 (backbone) and another interface in Area 24. R4 has an interface in Area 24 and another interface in area 45.

You might think that R2 and R4 are ABRs. However in Cisco deployments, for a router becomes ABR requires that at least one interface is connected to area 0 (backbone).

Now let’s take a look at the routing tables of R1 and R5 respectively.

 

As can be seen in the above outputs, R1 has OSPF routes of the loopback interfaces of R2, R3, and R4 and also has the route of the segment 192.168.24.0/24 which connects R2 and R4.  However, the route of the segment 192.168.45.0/24 and the loopback of R5 are missing.   In R5 only the connected routes are present.

Now let’s question R1 and R5 about their known ABRs.

According to the above outputs, R1 identifies R2 as the only ABR in OSPF.  R5 can’t identify any.

Remember, when a Router turns into an ABR what it does is set the “b” bit into its Type-1 LSA, then generates and flood Type-3 LSAS.    The flooding scope of Type-3 LSA is a single area.

So, let’s take a look to R2 and R4 Type-1 LSAs and see if the b-bit is set.  We know R2 has it.  R1 already identifies R1 as ABR, but I want to show you the difference between them.

As expected, R2 has the “b” bit set and is claiming to be and ABR while R4 is not.   This is the reason why the routes are not been propagated.   In order that R4 become an ABR, it is necessary that one of its interfaces to be connected to the backbone area.

There are many ways to solve this problem.  For example we can try renumbering the Area 45 and make a single area 24. Or we can just connect an interface between R2 and R5 as part of area 45. But what if none of these solutions are possible?  What if the devices don’t have free interfaces or they are placed too far from each other?   What if renumbering the area is not allowed?

Well, in this case we can use OSPF virtual-links or GRE tunnels.   In my humble opinion, it is better to use Virtual-Links instead of GRE.   To start, GRE is process-switched.  GRE also adds encapsulation overhead.  GRE encapsulates data traffic and routing traffic unlike Virtual-links, where only the routing updates are tunneled.   The only advantage of GRE over Virtual-Links is that supports tunnels through stub areas.   So let’s try using virtual-links and in a following post I will explain how to use GRE.

Let’s take a look to the requirements to configure the virtual-link:

  • The transit area cannot be a stub area.
  • The transit area shouldn’t have filtering.
  • The transit area must have full routing information.

Looking at the configuration files exposed before, note that Area 24 is a normal area and there is no filtering applied.  The last thing we need to verify is the transit area routing information.  If it has full routing information then using a virtual-link is possible.   Let’s take a look to the routing table of R4 to verify this.

OSPF-CONN-VL-07

As can be seen in the above output, R4 which is the router connecting has full routing information.  This means that Area 24 can be used as transit.

Let’s move on the configuration:

To configure the OSPF virtual-link, use the command area {transit-area-id} virtual-link {destination-router-id}.   This command goes in the OSPF process definition both routers forming part of the transit area (R2 and R4).

OSPF-CONN-VL2

 

R2: 

!
router ospf 1
area 24 virtual-link 0.0.0.4
!

R4:

!
router ospf 1
area 24 virtual-link 0.0.0.2
!

OSPF-CONN-VL-08

After the configuration was done, a new adjacency was formed via interface OSPF_VL0.

This “interface” is as a matter of fact is a multi-hop point-to-point unicast adjacency; it is in essence an extension of Area 0 across the transit area.

Let’s take a look to the virtual link using the command show ip ospf virtual-links.

OSPF-CONN-VL-09

As can be seen in the above output, the virtual-link is a demand circuit.   This is a legacy concept coming from back on the day where dialup or ISDN circuits were in use.  Back then the customers pay the link depending on the connect time or usage.   Also note the Hello is suppressed and the DoNotAge LSA is allowed.   This means that once the virtual link is up, no hellos are exchanged and the normal LSU refresh (every 30 minutes) won’t take place.  These things must be taken into account when doing troubleshooting.   In some cases is necessary clearing the ospf process for the changes take place.

Let’s take a look to the link-state Database.

OSPF-CONN-VL-09-1

The above output show the DNA (DoNotAge) bit set in some LSAs.    Also note that R4 now show Type-1 LSAs from Area 0.

Let’s take a look of the self-originated Type-1 LSA of R4.

OSPF-CONN-VL-10

As can be seen on the above output, now R4 is setting the “b” bit to its Type-1 LSAs.  This means that R4 has turn into an ABR.

Finally let’s take a look to the routing table of R5:

OSPF-CONN-VL-11

Now R5 has full reachability to the network via the transit area.

It is time to close this long post. Thank you for visiting.

Interconnecting OSPF Areas

In a previous post, we learned how to configure OSPF within a single area. Now it is time to consider what would happen if this single area grows to let’s say, hundreds of routers?

Well, with such large number of routers and segments; the network changes are inevitable.   Having this in mind, we can anticipate some problems like frequent calculations of the shortest path first (SPF) algorithm, large link-state database and of course, a large routing table.  In order to avoid these issues, OSPF allows large areas can be separated into smaller ones.  This is also known as hierarchical routing.

Before go deep into this topic we have to recall the different OSPF router types:

  • Internal Router – Routers that have all interfaces in the same area.
  • Backbone Router – Routers where at least one OSPF interface must belong to area 0 (backbone area).
  • Area Border Router (ABR) – In Cisco IOS are the Routers that have at least one OSPF interface connected to Area 0 and at least one OSPF interface belong to a non-backbone area. This may not be the case for different platforms where the only requirement is having the interfaces in different areas regardless if they are connected to the backbone area or not.   IPEXPERT’s blog has an interesting post about this here.
  • Autonomous System Boundary Router (ASBR) – Routers injecting routes (Redistribution) from another routing protocol.

Let’s take a look at the following example:

OSPF-CONN-ABR

Relevant Configuration:

R1:

!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
ip ospf 1 area 0
!
interface Ethernet0/0
ip address 192.168.12.1 255.255.255.0
ip ospf 1 area 0
!
router ospf 1
router-id 0.0.0.1
!

R2:

!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
ip ospf 1 area 0
!
interface Ethernet0/0
ip address 192.168.12.2 255.255.255.0
ip ospf 1 area 0
!
interface Serial1/0
ip address 192.168.24.2 255.255.255.0
ip ospf 1 area 24
!
router ospf 1
router-id 0.0.0.2
!

R3:

!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
ip ospf 1 area 0
!
interface Ethernet0/0
ip address 192.168.12.3 255.255.255.0
ip ospf 1 area 0
!
router ospf 1
router-id 0.0.0.3
!

R4:

!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
ip ospf 1 area 24
!
interface Ethernet0/0
ip address 192.168.45.4 255.255.255.0
ip ospf 1 area 24
!
interface Serial1/0
ip address 192.168.24.4 255.255.255.0
ip ospf 1 area 24
!
router ospf 1
router-id 0.0.0.4
!

R5:

!
interface Loopback0
ip address 5.5.5.5 255.255.255.255
ip ospf 1 area 24
!
interface Ethernet0/0
ip address 192.168.45.5 255.255.255.0
ip ospf 1 area 24
!
router ospf 1
router-id 0.0.0.5
!

Area Border Router

As mentioned earlier, ABR’s are used to connect non-backbone areas to Area 0.  ABRs take the information contained in Type-1 and Type-2 and summarize it into Area 0.  In the above example, R1, R2, and R3 are backbone routers.  R2 is also acting as ABR between Area 0 and Area 24 respectively.   R4 and R5 are internal routers of Area 24.   R2 advertise itself as ABR by setting the “B” bit in its type 1 LSA.

OSPF-CONN-01

The above output displays the self-originated Type-1 (Router) LSA with the “B” bit set.  This is the ABR in the current topology.   Another way to identify ABRs is using the command show ip ospf border-routers.

OSPF-CONN-02

The above output displays the list of known ABRs from the perspective of R1.

Also, we have to keep in mind that an ABR keeps multiple copies of the link-state database, one for each area to which that router is connected.    ABRs create and flood Type-3 (Summary) LSAs within areas; it will generate more than one summary LSA if the address cannot be properly aggregated by a single prefix (i.e. Host Routes or loopbacks).

OSPF-CONN-03

As can be seen in the above output, R2 (ABR) has 2 copies of the link-state database.  The Type-3 Summary LSA information of Area 0 details 2 networks (192.168.24.0/24 and 192.168.45.0) and 2 host routes (4.4.4.4 and 5.5.5.5) belonging to the loopbacks of R4 and R5 while the Summary LSA of Area 24 details a single network (192.168.12.0/24) and 3 host routes (1.1.1.1, 2.2.2.2 and 3.3.3.3) belonging to the loopbacks of R1, R2 and R3 respectively.     In other words, the ABR is actually hiding the topology information within areas.

Now, let’s take a look to the routing table of R1 and see how to reach R5’s loopback:

OSPF-CONN-04

As can be seen in the above output, the routing table shows the routes belonging to area 24 as “O IA” meaning inter-area routing.  The intra-area routes of Area 0 are shown as “O”.   Another important thing to denote is the actual route to the loopback 0 of R5.    As you can see, the metric to reach 5.5.5.5 is 85 from R5.   This is because the metric is additive in this case.  It is the sum of the cost to reach the loopback of R5 from R1.  (R1—10—R2—64—R4—10—R5—1—Lo0 = 85).   The route describes the next hop:  “192.168.12.2, from 0.0.0.2”, which is the next-hop IP address and the Router-ID of R2.  R2 is the advertising the route on behalf of R5, not an IP address.

Now let’s take a look at R2’s information for the same route.

OSPF-CONN-05

Note the difference between the above output and the previous one.  Here we can see the route to 5.5.5.5 shown as “O” intra-area.   This is because R2 has the interface Serial1/0 in area 24; this makes the route internal for it.     From R2, the metric has also decreased to 75.  The route describes the next hop:  “192.168.24.4, from 0.0.0.5”, which is the next-hop IP address of R4 and the Router-ID of R5 which is advertising router.

Let’s take a look at R4’s information for the same route.

OSPF-CONN-06

As can be seen in the above output, the routing table shows the routes belonging to area 0 as “O IA” meaning inter-area routing.  The route to 5.5.5.5 is an intra-area route OSPF.  As expected, the metric has decreased to 11.  The route describes the next hop: “192.168.45.5, from 0.0.0.5”, which is the next-hop IP and the Router-ID of R5.

Finally in R5, ospf advertise the loopback 0 with Cost of 1.

OSPF-CONN-07

ABRs also create and flood Type-4 (ASBR Summary) LSAs when an ASBR is present.  This LSA is used to let other areas know where the ASBR is.

Autonomous System Boundary Router

ASBRs are routers injecting routes from another routing protocol or autonomous system.  The injection is done via Redistribution.   ABRs generate and flood Type-5 LSAs.

To inject routes into the OSPF domain, use the redistribute {connected|static|protocol}{metric <0-16777214>} {metric-type <1|2>} {subnets} {route-map} {tag <0-4294967295>} OSPF process command.

  • The {connected|static|protocol} statement is self-explanatory. It defines the source of the routes to be redistributed.
  • The {metric} keyword set the Cost of the route to be advertised. If the metric is not specified, OSPF will use a default value of 20 when redistributing routes from all IGPs.  When redistributing from BGP, the metric will be 1 by default.
  • The {metric-type} keyword forces the routes to be advertised as External Type 1 or Type 2. By default, Type 2 is used.   For more information about the route Types and LSA Types, please see the post OSPF LSA Flooding Scope.
  • The {subnets} keyword is required when redistributing subnetted networks. Without this keyword, only major networks will be redistributed.
  • The {route-map} keyword is an enhancement to the redistribution process. It allows using different policies for redistribution.
  • The {tag} keyword as its name implies, set a numeric tag value to the routes to be redistributed. This is widely used to control redistribution between protocols.

More on {route-maps} and {tags} in future posts.

For example, let’s use the same topology but we will configure R3 as ASBR:

OSPF-CONN-ABR-ASBR

In R3 we will make the following changes:

First, we will add two loopback interfaces and configure RIP:

!
interface Loopback10
ip address 10.10.10.10 255.255.255.0
!
interface Loopback20
ip address 20.20.20.20 255.255.255.0
!
router rip
version 2
network 10.0.0.0
network 20.0.0.0
no auto-summary
!

Finally, we will redistribute RIP into OSPF:

 

!
router ospf 1
redistribute rip metric 200 subnets
!

After redistribution was configured, R3 advertise itself as ASBR by setting the “E” bit in its type 1 LSA.

OSPF-CONN-07-1

The above output displays the self-originated Type-1 (Router) LSA with the “E” bit set.  This is the ASBR in the current topology.   Another way to identify ASBRs is using the command show ip ospf border-routers.

OSPF-CONN-07-2

Now let’s take a look at the link-state Database of R1 and its routing table.

OSPF-CONN-08

OSPF-CONN-09

As can be seen in the above output, R1 only has Type-1, Type2, Type-3 and Type-5 LSAs in their databases.  R1 and R3 have identical link-state Databases.  The routes to reach the RIP routes are “O E2” OSPF external routes Type 2.

Now, R2 is an ABR and contains identical database information as R1 and R3 for area 0.  R2 also has a database for area 24.

OSPF-CONN-10

The database of R2 for Area 24 contains Type-1, Type-2, Type-3, Type-4 and Type-5 LSAs.  As mentioned before, Type-4 LSAs are used to inform other areas where the ASBR is located.  It is used basically to provide reachability information for the ASBR.

R4 and R5 are internal routers of Area 24; they share the same database information.  For brevity, let’s focus in R5.

OSPF-CONN-11

OSPF-CONN-12

As expected, the link-state Database contains Type-1, Type-2, Type-3, Type-4 and Type-5 LSAs and the routing table show the routes as “O E2” OSPF External routes type 2.

Finally, let’s try to reach the IP address 10.10.10.10 from R5.

Let’s get started looking for the route itself:

OSPF-CONN-13

As you can see, the route is known by OSPF, the reported metric of the route is 200.  We have defined this metric when redistributing the route.  The route is External Type-2.  This is the advertised cost from the ASBR to the external destination network.   The forward metric is 84.   This metric is the total cost to the ASBR from R5.

The route describes the next hop: “192.168.45.4, from 0.0.0.3”, which is the IP address of R4 and the Router-ID of the advertising router R3 (ASBR).

Now let’s check R4 and R2:

OSPF-CONN-14

OSPF-CONN-15

As can be seen in the above outputs, the only change is metric and the next-hop to reach the advertising router.

OSPF-CONN-16

The advertising router remains the same because the forwarding address in the Type-5 LSA is set to 0.0.0.0 (null).   This means that the route is reachable only via the advertising router.

It is time to close this long post. Thank you for visiting.