Month: January 2016

OSPF Authentication Enhancements

Today we will discuss the enhancements made in OSPF authentication. As mentioned in a previous post, now is possible the use of SHA encryption with OSPF as described in RFC 5709.

There are two major enhancements described in the RFC:

OSPF SHA Cryptographic Authentication
OSPF Key Chain Based Authentication

Despite the improvements, the RFC does not define a new Authentication Type. OSPF still use the typical Type-0 (Null), Type-1 (Simple Password) and Type-2 (Cryptographic) authentications. However defines new Cryptographic Algorithms for Type-2:

HMAC-SHA-1
HMAC-SHA-256
HMAC-SHA-384
HMAC-SHA-512

Using key chains allows for multiple enhancements for the Authentication such:

Multiple keys can be defined.
A single key chain can be used for multiple interfaces.
Allow automatic time-based key rotation.

I should also mention that key chains are backwards compatible with the interface level Type 2 (MD5) authentication and the rule of key number and password must match between routers still applies.

In order to use the OSPF authentication enhancements described above, Only two steps are required:

Configure the Key Chain.
Associate the Key Chain to an interface.

Key Chain Configuration

To configure key chains the following steps must be followed:

Define the key chain name to be used.

key chain {key chain-name}

Configure a key identifier.

key {0-2147483647}

Configure the password to be used.

key-string {password}

Configure the Cryptographic Algorithm to be used.

cryptographic-algorithm {crypto-algorithm}

(OPTIONAL) Time Interval. This is used for key chain rotation.

accept-lifetime {start-time} {start-date} {end-time} {end-date | infinite}

send-lifetime {start-time} {start-date} {end-time} {end-date | infinite}

Key-chain configuration example:

!
key chain testkey1
key 1
key-string cisco123
cryptographic-algorithm hmac-sha-1
end
!

In this example the key chain testkey1 was configured in the router with a single key (1), with password cisco123 and the Cryptographic Algorithm selected was HMAC-SHA-1. The key is valid immediately and has no expiration.

Key-chain configuration example with time-based key rotation:

!
key chain testkey2
key 1
key-string cisco123
cryptographic-algorithm hmac-sha-1
accept-lifetime 00:00:00 Jan 1 2016 00:15:00 Jun 1 2016
send-lifetime 00:00:00 Jan 1 2016 00:00:00 Jun 1 2016
key 2
key-string cisco321
cryptographic-algorithm hmac-sha-1
accept-lifetime 23:45:00 May 31 2016 infinite
send-lifetime 00:00:00 Jun 1 2016 infinite
end
!

In this example, the router will accept key 1 with password cisco123, until 12:15 AM on June 1, 2016. The router will send this same key until 12:00 AM on the same date (June 1, 2016). Also, the router will start accepting key 2 with password cisco321, at 11:45 PM on May 31, 2016. Worth to mention key chain rotation depends on accurate time and date on the devices.

To verify the key chain, use the show key chain {keychain-name} command.

OSPF-AUTH-KeyChain-Simple

OSPF-AUTH-KeyChain-Rotation

Key Chain Association

This is the final step of the configuration. To associate the Key Chain to the interface, use the command ip ospf authentication key-chain {key chain-name}. Remember, a single key chain can be used for multiple interfaces.

!
interface Ethernet0/0
ip ospf authentication key-chain mykey
!

OSPF Enhanced Authentication configuration Example:

For this example I will use the following scenario:

The network is currently doing authentication using MD5 Encryption (Type 2) between R1 and R3 and the authentication used for R1, R2 and R3 are Simple Passwords (Type-1).

A new change was requested by the Information Security team to increase the level of encryption along the network as follows:

For the segment between R1, R2 and R4 use SHA-1 with password cisco421
For the segment between R1 and R3 use SHA-256 with password cisco31
The DUE date to complete the change is Jun 1, 2016

So let’s do it!

First let’s take a quick look only to the relevant configuration:

R1:

!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface Ethernet0/0
ip address 192.168.124.1 255.255.255.0
ip ospf authentication-key cisco124
!
interface Ethernet0/1
ip address 192.168.13.1 255.255.255.252
ip ospf authentication message-digest
ip ospf message-digest-key 1 md5 cisco13
ip ospf network point-to-point
!
router ospf 1
router-id 0.0.0.1
area 0 authentication
network 1.1.1.1 0.0.0.0 area 0
network 192.168.13.1 0.0.0.0 area 0
network 192.168.124.0 0.0.0.255 area 0
!
ntp master 1
!

R2:

!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
interface Ethernet0/0
ip address 192.168.124.2 255.255.255.0
ip ospf authentication
ip ospf authentication-key cisco124
!
interface Ethernet0/1
ip address 172.16.20.2 255.255.255.0
!
router ospf 1
router-id 0.0.0.2
network 2.2.2.2 0.0.0.0 area 0
network 172.16.20.0 0.0.0.255 area 0
network 192.168.0.0 0.0.255.255 area 0
!
ntp server 192.168.124.1
!

R3:

!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
interface Ethernet0/0
ip address 192.168.13.2 255.255.255.0
ip ospf authentication message-digest
ip ospf message-digest-key 1 md5 cisco13
ip ospf network point-to-point
!
interface Ethernet0/1
ip address 172.16.30.3 255.255.255.0
!
router ospf 1
router-id 0.0.0.3
network 3.3.3.3 0.0.0.0 area 0
network 172.16.30.0 0.0.0.255 area 0
network 192.168.13.2 0.0.0.0 area 0
!
ntp server 192.168.13.1
!

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.124.4 255.255.255.0
ip ospf authentication
ip ospf authentication-key cisco124
ip ospf 1 area 0
!
interface Ethernet0/1
ip address 172.16.40.4 255.255.255.0
ip ospf 1 area 0
!
router ospf 1
router-id 0.0.0.4
!
ntp server 192.168.124.1
!

In the above output we can see that R1 has a simple password authentication configured directly to the area, while the crypto authentication is applied directly to the interface that connects to R3.

The other routers have configured the authentication parameters directly on the interface. Please also note R1 is acting as Clock Server for all routers in the network.

After checking the clock in all routers, we have determined that a possible solution is implementing extended authentication with rotary passwords for the segment between R3 and R1. Using this solution, we can switch the crypto algorithm without loose connectivity.

Unfortunately we cannot use the same solution for routers 1, 2 and 4. The reason is because Enhanced Authentication is intended only for Type-2 Authentications.

First let’s configure the key chain to be used for the link between R3 and R1 using rotary passwords.

!
key chain R3-TO-R1
key 1
key-string cisco13
cryptographic-algorithm md5
accept-lifetime 00:00:00 Jan 1 2016 00:15:00 Jun 1 2016
send-lifetime 00:00:00 Jan 1 2016 00:00:00 Jun 1 2016
key 2
key-string cisco31
cryptographic-algorithm hmac-sha-256
accept-lifetime 23:45:00 May 31 2016 infinite
send-lifetime 00:00:00 Jun 1 2016 infinite
end
!

