Nokia (Alcatel-Lucent) OSPF configuration tutorial

The purpose of this post is to cover basic OSPF configuration steps and commands. Intended readers are engineers with basic OSPF knowledge who want to know how to configure OSPF on Alcatel-Lucent Service Routers (7750-SR, 7705-SR, 7210-SR). All the examples are valid for TiMOS-B-12.0.R8 both/i386 ALCATEL SR 7750 Copyright (c) 2000-2015 Alcatel-Lucent.  software.

Single-area OSPF

Basic OSPF protocol configuration in a single area consists of the next steps:

  • Enable OSPF globally
  • Configure router with OSPF Router ID
  • Configure backbone OSPF Area 0
  • Include interfaces in Area 0

I will guide you through basic OSPF configuration steps referring to this topology:

Enabling OSPF and Router ID

To enable OSPF on a router simply issue  configure router ospf command. This will start OSPF process #0 on a router. If you would like to run another separate OSPF process on the same router, use  configure router ospf <N> , where <N> is a decimal number of the OSPF process.

To operate properly OSPF routers should have unique Router ID, which is a 32-bit identifier. Router ID selection process goes like this (in priority order):

  • configured globally for a router  router-id  value
  • configured system interface IPv4 address value
  • the last 32 bits of the chassis MAC address
To check Router ID currently value in use and OSPF admin/oper status issue the command  show router ospf status

Configuring Backbone Area

To configure OSPF area you should use command  area in OSPF configuration context:

Area ID value could be entered as decimal, like area 0  or in dotted-decimal format like area

It is common practice to use one composite command to enable OSPF process and to configure OSPF area instead of two separate commands:

To check all the configured areas on a router use  show router ospf area

Configuring OSPF interfaces

Once backbone area is configured its time to add some interfaces to it with interface <interface_name> command.

To check that OSPF interfaces was configured properly and are operating use this show command:

Repeat the same configuration steps by including all the interfaces to OSPF Area 0 to the other backbone routers R2-R3-R4 and you will end up with fully configured OSPF Backbone Area. Finally its time to check that our routers established neighboring relationships:

One of the most used OSPF verification commands is show router ospf database . This command shows all the Links State Advertisements (LSA)  and helps the engineer to troubleshoot OSPF-related issues.

Multi-area OSPF

Basic Multi-area OSPF configuration is straightforward as well. I added two more routers to previous topology acting as core routers in two new areas: Area 1 and Area 2.

sorry fellows, I mistyped port numbers for R5-R1 and R6-R2 pairs, it should be 1/1/4. Though this wont affect the course of this topic in anyway


We will start by configuring Area 1 on routers R5 and R1. Every command is from the previous section, so you wouldn’t face any problems.

Adding one more Area (besides backbone Area 0) on R1 makes it Area Border Router. So R1 will form and maintain another neighbor relationships with R5 in Area 1. We will check if its true:

I repeated same configuration steps on R6: added it to Area 2 and neighbored with R2.

Examining Multi-area LSDB

Since we configured multi-area OSPF we should expect to see some new LSA in our Link State Database:

Aha, R1 as being an ABR lists all LSA’s for both Area 0 and Area 1. Moreover, R1 lists Type 3 Summary LSA from Area 0 to Area 1 and vice versa, from Area 1 to Area 0. 

R5 has only Area 1’s LSA’s, since R5 lives in just one Area – Area 1.

Verifying OSPF routes propagation

To ensure that OSPF routes was transferred between OSPF lets check it by issuing a set of commands on both R5 and R1:

Since we configured all routers in our topology we can try to run ping between R6 and R5:

OSPF Route Summarization

So far we configured multi-area OSPF topology with three Areas. And one of the reasons to implement multi-area OSPF topology is the ability to perform manual summarization. In this section we will configure OSPF route summarization between Area 0 and Area 1.

To get a range of IP addresses which we will summarize later we will add 3 loopback interfaces to R3 router and include them in OSPF Area 0:

Since we added these interfaces to OSPF we see them coming to R5 router as Type 3 Network Summary LSA. And these routes make their way to routing table.

We will configure route summarization on Area Border Router (R1), so it will advertise only one summary route  instead of three specific routes.

Configuration steps:

Pay attention, that summarization command area-range must be applied in the context of the area being summarized. Since we are summarizing routes from area 0 to area 1 then we using this command in area 0 configuration context. By default, adding command  area-range <prefix>/<length> will actually place command  area-range <prefix>/<length> advertise in the configuration, meaning that ABR will advertise this prefix. Counterpart statement  not-advertise is used for route suppression and will be discussed in a detail in next section.

Pay attention: route summarization procedure automatically places black-hole route in R1’s route-table.

Lets see what has changed at R5. R5’s LSDB now has just one Type 3 Summary LSA regarding network  and has no LSA’s for specific networks:

Verifying that IP connectivity works for summarized route:

OSPF Route filtering on ABR

You can filter unwanted routes on ABR’s with the same command area-range adding the key  not-advertise.

For example lets take a look at R6’s route table which contains specific routes to R3’s loopback addresses. These addresses is advertising by R2 since it is acting as ABR and advertises all the routes it has in its routing table.

If we want to prevent R2 from advertising some routes to its neighbor in Area 1 then we have to make configuration steps in Area 0 context since we filter Area 0 routes:

By doing this, we tell R2 to stop advertising Type 3 Summary LSA for prefix . And R6’s route table immediately reflects this change by missing this specific route :

You can also use “summary” prefix to filter a range of routes:

Note: Route filtering does not install any black-hole routes.

ASBR’s and OSPF Route Redistribution

Routes between different routing domains can me mutually exchanged. External routers can be exported into OSPF and vice versa. The process of routes exchange is often called route redistribution.

In this section we will redistribute routes added by means of loopback interfaces created on R5. These routes are in R5’s route table but are not advertising to OSPF neighbor, since these interfaces are not included in OSPF process.

To redistribute these local routes to OSPF process a policy should be configured. Lets configure policy with a name  EXPORT Local Loopbacks:

The next step is to configure R5 as an ASBR router and to apply created policy to OSPF process:

Verifying redistributed routes propagation

Now these routes get exported to OSPF process on R5. Moreover, R5 is now configured as ASBR. These changes allow other routers in OSPF domain to receive these routes via Type 4 ASBR Summary LSA and Type 5 AS External LSA:

OSPF Stub Area

Stub areas are widely used since they help to optimize LSDB and routing tables of the routers. We will configure Area 2 as stub, this will tell ABR (R2) to not distribute any External routes and send a default route instead into Area 2. To configure Area 2 as stub you need to configure all OSPF routers inside this area:

This “before | after” comparison shows that after configuring Area 2’s routers as stub R6 router no longer receives ASBR Summary LSA and AS External LSA nor it has routes Instead it has a new Summary LSA from ABR with the Link State ID which means default route.

OSPF Totally Stub Area

ABR router participating in a Totally stub area blocks not only Type 4 ASBR Summary and Type 5 AS External LSA but also Type 3 Summary LSA. This drastically reduces LSDB and route tables on Area 2 routers. As of this moment we have Area 2 configured as stub area, lets configure it to be totally stub. To make Area 2 totally stub we need to configure just ABR (R2) with keyword no summaries

Take a look at R6’s LSDB and route table

Now Area 2 router R6 has only 3 LSA in its LSDB. All Type 3 Summary LSA for networks inside Area 0 was substituted by Summary default route from ABR (R2).

Not So Stabby Area (NSSA)

There is a typo on the pic. No type4 lsa will be advertised in Area0 by R1. Only Type5

Not so stabby areas are basically stub areas with ASBR. It inherits the same rule of blocking Type 4 and Type 5 LSA and in order to distribute external routes from ASBR another LSA – Type 7 – is used.

We will configure Area 1 to be NSSA by adding commands to R1 (ABR) at first:

As soon we configured Area 1 on R5 to be NSSA we lost R1 as neighbor. This is the effect of mismatched Area type in OSPF Hello messages between two routers. Recall that R1 is maintaining Area 1 as a basic area, and Area 1 on R5 was reconfigured to NSSA.

We will fix neighboring by moving R1’s Area 1 to NSSA operation as well:

Now when R1 and R5 are neighbors again lets see what has changed:

As we see, all Type 5 AS External LSA was substituted by Type 7 NSSA LSA. And if we had any other external routes we wouldnt see them in R5 database, since NSSA areas can not contain External routes.

Totally NSSA

There is a typo on the pic. No type4 lsa will be advertised in Area0 by R1. Only Type5

As with totally stubby areas, NSSA could be configured in a way that no Type 3 Summary LSA will present in such area. Totally NSSA configuration adds two additional commands on ABR:

ABR configured with Totally NSSA area filter Type 3 LSA as totally stubby area does. But notice one major difference – there is no default route injected by ABR! This is the cause of ping failure to any Area 0  address:

To resolve this issue you should add another command to NSSA context:

This will cause R1 to inject Type 3 Summary LSA in Area 1:

Debugging OSPF adjacency issues

For two OSPF routers to become neighbors several parameters should be matched. And most of them – are the parametes communicated via OSPF Hello messages. If you do not see the a neighbor on the other side – there is a good chance that one of these parameters mismatch.

When you need to investigate what is the reason casing a neighboring relationships to break down debug should help. I will show you some debug commands to help you understand how to troubleshoot OSPF Hello mismatched parameters.

For some reason R1 lost its neighbor R5 in Area 1:

To see what is going wrong, lets create logging instance and capture Hello packets to analyze their content:

Now we have log and debug configured, we could see log contents:

Now the problem is clear – incoming OSPF packet came in with Hello timer set to 5sec. And R1 tells us that this value mismatches its configured Hello timer value.

This debug technique should indicate every discrepancy in OSPF values that should match, be it authentication mismatch or area id mismatch.

And that is all for this moment. Should you have any questions – do not hesitate, comment form is down below!

noshut# exit all

Roman Dodin

Network engineer at Nokia
Eagerness to learn multiplied by passion to share.
You can reach me at LinkedIn

You Might Also Like

  • Pingback: OSPF. Neighbors on a “point-to-broadcast” network | Networking in a Service Provider way()

  • nani

    Hello .. Thanks for writing wonderful article..
    Can we use aggregate routes with OSPF, for eg on ASBR, can I write an aggregate summary-only and redistribute it into OSPF with export policy.
    It does work but I see both aggregate route and also specific routes via OSPF.
    Am I missing something ?

  • Arif Mohammad

    Thanks for this post.

    • Roman Dodin

      You are welcome, Arif!