The above key chain meets the requirements. It will maintain the connectivity using the current MD5 encryption algorithm until 15 minutes after midnight in June 1 (Key 1) and will also start accepting SHA-256 from May 31 at 23:45 hours (Key 2).

We can use the same key chain in both routers, R3 and R1. Lastly we have to assign the key chain to the interface connecting both routers.

R3:

!
interface Ethernet0/0
ip ospf authentication key-chain R3-TO-R1
!

R1:

!
interface Ethernet0/1
ip ospf authentication key-chain R3-TO-R1
!

Now let’s verify the results of this configuration:

OSPF-AUTH-1

OSPF-AUTH-2

As can be seen in the above output, the current valid key is Key 1, with the current authentication. The interface output shows the key chain (R3-TO-R1) association.

Now let’s configure the authentication settings for the segment between R1, R2 and R4.

!
key chain R1-R2-R4
key 1
key-string cisco421
cryptographic-algorithm hmac-sha-1
end
!

As can be seen in the above configuration, the key chain was created with key 1 for SHA-1 with the password cisco421. By default the key chain will set the “accept” and “send” lifetime as always valid if is not manually set.

OSPF-AUTH-3

All three, routers, R1, R2 and R3 are connected to the segment 192.168.124.0/24 using the interface Ethernet0/0. The final step would be applying the same key chain in all three routers and enable the key chain to the interface Ethernet0/0. Remember, in this case when moving from Type 1 to Enhanced Type 2 authentications, the change may be disruptive. You have 40 seconds (OSPF default dead timer) before the router declare its neighbors down.

So finally let’s associate the interface to the routers 1, 2 and 4:

!
interface Ethernet0/0
ip ospf authentication key-chain R1-R2-R4
!

Let’s take a look to the output of show ip ospf interface Ethernet0/0 and Ethernet 0/1 in R1:

OSPF-AUTH-4

OSPF-AUTH-5

R1 as shown above is now doing authentication SHA-1 in the interface Ethernet0/0 as requested. The interface Ethernet0/1 connecting with R3 is still doing Authentication MD5.

Finally let’s test the configuration with rotary authentication. For this purpose I’ll manually set the clock to 23:46:00 May 31 2016 and will check the interface status in R3 and R1.

OSPF-AUTH-6

OSPF-AUTH-7

As can be seen in the above output, the interface Ethernet0/1 in R1 and the interface Ethernet0/0 in R3 have changed to Authentication HMAC-SHA-256. In this case the change was automatic due the automatic time-based key rotation feature.

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

OSPF Null Authentication

In the previous post (OSPF Authentication), we have learned how to configure and troubleshoot OSPF Authentication. However, we only focused on Authentications Type 1 and Type 2.

So you may be wondering: what about Type 0 or Null Authentication? What is it for?

Well, this type of authentication is typically used in links where authentication is not required. Let me explain. If your organization is using OSPF authentication in an Area and you try to form an adjacency with another device where authentication is not configured or desired, there is where OSPF Null Authentication enters to play.

To configure OSPF Null Authentication use the interface level command: ip ospf authentication null.

For example, let’s take a look to the following topology:

OSPF-NULL-A-Topology

In this scenario R1, R2 and R4 have configured OSPF authentication using Cryptography (Authentication Type 2). R3 was recently added to the network; however the adjacency with R1 is not established.

First, let’s debug the ospf adjacencies and try to find what the problem is.

OSPF-Null-Debug-R1

OSPF-Null-Debug-R3

As you can see in the above output, the problem is mismatch authentication types between the peers.

R1 is using Type 2 (Crypto) and R3 is using Type 0 (null).

Now let’s take a look at the configuration of R1 and R3:

OSPF-NULL-R1-TO-R3

R1:

!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface Ethernet0/0
ip address 192.168.124.1 255.255.255.0
ip ospf message-digest-key 1 md5 cisco124
!
interface Ethernet0/1
ip address 192.168.13.1 255.255.255.252
ip ospf network point-to-point
!
router ospf 1
router-id 0.0.0.1
area 0 authentication message-digest
network 1.1.1.1 0.0.0.0 area 0
network 192.168.13.1 0.0.0.0 area 0
network 192.168.124.0 0.0.0.255 area 0
!

As shown in the configuration above, R1 was configured to authenticate all devices connected to area 0 with the command area 0 authentication message-digest. This will be equivalent to adding the command ip ospf authentication message-digest to all interfaces connecting to Area 0.

A way to verify this statement is by using the command show ip ospf interface {interface-id}.

OSPF-NULL-show-ospf-if-e0-0

OSPF-NULL-show-ospf-if-e0-1

R3:

!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
interface Ethernet0/0
ip address 192.168.13.2 255.255.255.0
ip ospf network point-to-point
!
interface Ethernet0/1
ip address 172.16.30.3 255.255.255.0
!
router ospf 1
router-id 0.0.0.3
passive-interface default
no passive-interface Ethernet0/0
network 3.3.3.3 0.0.0.0 area 0
network 172.16.30.0 0.0.0.255 area 0
network 192.168.13.2 0.0.0.0 area 0
!

As shown in the configuration above, R3 do not have OSPF authentication configured.

To solve this issue, just configure OSPF null authentication to the interface in R1 connecting to R3:

!
interface ethernet0/1
ip ospf authentication null
end
!

After the above configuration was applied, the peers R1 and R3 will form adjacency:

OSPF-NULL-Solution-Neighbors

Let’s take a look at the result of the configuration in the interface:

OSPF-NULL-Solution-e-0-1

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

OSPF Authentication

In the last post (OSPF Passive Interface), I have mentioned that enabling routing everywhere may increase the chances of the insertion of unauthorized devices. What I mean by this is when we enable OSPF within the interface or using the network command in the OSPF process, we also allow automatic neighbor discovery and adjacency forming in certain network types such broadcast networks. Using passive-interface in OSPF we make sure no hello packets are sent in stub networks; thus, adjacencies won’t form in these network segments. But what about the routers placed in transit networks? How can we protect them without disabling the Hello packets?

Well, in this case, what we can do its force the routers to authenticate in order to establish the adjacencies.

OSPF Authentication Types:

Three types of authentications are currently supported by OSPF:

Type 0 – Null – Is the default and means that there is no authentication and is typically used in links where authentication is not required.
Type 1 – Simple Password – In this type of authentication, the passwords are exchanged in plaintext (very insecure).
Type 2 – Cryptographic – In this type of authentication, the password is encrypted using MD5. (Now is possible the use of SHA encryption with OSPF in new IOS versions. This will be discussed in the following post)

OSPF Authentication Configuration:

OSPF authentication is a 2 step configuration; the first step is enabling the type of authentication to be used. It can be enabled at the Process level or at the Link level. By default, the link level authentication overrides the process level authentication.

To enable OSPF authentication at the process level, use the area {area-id} authentication command for Simple Password authentication; adding the keyword message-digest changes the authentication to Cryptographic type 2 (MD5).

To enable OSPF authentication at the interface level use the ip ospf authentication command for Simple Password authentication; adding the keyword message-digest changes the authentication to Cryptographic type 2 (MD5).

To configure OSPF null authentication to a link connecting to a neighbor, use the ip ospf authentication null command. As mentioned before, null authentication is typically used in links where other types of authentication are been used but is not required in a particular link. More details and examples in the next post.

The second step is to define the password to be used either plaintext or encrypted. The authentication passwords are always configured on the link.

To configure the authentication passwords in plaintext use the interface command ip ospf authentication-key {0|7} {password}.

The option 0 or 7 inside the curly brackets means the user is entering the password in plain text (option 0) while the option 7 means the user is entering an already encrypted Cisco proprietary Type-7 password. The option 0 is the default and is not required to be set.

To configure the authentication passwords as Type 2 (MD5) use the interface command ip ospf message-digest-key {key-number [1-255]} md5 {0|7} {password}.

Type 2 authentication supports up to 255 different keys. The key number and password must match between the routers. Using different keys allow for quick changes of passwords and to use multiple passwords per area.

OSPF Authentication Configuration for Virtual-Links:

A Virtual Link is an OSPF tunnel, a multi-hop point-to-point unicast adjacency; it is, in essence, an extension of Area 0 across (transit area) another area. When configured a P2P logical interface is created with state P2P and attached to Area 0. The Virtual-Link configuration follows the same rules described before. Requires define the authentication Type which can be defined in the area or over the virtual-link definition and the password. Because the logical interface VL is created when the virtual link is defined in the process, it also has to be defined within the virtual link configuration in the process. Use the following combinations to configure the Virtual-Link Authentication:

Simple password configuration:

area {area-id} virtual-link {router-id} authentication authentication-key {password}

Cryptographic configuration:

area {area-id} virtual-link {router-id} authentication message-digest message-digest-key {key-number [1-255]} md5 {0|7} {password}.

OSPF Authentication Configuration Examples:

For this set of examples, we will use the topology we have been using so far.

Initial Configurations:

R1:

!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface Ethernet0/0
ip address 192.168.124.1 255.255.255.0
!
interface Ethernet0/1
ip address 192.168.13.1 255.255.255.0
!
router ospf 1
router-id 0.0.0.1
network 1.1.1.1 0.0.0.0 area 0
network 192.168.0.0 0.0.255.255 area 0
passive-interface default
no passive-interface Ethernet0/0
no passive-interface Ethernet0/1
!

R2:

!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
interface Ethernet0/0
ip address 192.168.124.2 255.255.255.0
!
interface Ethernet0/1
ip address 172.16.20.2 255.255.255.0
!
router ospf 1
router-id 0.0.0.2
network 2.2.2.2 0.0.0.0 area 0
network 172.16.20.0 0.0.0.255 area 0
network 192.168.0.0 0.0.255.255 area 0
passive-interface default
no passive-interface Ethernet0/0
!

R3:

!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
interface Ethernet0/0
ip address 192.168.13.3 255.255.255.0
!
interface Ethernet0/1
ip address 172.16.30.3 255.255.255.0
!
router ospf 1
network 3.3.3.3 0.0.0.0 area 0
network 172.16.30.0 0.0.0.255 area 0
network 192.168.13.0 0.0.0.255 area 0
passive-interface default
no passive-interface Ethernet0/0
!

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.124.4 255.255.255.0
ip ospf 1 area 0
!
interface Ethernet0/1
ip address 172.16.40.4 255.255.255.0
ip ospf 1 area 0
!
router ospf 1
router-id 0.0.0.4
passive-interface default
no passive-interface Ethernet0/0
!

The Switch interfaces where the routers are connected were configured as follows:

!
interface FastEthernet0/[1-4]
switchport trunk encapsulation dot1q
switchport mode trunk
!

Task 1:

Let’s start applying Simple Password Authentication (Type-2) to the segment between R1 and R3 with the password cisco123. R1 must use interface level authentication and R3 must use Area authentication.

R1:

OSPF-Auth-Task-1-1

R3:

OSPF-Auth-Task-1-2

An interesting thing to mention is that all OSPF packets are authenticated.

Let’s take a look to the different OSPF packets:

Hello Packet Header:

OSPF-Hello-Packet

Link-State Database Description (LSDB) Header:

OSPF-LSDB-Packet

Link-State Request:

OSPF-LSR-Packet

Link-State Update:

OSPF-LSU-Packet

Link-State Acknowledge:

OSPF-LSA-Packet

As you can see in the above examples, the Authentication Type is Simple password (1) and the password (cisco123) is shown in plain text format.

OSPF authentication doesn’t mean Encryption, meaning that the content of the packet is perfectly readable. The objective of OSPF Authentication is only to protect the Router control plain avoiding the insertion of unauthorized routes injected by unauthorized devices.

Task 2:

For this task, let’s apply Cryptographic Password Authentication (Type 2) to the network segment between R1, R2, and R4 with the password cisco124. R1 must use Area authentication while R2 and R4 must use interface level authentication.

R1:

OSPF-Auth-Task-2-1

R2:

OSPF-Auth-Task-2-2

R4:

OSPF-Auth-Task-2-3

Let’s take a look at the Hello packet of R1 in the interface E0/0:

OSPF-Hello-Packet-Task-2

As you can see in the output the Authentication Type now is Cryptographic (2). You will also find the Key ID used to authenticate, the sequence number and the encrypted password contained in the Auth Crypt Data field. Using sequence numbers prevents replay attacks where the OSPF packets are captured, modified and retransmitted to the router.

In this case, we use the same password because is a shared segment, however in other network types such point-to-point, different passwords can be used.

OSPF Authentication Verification and Troubleshooting:

In order to verify the authentication use the show ip ospf interface {interface-id} command.

show-ip-ospf-if

The above output displays the type of authentication used and the key id used to authenticate in the interface Ethernet0/0 for the segment 192.168.124.0/24 where R1, R2, and R4 reside. Then the same output displays the type of authentication used, in this case, Simple password for the segment 192.168.13.0/24 where R1 and R3 connects.

Another way to verify if the authentication succeeds is by checking the neighbor table using the show ip ospf neighbor command. When the authentication fails, it will remove the neighbor from the table.

In order to demonstrate the troubleshooting process, I’ve made the some changes (misconfigurations I would say) to the routers previously configured.

The problem:

After OSPF Authentication was configured in the routers, the connectivity to the segments 172.16.30.0/24 and 172.16.40.0/24 has been lost.

OSPF-SAREA-NTOPOLOGY

debug-04

After confirming the adjacencies to R3 and R4 were lost, we can troubleshoot the adjacencies using the debug ip ospf adj command. To turn off the debug use the command: undebug all.

debug-MSG

Aha! Seem that we have found the problems. The debug output showed above give us details about the issue:

The first problem found: The router has received in the interface Ethernet0/1 a packet with mismatched Authentication Type. The received packet is using Simple Password Authentication (Type 1), but the local router is using Cryptographic Authentication (Type 3).

This was an easy catch; the solution will be enabling Simple Password (Type 1) authentication in the interface Ethernet0/1 of R1.

R1#config t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#interface e0/1
R1(config-if)#ip ospf authentication
R1(config-if)#ip ospf authentication-key cisco123
R1(config-if)#no ip ospf message-digest-key 1 md5 cisco123
R1(config-if)#end
R1#

The other problem: The router has received in the interface Ethernet0/0 a packet with Mismatched Authentication Key – ID 1. This debug message is self-explanatory. The password received in the interface doesn’t match with the local one.

Let’s compare the configurations:

Wait a minute! At first sight, the passwords look identical. But are they actually identical?

Well, in this problem I have introduced a common problem when configuring passwords. I have added a blank space at the end of the password in R4. Blank spaces also count as part of passwords.

debug-03

The solution in this case is remove the MD5 key 1 and re-enter it. You can also copy the line from R1 or R2 and paste it into the interface Ethernet0/0 configuration.

It is time to close this post.

Thank you for visiting.

OSPF Passive Interface

When we advertise networks in OSPF using the process command network {ip-address} {wildcard-mask} area {area-id} or using the interface command ip ospf {process-id} area {area-id}, the selected network is not just advertised in OSPF, the corresponding interface will also try to form adjacencies in its network segment. This is a normal behavior; however enabling routing everywhere may increase the chances of the insertion of unauthorized devices. Another consideration is the possibility of an attack where an attacker could advertise fake routes to the OSPF domain and black hole traffic or even worst like crashing the router.

The following example may illustrate the problem:

OSPF-PassiveIF

First, let’s take a look at the segment 172.16.20.0/24 which corresponds to a group of users. The interface ethernet0/1 of R2 connects to a Layer-2 switch to provide connectivity to the users. No other router is connected to the segment.

R2 Configuration:

!
interface ethernet0/0
ip address 192.168.124.2 255.255.255.0
!
interface ethernet0/1
ip address 172.16.20.2 255.255.255.0
!
interface loopback0
ip address 2.2.2.2 255.255.255.255
!
router ospf 1
router-id 0.0.0.2
network 2.2.2.2 0.0.0.0 area 0
network 172.16.20.0 0.0.0.255 area 0
network 192.168.0.0 0.0.255.255 area 0
!

The above configuration enables OSPF in all 3 interfaces. The interface ethernet0/0 and 0/1 are by default OSPF network type BROADCAST. Therefore, by default both interfaces will try to form adjacencies. Let’s take a look at the interfaces and neighbor status.

OSPF-IF

For the interface ethernet0/0 it is ok because it belongs to a transit network which connects to other routers in the same segment (R1 and R4).

OSPF-IF-e-0-0

However, the interface ethernet0/1 connects to a stub network. This network is intended for user computers only and does not require adjacency forming capabilities. In other words, it is not required sending hello packets over this interface.

OSPF-IF-e-0-1

The above output shows the details of the OSPF process for the interface Ethernet0/1, as you can see the output is similar to the one for interface Ethernet0/0. This interface is also sending Hello packets with its default settings. With the configuration like this, an attacker connected to the switch could use software such as Loki to insert routes to OSPF domain. (You can watch an example here.)

To prevent this from happening, we can use the passive-interface {interface-id} process command.

!
router ospf 1
passive-interface Ethernet0/1
!

In the above example, setting the interface Ethernet0/1 as passive disables the sending of hello packets on that interface; hence, adjacencies will not be formed. However, the subnet 172.16.20.0/24 will continue to be advertised to other interfaces.

Let’s take a look at the result:

OSPF-IF-e-0-1-Passive

Now the output of show ip ospf interface E0/1 states that No Hellos are being sent on this interface and is a Passive interface.

You may be wondering what happens with the interface command ip ospf {process-id} area {area-id}?

Well, it is the same principle. Let’s take a look to R3 which was configured this way.

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

OSPF-R3-IF-e-0-1

As you can see the output of show ip ospf interface E0/1 display the same results as shown for R2. It states that No Hellos are being sent on this interface and is a Passive interface.

The Passive-Interface inverse logic:

You may well have a multi-layer switch with multiple VLAN-interfaces where you want to configure most or all of them as passive. In this case, would be more effective if all of the interfaces are set as passive and just enable the hello packets to the ones where is required instead go on setting the interfaces as passive one by one. (The inverse logic)

OSPF-IF-default

In this case, we can use the passive-interface default process command to disable Hello packets from all interfaces and then enable Hellos with the no passive-interface {interface-id} only on the desired interfaces.

Let’s take a look at the relevant Multi-Layer Switch configuration:

!
ip routing
!
interface Ethernet0/1
description UPLINK-to->R2
no switchport
ip address 192.168.50.2 255.255.255.252
!
interface vlan 10
ip address 10.0.10.254 255.255.255.0
!
interface vlan 20
ip address 10.0.20.254 255.255.255.0
!
interface vlan 30
ip address 10.0.30.254 255.255.255.0
!
interface vlan 40
ip address 10.0.40.254 255.255.255.0
!
interface vlan 50
ip address 10.0.50.254 255.255.255.0
!
interface loopback 0
ip address 50.50.50.50 255.255.255.255
!
router ospf 1
router-id 0.0.0.50
passive-interface default
no passive-interface Ethernet0/1
network 50.50.50.50 0.0.0.0 area 0
network 192.168.50.2 0.0.0.0 area 0
network 10.0.0.0 0.0.255.255 area 0
!

With the above configuration, we have enabled OSPF for the loopback interface, for the uplink interface between the switch and R2 and finally all of the SVI interfaces. The passive-interface default command has disabled sending hello packets in all of the OSPF-enabled interfaces. Finally, the no passive-interface Ethernet0/1 enables sending hello packets through that interface.

WARNING.!

The passive-interface default command will tear down all adjacencies almost immediately. So, consider how are you connected to the device.

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

OSPF Single Area Configuration

In previous publications, we have been gradually discovering the characteristics and operation of OSPF. Today we will configure single area OSPF and we will take a look at the link-state database and some interesting show commands.

Before starting the configuration, let’s review the prerequisites and how to enable OSPF.

OSPF Prerequisites

IP routing must be enabled. (IP routing is enabled by default in Routers but it is not in Multi-Layer switches.)
At least one interface must be in “up/up” state. (To be used by default as Router-ID)

Enabling the OSPF Routing Protocol

To enable the OSPF process in the router, the following command is required:

router ospf {process-id}

The OSPF process ID is a locally significant number and does not need to match the process IDs on other routers in the OSPF domain to establish adjacencies and exchange routing information. However, it is a good practice to keep the same number for better administration.

Enabling the OSPF process and define the process-id is not enough for the router to begin forming adjacencies. The OSPF process needs to know the networks to be advertised and the area where the networks belong.

There are two ways to advertise OSPF networks:

At the interface level, using the command:

ip ospf {process-id} area {area-id} [secondaries none]

The area-id parameter can be specified as either a decimal value or in the dotted-decimal notation similar to an IP address.

The secondaries none statement prevents secondary IP addresses configured on the interface from being advertised.

At the OSPF process level, using the command:

network {address} {wildcard-mask}area {area-id}

With the network command in OSPF, we are not telling the router what networks to advertise; we are telling the router to place some interfaces within a specific area.

Using ip-address and wildcard-mask allows specifying one or multiple interfaces with a single statement, and assign them to the desired OSPF area. The key defining the interfaces to be advertised is the wildcard mask. This is used to define how many bytes of the IP address must match with the desired network mask. This allows you to select one or multiple interfaces that meet the desired criteria. For example:

network 10.10.0.0 0.0.0.255 area 7 place interfaces with the IP address where the 3 first octets are 10.10.0 with any number [1-254] in the last octet in area 7.
network 10.10.10.0 0.0.0.63 area 9 place interfaces with the IP address where the 3 first octets are 10.10.10 and the last octet is in between 1 and 62 in area 9.

The combination of {ip-address 0.0.0.0} exactly matches an interface address; while the combination of {0.0.0.0 255.255.255.255} matches all interfaces on a router and most specific wildcard match determines the area. For example:

network 10.0.0.1 0.0.0.0 area 5 place the interface with the IP address 0.0.1 in area 5
network 0.0.0.0 255.255.255.255 area 0 place all interfaces on a router in Area 0.

OSPF Single Area Configuration

For this example we will use the following topology:

As you can see in the connectivity diagram, all routers are connected using sub-interfaces in the interface Ethernet0 /0. The physical interface Ethernet0/0 is connected to a switch with its port connected as trunk. This provides flexibility to change the topology, creating new connections in different VLANs is achieved creating new sub-interfaces.

Let’s take a look to the interface configuration of the Routers:

R1:

!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface Ethernet0/0
no ip address
!
interface Ethernet0/0.13
encapsulation dot1Q 13
ip address 192.168.13.1 255.255.255.0
!
interface Ethernet0/0.124
encapsulation dot1Q 124
ip address 192.168.124.1 255.255.255.0
!

R2:

!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
interface Ethernet0/0
no ip address
!
interface Ethernet0/0.20
encapsulation dot1Q 20
ip address 172.16.20.2 255.255.255.0
!
interface Ethernet0/0.124
encapsulation dot1Q 124
ip address 192.168.124.2 255.255.255.0
!

R3:

!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
interface Ethernet0/0
no ip address
!
interface Ethernet0/0.13
encapsulation dot1Q 13
ip address 192.168.13.3 255.255.255.0
!
interface Ethernet0/0.30
encapsulation dot1Q 30
ip address 172.16.30.3 255.255.255.0
!

R4:

!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
!
interface Ethernet0/0
no ip address
!
interface Ethernet0/0.40
encapsulation dot1Q 40
ip address 172.16.40.4 255.255.255.0
!
interface Ethernet0/0.124
encapsulation dot1Q 124
ip address 192.168.124.4 255.255.255.0
!

The Switch interfaces where the routers are connected were configured as follows:

!
interface FastEthernet0/1
switchport trunk encapsulation dot1q
switchport mode trunk
!

R1 – OSPF Configuration:

!
router ospf 1
router-id 0.0.0.1
network 1.1.1.1 0.0.0.0 area 0
network 192.168.0.0 0.0.255.255 area 0
!

The configuration in R1 means:

router ospf 1 – Enable OSPF process ID 1 (Remember this is only locally significant)
router-id 0.0.0.1 – Assign the Router-ID as 0.0.0.1 for this OSPF process. This value is also locally significant. If the Router-ID is not defined it will assign the value of the loopback interface (if any), or the value of the highest IP Address configured to any physical interface.
network 1.1.1.1 0.0.0.0 area 0 – Advertise the IP address 1.1.1.1/32 in Area 0. In this case the interface Loopback0 matches the network in all octets. Loopback interfaces are always advertised as /32 by default because of the network type loopback. However if the loopback is configured with a different mask, let’s say /24, the /24 can be advertised if the ip ospf network-type is configured as point-to-point.
network 192.168.0.0 0.0.255.255 area 0 – Advertise the networks where the first two octets of the IP address of the interface must be 192.168 and the last two can be any. In this case, E0/0.124 (192.168.124.1/24) and E0/0.13 (192.168.13.1/24) match this condition.

R2 – OSPF Configuration:

!
router ospf 1
router-id 0.0.0.2
network 2.2.2.2 0.0.0.0 area 0
network 172.16.20.0 0.0.0.255 area 0
network 192.168.0.0 0.0.255.255 area 0
!

The configuration in R2 means:

router ospf 1 – Enable OSPF process ID 1
router-id 0.0.0.2 – Assign the Router-ID as 0.0.0.2 for this OSPF process.
network 2.2.2.2 0.0.0.0 area 0 – Advertise the IP address 2.2.2.2/32 in Area 0. In this case Lo0 match with this network statement condition.
network 172.16.20.0 0.0.0.255 area 0 – Advertise the networks where the first three octets of the IP address of the interface must be 172.16.20 and the last octet can be any. In this case, E0/0.20 (172.16.20.2/24) matches this condition.
network 192.168.0.0 0.0.255.255 area 0 – Advertise the networks where the first two octets of the IP address of the interface must be 192.168 and the last two can be any. In this case, E0/0.124 (192.168.124.2/24) matches this condition.

R3 – OSPF Configuration:

!
router ospf 1
network 0.0.0.0.255.255.255.255 area 0
!

The configuration in R3 means:

router ospf 1 – Enable OSPF process ID 1.
network 0.0.0.0 255.255.255.255 area 0 – Advertise all networks belonging to the configured interfaces in Area 0. In other words, the 0.0.0.0 means any and the wildcard 255.255.255.255 also means any. Thus all configured interfaces will be advertised in Area 0. Although you may thing this is the best way to configure OSPF, is not. This type of configuration will add all interfaces even the undesired ones.

Also note the Router-ID was not defined. In this case Lo0 (3.3.3.3) will be the Router-ID assigned to the process.

R4 – OSPF Configuration:

!
router ospf 1
router-id 0.0.0.4
!
interface Loopback0
ip ospf 1 area 0
!
interface Ethernet0/0.40
ip ospf 1 area 0
!
interface Ethernet0/0.124
ip ospf 1 area 0
!

The configuration in R4 means:

router ospf 1 – Enable OSPF process ID 1
router-id 0.0.0.4 – Assign the Router-ID as 0.0.0.4 for this OSPF process.
Interface Leve commandl: ip ospf 1 area 0 – Advertise the network belonging to the IP address of the interface in with was configured in Area 0. It is the equivalent to the process command network x.x.x.x 0.0.0.0 area 0 for specific interfaces.

Keep in mind that without the secondaries none statement, this command will also advertise any secondary IP address configured in the interface.

OSPF Verification

Now that we have configured OSPF let’s take a look from the point of view of all routers.

First let’s look the neighboring state. For this purpose we will use the following commands:

Show ip ospf neighbor
Show ip ospf interface {interface-number} | [brief]

R1-1

The above output show R1 is neighbor of R2, R3 and R4 respectively. The Neighbor ID column show the Router-ID corresponding to each neighbor, PRI display the neighbor reported Priority (1 – default). The State displays the state of the link (DR, BDR, DROTHER, Waiting, Point-to-Point or Point-to-Multipoint). The Address displays the neighbor’s IP address and the Interface connecting to the segment.

The show ip ospf interface brief show local summary information of the interfaces running OSPF such the Interface, Process ID (PID), the area where the interface belong, the IP address of the local interface, it’s cost, the State of the link and Neighbors Full/Count. All of the columns are self-explain but the last one. The Nbrs F/C column represents the number of neighbors on the segment in Full State vs the count of neighbors in the given segment. If there’s inconsistency, for example 1 / 2 means one neighbor on the segment has adjacency problems. Only 1 out of two is in full state.

R2-1

R3-1

R4-1

The show ip ospf interface {interface-number} show detailed information of a given interface running OSPF.

R1-2

Now, let’s examine the Link-State Database (LSDB):

R1-3

R2-3

R3-3

R4-3

As you can see in the outputs of R1, R2, R3 and R4 LSDB, they look the same. All routers share the same information. This is because all of them are in a single area. Therefore they only have Type-1 and Type-2 LSAs. All of the routers agree on the same Designated Router (DR). As you can see on the Net Link States (Type-2 LSA) ADV router, the DR of the area is the one with RID 0.0.0.1 (R1).

The Type-1 LSA also contains information about the links reported from each network. For example, let’s take a look to the links reported from R2 (RID 0.0.0.2):

R1-4

As shown in the above example, R2 advertises 3 links. The first link is reported as Stub Network and details the information of the Loopback interface of R2. The second link is also reported as a Stub Network and corresponds to the network segment 172.16.20.0/24; finally the third link is reported as Transit. Correspond to the link connecting with R1 (192.168.124.2). The Link-ID is the Router-ID of the Designated Router (DR). All three links also display its metric (Cost).

Now, let’s take a look to the Routing Table on R1:

R1-5

As you can see in the output, all of the OSPF routes are coded as O – OSPF, this means they are Intra Area Routes and were generated by TYPE-1 LSAs.

Last, but not least, let’s take a look to the OSPF RIB:

R1-6

The OSPF RIB serves as the primary state for OSPF route computation. Each OSPF instance has its own local Routing Information Base (RIB).

The above example shows the list of routes to be installed in the global RIB. The output is similar to the one generated by BGP.

It is noteworthy that the global routing table is updated only when routes are added, deleted or changed. This greatly reduces processing cycles and results in fewer dropped packets.

It is time to close this long post.

Thank you for visiting.

OSPF Virtual Links

In a previous post (OSPF Areas and Area Types), I have mentioned that Area 0 is the backbone Area. In a multi-area OSPF autonomous system, 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.

In situations where is not possible to connect an area with the Backbone, OSPF Virtual links enter to play.

Let’s take a look to the following topology:

OSPF-Virtual-Link-1

In this example, R1 has a link in Area 0 and other in Area 123. R1 is acting as ABR between area 0 and routers in area 123. Area 123 is configured as a normal area.

R2 has routes from Area 0 advertised from R1 (ABR) as Type-3 LSAs and also has routes from within the area 123 (Type-1 and 2 LSAs); however it does not have any route or paths to R4 networks.

R3 like R2 has routes from Area 0 advertised from R2 (ABR) as Type 3 LSA, also has routes from within the area 123 (Type-1 and 2 LSAs); also has routes within the area 34 (Type 1 and 2 LSAs). R3 does not have a link in Area 0; therefore, it is not an ABR (Which is a requirement to be an ABR). Then it cannot generate Type-3 LSAs nor advertise networks to and from R4.

Finally, R4 has routes of area 34 (if any) but has no route for networks in areas 0 or area 123.

To solve this problem Virtual-links and GRE tunnels can be used, however, there are some “disadvantages” using GRE over Virtual Links which worth mentioning:

Encapsulation overhead.
GRE is process-switched.
GRE require more configurations.
Routing LSAs and Data traffic are encapsulated in GRE.

Now GRE over Virtual-Links has a big advantage which worth to mention: With GRE the transit area can be of any Type, meaning that supports Stub Areas and its variants.

A Virtual Link is an OSPF tunnel, a multi-hop point-to-point unicast adjacency; it is, in essence, an extension of Area 0 across (transit area) another area. In the previous example, area 123 is the transit area between area 0 and area 34.

OSPF-Virtual-Link-2

There are some restrictions that I have to mention:

The transit area cannot be any type of stub area.
The transit area shouldn’t have filtering configured.
If a change is done on one side of the virtual link, the change must be replicated on the other end. For example, adding authentication or changing hello/dead timers must be done on both sides of the Virtual Link.

The virtual link must be defined between the ABR and the node connecting the discontiguous area (transit area). To create the virtual link use the command area x virtual-link [Router-ID].

OSPF-Virtual-Link-3

Virtual links support additional features such authentication, hello/dead interval tuning and TTL-security. I will discuss this features in further posts.

Finally, there are some additional considerations to keep in mind when working with Virtual Links:

When configured a P2P logical interface is created with state P2P and attached to Area 0.
The default Timers of the Virtual Link interface is Hello 10 / Dead 40. However, the Hello packets in Virtual Links are suppressed by default.
Virtual Links calculate its cost based on the cost of the Router connecting the discontiguous networks to the ABR.
Virtual Links runs as a demand circuit. Misconfigurations in Virtual Links could not be detected until LSA flooding occurs. This is because LSAs originated by ABRs don’t age by default as occurs in LSAs originated for standard areas (30 mins by default).

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

OSPF Areas and Area Types

OSPF provides two levels of hierarchy through the use of Areas. An easy way to explain what an Area is would be: An OSPF area is a logical segment or a sub-domain containing networks, routers and links sharing the same area id.

Using multiple areas in OSPF reduces the router resource utilization because the routers belonging to the same area only maintain the network topology of the area where they belong. Thus, less LSA has to be flooded and maintained. In other words, the Routers in other areas; don’t have information about the topology outside its own area.

An area is a 32-bit number which can be represented the same way as an IP address such “area 0.0.0.0” or as a decimal number, such as “Area 0”.

OSPF-AT-Single-Area

The Area 0 is the backbone area in an OSPF domain. If more than one area is configured, then Area 0 is required to provide inter-area communications. This means that in an OSPF autonomous system, all areas must be physically connected to the backbone area 0.

OSPF-AT-Multi-Area

I’ve mentioned that all areas must be connected to Area 0; But, what about areas that cannot be physically connected to the area 0?

OSPF provides a native solution for this problem, OSPF Virtual-Links. I will dedicate an entire post for this technology later on.

The Routers contained within the same area are called Area Routers (AR), the routers with a link in Area Zero (0) and a Non-Zero area is called Area Border Routers (ABRs). Finally, the Routers with a link in Area Zero (0) or a Non-Zero area and redistributing from another Routing Protocol are called Autonomous System Boundary Routers (ASBRs). Summarization can be done only on ABRs and ASBRs.

OSPF-Router-Type

OSPF Area Types

The OSPF area types can be divided into the following types:

Normal Areas
- Standard.
- Transit.
Stub Area.
- Totally Stubby Area.
Not-So-Stubby Area (NSSA).
- Totally NSSA.

Normal Area

Normal Areas can be standard or transit (backbone) areas.

The Standard areas are the non-zero defined areas where LSAs Type-1, 2, 3, 4 and 5 are allowed; this means that can accept intra-area, inter-area, and external routes.

The backbone area is, in essence, a Standard area but is the area from which all other areas in OSPF must be connected.

I’ve mentioned that summarization is possible only on ABRs and ASBRs; But, what about the default route? Well I think is necessary to explain about the default-route in normal areas.

It is allowed to generate the default route in Normal Areas. The default route is injected as Type-5 LSA.

In order to generate the default route use the default-information originate process command. If the default route is not present in the Routing Table then won’t be generated unless the [always] keyword is added at the end of the command.

OSPF-AREA-Normal

Stub Area

Stub areas are typically used where the access to the rest of the network through a single link. For these type of networks is not necessary having and maintaining a full link state database. This area type can only accept intra-area, inter-area and the default route (generated by default).

Stub areas allow only LSAs Type-1, 2 and 3. Redistribution is not allowed in Stub Areas.

The default route in a Stub area is generated by default and is injected in the area as Type-3 LSA.

To configure a Stub Area use the Area [x] stub process command. This command must be added to the routers belonging to the stub area and also, must be added to the ABR connecting the stub area.

OSPF-AREA-STUB

Totally Stubby Area

Totally Stubby areas are an extension of Stub Areas and are in fact, the most restricted type of OSPF area.

In Totally Stubby Areas, the Routers receive only a default route from the ABRs, no External or Summary routes are allowed except for the default-route. The default route in Totally Stubby area is generated by default and is injected in the area as Type-3 LSA.

To configure a Totally Stubby Area use the Area [x] stub no-summary process command. This command with the no-summary keyword is required only on the ABR connecting the area.

The router connecting to the ABR does not require the no-summary keyword but requires to be defined as a stub.

OSPF-AREA-T-STUB

Not-So-Stubby Areas (NSSA)

Not-So-Stubby areas are also an extension of the stub areas. This type of area adds the flexibility of redistribution of external routes into the area while retaining its stub characteristic. This area type can only accept intra-area, inter-area, external and the default route (which is not generated by default). Not-So-Stubby areas allow only LSAs Type-1, 2, 3 and 7.

When the default route in an NSSA is generated, it is injected in the area as Type-7 LSA.

To configure an NSSA use the Area [x] nssa [default-information-originate] process command. This command must be added to the routers belonging to the NSSA area and must be also added to the ABR connecting the NSSA. The default-information-originate keyword generates the default-route in NSSA.

OSPF-AREA-NSSA

Totally Stubby NSSA

Totally Stubby NSSA is an extension to the NSSA. As a matter of fact, this is the most recommended form of NSSA area type. This type of area adds the flexibility of redistribution of external routes into the area while retaining it’s totally stubbed characteristic. This area type can only accept intra-area, external and the default route (which is generated by default). Totally Stubby NSSA areas allow only LSAs Type-1, 2, [3] and 7. The default route in a Stub area is generated by default and is injected in the area as Type-3 LSA.

To configure a Totally Stubby NSSA use the Area [x] nssa no-summary process command. This command with the no-summary keyword is required only on the ABR connecting the area.

The router connecting to the ABR does not require the no-summary keyword but requires to be defined as NSSA.

OSPF-AREA-T-NSSA

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

OSPF LSA Flooding Scope

Before start talking about the LSAs contained within areas, I would remind about what a link-state is.

The link-state describes information about the link such:

Description of the link.
1. Type – Can be Transit, P2P or Stub.
2. Cost – This is the metric.
Adjacencies with other OSPF-enabled routers in the Link.

This information is contained in the OSPF databases for each area.

Now, when we talk about the different LSA types, we have to understand what part of this link-state information is contained inside each area. A keyword I will be using in this post is Flooding Scope.

The flooding scope is basically how far in the network the LSA will be propagated unchanged.

LSA Types and Flooding Scope

LSA Type-1

Router LSAs are originated by all OSPF routers.

Type-1 LSA contains the Link State ID (which is represented by the RID) and all the different Router Link-States. The LSA may contain information about multiple links within the same area. The flooding scope of Type-1 LSA is a single area. This means that the Router will generate a single Type-1 LSA per area. The link type for this type of LSA is transit.

OSPF-LSA-TYPE-1

Please note R1 has links in area 0 and area 13, also, R2 has links in area 0 and area 24. These routers are known as Area Border Routers (ABRs). The “boundary” or flooding scope is represented by the red dashed line. R1 has two separated databases, one for the LSAs in area 0 and other for the LSAs in area 13. The same case is for R2, where 2 different databases were created; one for LSAs in area 0 and other for the LSAs in area 24. In both cases, the links belonging to each area is not advertised to other areas.

LSA Type-2

Network LSAs are originated by the Designated Router (DR).

Type-2 LSAs contains the Link ID (which is the IP address of the DR), the Netmask, and RIDs of connected neighbors within the area. The flooding scope of Type-2 LSA is a single area.

OSPF-LSA-TYPE-2

In this example, Type-2 LSAs were generated by the elected DRs in each area. This is because the media is Ethernet and the network type is broadcast by default; then the DR/BDR election took place. However, this won’t be the case if let’s say the link between R1 and R3 is configured as Network Type Point-to-Point. Then LSA Type-2 won’t be present for the Area 13.

LSA Type-3

Network Summary LSAs are originated by the Area Border Routers (ABRs).

The ABRs generate summary information of networks advertised in other areas with their respective cost to reach them. Type-3 LSA contains the Link State ID (which in this case is the summary network address), the Advertising Router ID (ABR RID), the Network mask and the calculated Metric to reach the network.

Type-3 LSAs operates in a very similar way to distance-vector protocols where a Router has a prefix with its respective cost, then that information is advertised to the neighbors by the ABR. The prefix is learned by the neighbor via the ABR (Routing by rumor). The flooding scope of Type-3 LSA is a single area.

OSPF-LSA-TYPE-3

In this example, R3 is advertising the Network A (NA). For the prefix of NA, R1 (ABR) will generate LSA Type-3 with the summary address of NA and its network mask, the LSA will also include the Advertising RID which is the RID of R1 and the cost to reach the network (NA+R3+R1), then will be advertised to R2. R2 (ABR) will also generate its own Type-3 LSA and will advertise the prefix of NA to R4 with its own RID as the Advertising RID and the aggregate cost of R2.

LSA Type-4

ASBR Summary LSAs are originated by the Area Border Routers (ABRs).

Type-4 LSAs provides reachability information for ASBRs. Type-4 LSA contains the Link State ID (which is represented by the RID of the ASBR) and the Advertising Router ID (ABR RID). The flooding scope of Type-4 LSA is a single area.

Type-4 LSAs are originated when a Router acting as ASBR sends an updated Type-1 LSA with the “E” bit set (E=Edge). The presence of this bit informs the ABR that the advertising router is an ASBR and generates the Type-4 LSA. Another way the Type-4 LSA is originated is by regeneration. Regeneration occurs when another ABR receive a Type-4 LSA.

LSA Type-5

External LSAs are originated by Autonomous System Boundary Routers (ASBRs).

Type-5 LSAs contains Link State ID (External Routes), the Network Mask, the Advertising Router ID (ASBR RID), The External Metric Type (E1 or E2) and the Forward Address. The flooding scope of Type-5 LSA is the entire OSPF domain (Standard areas excluding stub and NSSA areas).

The External Metric Type 1 (E1) set the cost as the total internal cost to get to the external destination network, including the cost to the ASBR.

The External Metric Type 2 (E2) is the default and set the cost to the advertised cost from the ASBR to the external destination network.

When the forwarding Address is set to null (0.0.0.0), mean that the route is reachable only via the advertising router.

OSPF-LSA-TYPE-4-and-5

In this example, R4 is redistributing routes from another routing protocol into OSPF. R4 is the ASBR in the network. R4 generates Type-5 LSA and advertise it to the entire OSPF Domain. R2 (ABR) generates Type-4 LSA. The Type-5 LSA contains information of the redistributed external routes, the advertising Router and the metric. The Type-4 LSA contains the ASBR reachability information. Without Type-4 LSA, Router 3 in Area 13 won’t be able to reach the redistributed networks.

LSA Type-7

NSSA External LSA is originated by Autonomous System Boundary Routers (ASBR) in NSSA areas.

Type-7 LSAs are used in NSSA areas in place of a type 5 LSA. Type-7 LSAs contains Link State ID (External Routes), the Network Mask, the Advertising Router ID (NSSA ASBR RID), The External Metric Type (N1 or N2) and the Forward Address. The flooding scope of Type-7 LSA is a single area.

The Routers in a Not-So-Stubby Areas (NSSAs) do not receive external LSAs from ABRs but are allowed to redistribute external routing information. Type-7 LSAs are translated into Type-5 LSAs by the ABR and flooded to the rest of the OSPF domain.

The External Metric Type 1 (N1) set the cost as the total internal cost to get to the external destination network, including the cost to the ASBR.

The External Metric Type 2 (N2) is the default and set the cost to the advertised cost from the ASBR to the external destination network.

OSPF-LSA-TYPE-7

In this example, R4 resides in an NSSA Area. R4 is redistributing routes from another routing protocol into OSPF. R4 is the NSSA ASBR in the network. R4 generates Type-7 LSA and advertise it to R2 (ABR). R2 translates from Type-7 LSA into Type-5 LSA and flood the information within the OSPF domain. R3 (ABR) generates Type-4 LSA containing the NSSA ASBR reachability information when R2 advertise an updated Type-1 LSA with the “E” bit set.

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

OSPF DR and BDR Election

DR and BDR election occurs in multi-access Broadcast and Non-Broadcast network types.

The purpose of the DR is to be the Router in charge to maintain the topology table and to distribute updates to other routers within the same segment.

All other routers (called DROTHERs) will form adjacencies only with the elected DR and BDR.

OSPF Routers advertise updates to the “AllDR” multicast address of 224.0.0.6; then the DR advertises the Link-State advertisements (LSAs) via the “AllSPF” multicast address 224.0.0.5.

With the use of DR is possible to reduce the network traffic between neighbors by providing a single source of updates.

DR and BDR Election:

The default DR election criteria are as follows:

The Router configured with the highest priority wins the election. The default priority is 1 and the possible values range between 0 – 255.
If the priority is set to 0, the router will not participate in the DR/BDR election.
If the routers participating in the election tie with their configured priority; then the router will use highest Router ID (RID) as tie-breaker.
The Router with the second highest priority value becomes the BDR.
If a router with the higher priority comes online after the election has taken place; it will not become DR or BDR until DR and BDR fail.
If the DR fails, the BDR will take over. Then another election will take place to elect a new BDR.
Preemption is not supported. Thus, the first router to come up will be the DR and the second will be the BDR.

OSPF-DR-BDR-1

In topologies, such hub-and-spoke with a single hub is recommended to suppress the election of BDR manually setting the hub with high priority and the spokes with priority 0.

OSPF-DR-BDR-2

OSPF Manual Priority Configuration

To configure the OSPF priorities use the ip ospf priority <0-255> interface command.

!
config t
interface e0/0
ip ospf priority 100
exit
!

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

OSPF Timers

In a previous post (OSPF Hello Packets) I have mentioned that Hello packets are also used as a keepalive mechanism. For this purpose, OSPF uses Hello and Dead Intervals. These two parameters must match between neighbors to form the adjacency.

The default OSPF timers on Cisco routers depend on the media type of the interface; however it can be manually configured.

For Broadcast Multi-access media and Point-to-Point, the default OSPF timers are 10 seconds for hello and 40 seconds for the dead timer.
For Non-Broadcast (NBMA) the defaults are 30 seconds for hello and 120 seconds for the dead timer.

Configuring Hello and Dead Timers:

To configure the hello and dead timers use ip ospf hello-interval and ip ospf dead-interval interface commands. The values are expressed in Seconds.

!
config t
interface e0/0
ip ospf hello-interval <1-65535>
ip ospf dead-interval <1-65535>
exit
!

OSPF Fast Hello Packets:

This OSPF feature allows sending hello packets at intervals of less than one second.

Yes! Sub-Second convergence can be achieved with this feature. OSPF Fast Hello is typically used in LAN segments to achieve fast convergence. Please note that sending hello packets at sub-second intervals also means more processing power. This may lead to high CPU usage and re-convergence triggered by congestion in some extreme cases.

The dead interval is set to minimal (1 second), and the hello-multiplier value is set to the number of hello packets that you want to send during that 1 second period.

When configured, the hello interval advertised in the hello packet is set to 0. This means that the hello interval in the hello packet received by the neighbor is ignored. The hello multiplier does not need to be the same as long as at least one hello packet is sent within the configured dead interval.

Configuring Fast Hello Packets:

To configure Fast Hello use the ip ospf dead-interval minimal hello-multiplier <3-20> interface command.

!
config t
interface e0/0
ip ospf dead-interval minimal hello-multiplier <3-20>
exit
!

Always keep in mind that OSPF Hello and Dead timers must match to form neighbor adjacencies. This also applies to OSPF Fast Hello dead-interval.

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