EIGRP/OSPF LAB: The Merger

In this update I will explore how to merge an existing OSPF network with an existing EIGRP network and also touch on some other subjects which you can read about in the objectives below.

Scenario:

Company A has bought Company B and must merge its network into its own. Company A runs the EIGRP routing protocol and Company B runs the OSPF routing protocol. The engineer will also need to take several other objectives into account such as route summarization, redistribution and the actual connection between the two companies over a leased line.

This lab comes with different objectives that we’ll have to research and try to complete.

Topology:

Preliminary configuration:

  1. Configure all interfaces and the Frame Relay connection.
  2. Configure all Loopback interfaces on each router.
  3. Configure EIGRP AS 10 for Company A.
  4. Configure OSPF 10 for Company B.
  5. Configure OSPF router ID’s for Company B.

Objectives:

  1. Before starting, verify proper operations for each network with the use of a Tcl script.
  2. Summarize the loopback networks on R2 as efficient as possible.
  3. Investigate and implement authentication between R3 & R4.
  4. Redistribute OSPF routes into the EIGRP network.
Instead of going step by step through the preliminary configuration, I will just give you an overview of each router and its base configuration.
If you’d like to know how to configure Frame Relay, base EIGRP or OSPF settings, please refer to my previous updates.

Now that is done, we can get started on our objectives.

Objective one; verify proper operations for each network with the use of a Tcl script.

I will use TCL scripting to check if each configured IP address is reachable for each router.
I have prepared the Tcl script for both companies’ networks in notepad as you can see below. This will then be easy to paste into each router’s cli to test inter-connectivity.

Interestingly enough, after the running the script I saw that everything was reachable, except for R3 and R4 Se 0/0 interface, and this only from its own network or locally on the router itself.

I did some research and it seems that on a connection like this, even when pinging its own local interface, the ping address will still transverse the serial link, which is weird if you ask me!

This can be solved by adding a frame-relay map pointing to the router’s own serial interface IP address. After adding this (and advertising the 10.1.1.3/27 on R3) , the Tcl script was showing full connectivity across the grid for Company A.

Now let’s take a look at Company B. I’ve made the same mistake with the frame relay map on R4, so let’s fix that first.

And now to run the Company B script that I prepared.

Seems like everything is working as should so let’s move on to objective #2; Summarize the loopback networks on R2 as efficient as possible.
I explained how to do manual summarization in this update, so you can click that link if you’re interested in learning how to do this. For now I’ll just calculate the best summary and configure it. Here is how it will end up looking for R2:

On to Objective #3, authentication between R3 and R4.
This is kind of a vague objective, what kind of authentication do they want? I’ll just decide for myself and go with route authentication, also because we will have to set up an OSPF relationship between R3 and R4 anyway for the route redistribution in Objective #4 so I will do both objectives in one go.

First I’ve set up an OSPF relationship between R3 and R4. You can also see that R3 is now aware of the OSPF routes of Company B.

And now we can configure OSPF redistribution into our EIGRP network on R3 with the router process command “redistribute OSPF 10“. You should also set the default-metric with the command “default-metric 10000 100 255 1 1500” or your routes will not be redistributed properly.

We will need to also configure R4’s equivalent and redistribute the EIGRP routes into the OSPF or else they will not be able to communicate. You would need to set up an EIGRP relationship between R4 and R3, and then use the command “redistribute EIGRP 10” under R4’s OSPF router process.

We can test proper functioning by checking the routing table and general reachability with the Company B Tcl script on R2.

Routing Table:
Note how you can see the External (EX) routes showing up now.

And let’s test reachability to Company B’s network from R2 with the prepared script.

Great, that seems to work aswell. Now I just need to configure authentication.
OSPF Authentication is implemented with the router OSPF command “area 1 authentication message-digest” and the interface Serial 0/0 command “ip ospf message-digest-key 1 md5 myospfkey” on both R 3 and R4.

You can verify proper operation of this authentication by seeing that the neighbor relationships come back up after setting the key on both sides.

EIGRP LAB # 2 : Load Balancing

In this lab I will explore equal and unequal-cost load-balancing for EIGRP and will explain how EIGRP calculates its metric values.

Topology

R1 is the router we will be doing our tests from. It will connect through R2 and R3 to IP address 124.0.0.1 on the WAN.

Objective:

  1. Set up the base EIGRP configuration.
  2. Configure and verify load balancing
  3. Configure and verify Unequal-cost load balancing.

I have done objective one, configured all the interfaces and set up the EIGRP AS, network commands and set up a default route for 124.0.0.0/24. Here’s the configuration so far.

Okay, so the base configuration is done. I have verified the EIGRP process with the “show ip eigrp neighbours” command.
For loadbalancing we will be concentrating on the connection between R1 and 124.0.0.1 on the WAN.

Let’s do a “show ip route” on R1 to see what the current situation is.

We have a Gateway of last resort for 124.0.0.0/24 as intended and it looks like we have two equal-cost routes for this same network, one going through R2 and one going through R3.

To get some more information on our default route, we can use the command “show ip eigrp topology 124.0.0.0 255.255.255.0“.

In the third line we can see that this router has 2 Successors (next hops) with a FD (Feasible distance) of 2323456.

You can also see the ‘composite metric‘ for both routes. (2323456/2297856) The first number is the Feasible distance (as seen from R1), the second number is the Reported Distance (as seen from the neighbour).

The metric calculation for EIGRP is based on something called the K-values.
These K values are a reference to the entries under “Vector metric” in the screenshot above.

The K values only act as multipliers or modifiers in the composite metric calculation.

K1 = default 1Bandwidth = This is used in the calculation by default.
K2 = default 0Load = Not participating in the calculation by default.
K3 = default 1Delay This is used in the calculation by default.
K4 = default 0Reliability = Not participating in the calculation by default.
K5 = default 0MTU = Not participating in the calculation by default.

So in this calculation, we would use 1 x Bandwidth and 1 x Delay (values on the interface). Here’s the complete formula for EIGRP.

I’ve however come across some contradicting information that claims that K5, or MTU is or isn’t used in the EIGRP Metric calculation. In fact, if you look at the last part of the formula, K5/K4 + Reliability, you will see that if K5 is set to the default of zero, it will completely eliminate this part of the calculation as zero divided by anything is always zero.

So, you would think MTU is never used, however, I’ve found an interesting arcticle that explains it will still be used as a tie-breaker when dealing with equal cost paths even if K5 is set to zero.

If your router would have to ignore some equal-cost paths to the same destination (the number of equal-cost paths exceeds the value of the maximum-paths router configuration parameter), it ignores those with the lowest MTU metric.

When processing inbound EIGRP updates, the minimum of the MTU value in the inbound UPDATE packet and the interface MTU is stored in the EIGRP topology database. No MTU processing is done on the outbound updates. The MTU metric thus represents the minimum unidirectional MTU between the current router and the originating router.

How to verify Load Balancing

The default setting for Load Balancing under EIGRP is “per-destination”.
As we’re working with only one destination, we will still end up using one link for all traffic, so it is better to implement “per-packet” load-balancing.

To enable “per-packet” load-balancing we will need to check our CEF (Cisco Express Forwarding) settings. If this device did not use CEF, we would have to disable fast-switching on the interfaces with the interface command “no ip route-cache

To check CEF for this route, use the command “show ip cef 124.0.0.1

You can see here that per-destination sharing is enabled for these two routes.
To change this to “per-packet” use the interface command “ip load-sharing per-packet” on all interfaces that forward traffic to the destination.

R1#conf t
R1(config)#int fa 0/0
R1(config-if)#ip load-sharing per-packet
R1(config-if)#int fa 0/1
R1(config-if)#ip load-sharing per-packet

If you now enter the command “show ip cef 124.0.0.1” again, you can see that sharing is now per-packet based.

That’s it, We’ve configured and verified Equal-Cost Load Balancing.

On to objective 3, Configure and verify Unequal-cost load balancing.

To start this, I will higher the Delay value for R1, Fa 0/0 and R2, Fa 0/0 to make one of the links appear faster and therefor more preferred.

R1(config)#int fa 0/0
R1(config-if)#delay 5000
R1(config)#int fa 0/1
R1(config-if)#delay 5000

If you look at the EIGRP topology now, you can see one of the routes has a higher metric. This has as result that only the route via R3 is being used to forward traffic.

If we want to use multiple links that do not have the same metric for Load-Balancing, we need to use the router process command “variance x” where x is a multiplier for the lowest metric of the routes that you want to use.

So for example “Variance 2” would use routes with a metric between 2323456 and, twice that, 4646912. In this case it would allow our higher metric route via R2 to be used in Unequal-cost Load-Balancing for the route to 124.0.0.0/24.

R1#conf t
R1(config)#router eigrp 10
R1(config-router)#variance ?
<1-128> Metric variance multiplier

R1(config-router)#variance 2

And if we take another look at the EIGRP topology, we can see both the router via R3, and the higher metric route via R2, are being used.

Looking at the output from “Show ip cef 124.0.0.1“, we can see that both routes are being used, but the lower route has a higher traffic share, meaning that it will get to forward a bigger share of the traffic that is being Load-Balanced.

And with this, we have successfully implemented and verified Unequal-cost Load-Balancing.

References:
Variance
Influencing EIGRP Metrics

EIGRP LAB # 1 : Manual Summarization and Default Network Advertisement

In this lab I will practice manual summarization for EIGRP and also touch on configuring Default Network Advertisement. As you can see from the topology below, we are dealing with quite a few networks that will be the cause for an inefficient routing table.

The idea is to have all these networks summarized in as few routing entries as possible while still maintaining the same functionality.

Lab Topology:

The Loopback Interface on R1 represents an internet connection.
The Loopback interfaces on R2 and R3 represent remote networks.

Objectives:

  1. Configure a Basic EIGRP configuration.
  2. Configure and review EIGRP manual summarization.
  3. Configure Default Network Advertisement.
Let’s start with the first Objective. “Configure a Basic EIGRP configuration“. I will not go through the entire base configuration step by step, you can check my previous updates for that if needed. Instead, here’s the configuration for all three routers that we are starting out with.

R1
==

interface Loopback0
ip address 172.31.1.1 255.255.255.0

interface FastEthernet0/0
ip address 192.168.100.1 255.255.255.248
duplex auto
speed auto

router eigrp 10
network 172.31.0.0
network 192.168.100.0
no auto-summary

R2
==

interface Loopback1
ip address 192.168.200.1 255.255.255.252

interface Loopback5
ip address 192.168.200.5 255.255.255.252

interface Loopback9
ip address 192.168.200.9 255.255.255.252

interface Loopback13
ip address 192.168.200.13 255.255.255.252

interface Loopback17
ip address 192.168.200.17 255.255.255.252

interface Loopback21
ip address 192.168.200.21 255.255.255.252

interface Loopback25
ip address 192.168.200.25 255.255.255.252

interface FastEthernet0/0
ip address 192.168.100.2 255.255.255.248
duplex auto
speed auto

interface FastEthernet0/1
ip address 10.1.1.2 255.255.255.248
duplex auto
speed auto

router eigrp 10
network 10.0.0.0
network 192.168.100.0
network 192.168.200.0
no auto-summary

R3
==

interface Loopback1
ip address 192.168.1.1 255.255.254.0

interface Loopback5
ip address 192.168.5.5 255.255.254.0

interface Loopback9
ip address 192.168.9.9 255.255.254.0

interface Loopback13
ip address 192.168.13.13 255.255.254.0

interface Loopback17
ip address 192.168.17.17 255.255.254.0

interface Loopback21
ip address 192.168.21.21 255.255.254.0

interface Loopback25
ip address 192.168.25.25 255.255.254.0

interface Loopback100
ip address 10.1.3.1 255.255.255.252

interface Loopback172
ip address 172.16.1.1 255.255.255.0

interface FastEthernet0/0
no ip address
shutdown
duplex auto
speed auto

interface FastEthernet0/1
ip address 10.1.1.3 255.255.255.248
duplex auto
speed auto

router eigrp 10
network 10.0.0.0
network 172.16.0.0
network 192.168.0.0 0.0.31.255
no auto-summary

The first big difference from OSPF is that the “autonomous system” number must match on all routers that are to become neighbors with each other.
The “AN” number is configured with the global config command “Router EIGRP 10

I have also disabled auto-summarization for EIGRP with the router config command “no auto-summary“.
EIGRP, like RIP, will summarize at the class-full boundary. Meaning that if you have a route for 10.1.3.0/24 , being a class A address, it will end up being advertised as 10.0.0.0/8
Disabling auto-summary will make it advertise as the classless network 10.1.3.0/24.

Some more explanation on EIGRP.

EIGRP stores its data in three tables.

  1. Neighbor Table: Stores data about the neighboring routers, i.e. those directly accessible through directly connected interfaces
  2. Topology Table: This table contains the aggregation of the routing tables gathered from all directly connected neighbors. For every destination, a successor and a feasible successor are identified and stored in the table if they exist. Every destination in the topology table can be marked either as “Passive“, which is the state when the routing has stabilized and the router knows the route to the destination, or “Active” when the topology has changed and the router is in the process of (actively) updating its route to that destination.
  3. Routing table: Stores the actual routes to all destinations; the routing table is populated from the topology table with every destination network that has its successor and optionally feasible successor identified (if unequal-cost load-balancing is enabled using the variance command). The successors and feasible successors serve as the next hop routers for these destinations.

Now my base configuration is done, we will confirm EIGRP’s proper configuration with the command “show ip eigrp neighbours“.
Here is the output from R2.

R2#show ip eigrp neighbors
IP-EIGRP neighbors for process 10
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
1 10.1.1.3 Fa0/1 10 01:53:10 48 288 0 3
0 192.168.100.1 Fa0/0 13 02:13:11 377 2262 0 9

In this output we can see that, for EIGRP AS 10, it has formed neighbor relationships with the devices connected on Fa0/0 and Fa0/1.
Another interesting command is “show ip eigrp topology” which shows you the network topology as learned from the device’s neighbours.

R2#sh ip eigrp topology
IP-EIGRP Topology Table for AS(10)/ID(192.168.200.25)

Codes: P – Passive, A – Active, U – Update, Q – Query, R – Reply,
r – reply Status, s – sia Status

P 10.1.3.0/30, 1 successors, FD is 409600
via 10.1.1.3 (409600/128256), FastEthernet0/1
P 10.1.1.0/29, 1 successors, FD is 281600
via Connected, FastEthernet0/1
P 192.168.100.0/29, 1 successors, FD is 281600
via Connected, FastEthernet0/0
P 192.168.8.0/23, 1 successors, FD is 409600
via 10.1.1.3 (409600/128256), FastEthernet0/1
P 192.168.12.0/23, 1 successors, FD is 409600
via 10.1.1.3 (409600/128256), FastEthernet0/1
P 192.168.0.0/23, 1 successors, FD is 409600
via 10.1.1.3 (409600/128256), FastEthernet0/1
P 192.168.4.0/23, 1 successors, FD is 409600
via 10.1.1.3 (409600/128256), FastEthernet0/1
P 192.168.24.0/23, 1 successors, FD is 409600
via 10.1.1.3 (409600/128256), FastEthernet0/1
P 192.168.16.0/23, 1 successors, FD is 409600
via 10.1.1.3 (409600/128256), FastEthernet0/1
P 192.168.20.0/23, 1 successors, FD is 409600
via 10.1.1.3 (409600/128256), FastEthernet0/1
P 192.168.200.0/30, 1 successors, FD is 128256
via Connected, Loopback1
P 192.168.200.4/30, 1 successors, FD is 128256
via Connected, Loopback5
P 192.168.200.8/30, 1 successors, FD is 128256
via Connected, Loopback9
P 192.168.200.12/30, 1 successors, FD is 128256
via Connected, Loopback13
P 192.168.200.16/30, 1 successors, FD is 128256
via Connected, Loopback17
P 172.31.1.0/24, 1 successors, FD is 409600
via 192.168.100.1 (409600/128256), FastEthernet0/0
P 192.168.200.20/30, 1 successors, FD is 128256
via Connected, Loopback21
P 192.168.200.24/30, 1 successors, FD is 128256
via Connected, Loopback25
P 172.16.1.0/24, 1 successors, FD is 409600
via 10.1.1.3 (409600/128256), FastEthernet0/1

Okay, before I start trying to summarize all those routes for objective # 2, here’s the output of all three router’s routing tables for later reference and comparison.

R1#sh ip route

Gateway of last resort is not set

172.16.0.0/24 is subnetted, 1 subnets
D 172.16.1.0 [90/435200] via 192.168.100.2, 02:03:31, FastEthernet0/0
172.31.0.0/24 is subnetted, 1 subnets
C 172.31.1.0 is directly connected, Loopback0
192.168.200.0/30 is subnetted, 7 subnets
D 192.168.200.0 [90/409600] via 192.168.100.2, 02:23:31, FastEthernet0/0
D 192.168.200.4 [90/409600] via 192.168.100.2, 02:23:31, FastEthernet0/0
D 192.168.200.8 [90/409600] via 192.168.100.2, 02:23:31, FastEthernet0/0
D 192.168.200.12
[90/409600] via 192.168.100.2, 02:23:32, FastEthernet0/0
D 192.168.200.16
[90/409600] via 192.168.100.2, 02:23:32, FastEthernet0/0
D 192.168.200.20
[90/409600] via 192.168.100.2, 02:23:32, FastEthernet0/0
D 192.168.200.24
[90/409600] via 192.168.100.2, 02:23:33, FastEthernet0/0
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
D 10.1.3.0/30 [90/435200] via 192.168.100.2, 02:03:34, FastEthernet0/0
D 10.1.1.0/29 [90/307200] via 192.168.100.2, 02:03:51, FastEthernet0/0
192.168.100.0/29 is subnetted, 1 subnets
C 192.168.100.0 is directly connected, FastEthernet0/0
D 192.168.12.0/23 [90/435200] via 192.168.100.2, 02:03:34, FastEthernet0/0
D 192.168.8.0/23 [90/435200] via 192.168.100.2, 02:03:34, FastEthernet0/0
D 192.168.24.0/23 [90/435200] via 192.168.100.2, 02:03:34, FastEthernet0/0
D 192.168.4.0/23 [90/435200] via 192.168.100.2, 02:03:34, FastEthernet0/0
D 192.168.20.0/23 [90/435200] via 192.168.100.2, 02:03:34, FastEthernet0/0
D 192.168.0.0/23 [90/435200] via 192.168.100.2, 02:03:34, FastEthernet0/0
D 192.168.16.0/23 [90/435200] via 192.168.100.2, 02:03:35, FastEthernet0/0
R2#sh ip route

Gateway of last resort is not set

172.16.0.0/24 is subnetted, 1 subnets
D 172.16.1.0 [90/409600] via 10.1.1.3, 02:02:44, FastEthernet0/1
172.31.0.0/24 is subnetted, 1 subnets
D 172.31.1.0 [90/409600] via 192.168.100.1, 02:21:12, FastEthernet0/0
192.168.200.0/30 is subnetted, 7 subnets
C 192.168.200.0 is directly connected, Loopback1
C 192.168.200.4 is directly connected, Loopback5
C 192.168.200.8 is directly connected, Loopback9
C 192.168.200.12 is directly connected, Loopback13
C 192.168.200.16 is directly connected, Loopback17
C 192.168.200.20 is directly connected, Loopback21
C 192.168.200.24 is directly connected, Loopback25
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
D 10.1.3.0/30 [90/409600] via 10.1.1.3, 02:02:47, FastEthernet0/1
C 10.1.1.0/29 is directly connected, FastEthernet0/1
192.168.100.0/29 is subnetted, 1 subnets
C 192.168.100.0 is directly connected, FastEthernet0/0
D 192.168.12.0/23 [90/409600] via 10.1.1.3, 02:02:47, FastEthernet0/1
D 192.168.8.0/23 [90/409600] via 10.1.1.3, 02:02:47, FastEthernet0/1
D 192.168.24.0/23 [90/409600] via 10.1.1.3, 02:02:47, FastEthernet0/1
D 192.168.4.0/23 [90/409600] via 10.1.1.3, 02:02:47, FastEthernet0/1
D 192.168.20.0/23 [90/409600] via 10.1.1.3, 02:02:47, FastEthernet0/1
D 192.168.0.0/23 [90/409600] via 10.1.1.3, 02:02:47, FastEthernet0/1
D 192.168.16.0/23 [90/409600] via 10.1.1.3, 02:02:47, FastEthernet0/1
R3#sh ip route

Gateway of last resort is not set

172.16.0.0/24 is subnetted, 1 subnets
C 172.16.1.0 is directly connected, Loopback172
172.31.0.0/24 is subnetted, 1 subnets
D 172.31.1.0 [90/435200] via 10.1.1.2, 02:04:18, FastEthernet0/1
192.168.200.0/30 is subnetted, 7 subnets
D 192.168.200.0 [90/409600] via 10.1.1.2, 02:04:18, FastEthernet0/1
D 192.168.200.4 [90/409600] via 10.1.1.2, 02:04:18, FastEthernet0/1
D 192.168.200.8 [90/409600] via 10.1.1.2, 02:04:18, FastEthernet0/1
D 192.168.200.12 [90/409600] via 10.1.1.2, 02:04:19, FastEthernet0/1
D 192.168.200.16 [90/409600] via 10.1.1.2, 02:04:19, FastEthernet0/1
D 192.168.200.20 [90/409600] via 10.1.1.2, 02:04:19, FastEthernet0/1
D 192.168.200.24 [90/409600] via 10.1.1.2, 02:04:19, FastEthernet0/1
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.1.3.0/30 is directly connected, Loopback100
C 10.1.1.0/29 is directly connected, FastEthernet0/1
192.168.100.0/29 is subnetted, 1 subnets
D 192.168.100.0 [90/307200] via 10.1.1.2, 02:04:20, FastEthernet0/1
C 192.168.12.0/23 is directly connected, Loopback13
C 192.168.8.0/23 is directly connected, Loopback9
C 192.168.24.0/23 is directly connected, Loopback25
C 192.168.4.0/23 is directly connected, Loopback5
C 192.168.20.0/23 is directly connected, Loopback21
C 192.168.0.0/23 is directly connected, Loopback1
C 192.168.16.0/23 is directly connected, Loopback17

Now let’s get summarizing. I will first make an overview for the loopbacks per router so I know which addresses are available.
Then after that I will look what can be done with the remaining addresses.

Okay, first up, R2. It looks like we have a range from 192.168.200.1 to 192.168.200.25.
To find out which mask we can use to summarize these routes with, we have to check which increment to use that will encompass everything from 1 to 25.

Draw the following chart.

128   64   32   16   8   4   2   1

Now check which number is big enough to hold everything from 1 to 25.
That would be 32 right? So draw the following.

128   64   32   16   8   4   2   1

1        1      1     0   0   0   0   0

Now consider the IP address we’re working with. We know nothing changes in the first three octets right? So we can be sure our subnet mask will look like 255.255.255.x where “x” is the number we’re looking for. Using the method from above, this means we’ll need to add 3 bits to our subnet mask.
( 3 x 8 1‘s + 3 1’s ).
This will give us a subnet mask of 255.255.255.224 or /27 in CIDR notation.

We now end up with the subnet 192.168.200.0/27 which has the host range from 192.168.200.1 to 192.168.200.30
Using the same calculation, we end up with 192.168.0.0/19 for R3.

Now to configure our manual summarization. This can be done with the interface command “ip summary-address eigrp 10 address mask” and should be configured on the interface where you want the summarization to happen.

Let’s do it.

R2(config)#int fa 0/0
R2(config-if)#ip summary-address eigrp 10 192.168.200.0 255.255.255.224
R2(config-if)#int fa 0/1
R2(config-if)#ip summary-address eigrp 10 192.168.200.0 255.255.255.224I’ve configured summarization on those interfaces and looks what happens:

*Mar 1 04:05:11.926: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 10: Neighbor 10.1.1.3 (FastEthernet0/1) is resync: summary configured

*Mar 1 04:06:47.706: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 10: Neighbor 10.1.1.3 (FastEthernet0/1) is resync: peer graceful-restart

Our router notices what we are up to and gracefully reinitializes the neighbourship so its neighbours can learn of the new route.
Let’s do the same for R3.

R3(config)#int fa 0/1
R3(config-if)#ip summary-address eigrp 10 192.168.0.0 255.255.224.0

Okay, let’s take a look now at our new and improved routing table.

R1#sh ip route

Gateway of last resort is not set

172.16.0.0/24 is subnetted, 1 subnets
D 172.16.1.0 [90/435200] via 192.168.100.2, 00:10:13, FastEthernet0/0
172.31.0.0/24 is subnetted, 1 subnets
C 172.31.1.0 is directly connected, Loopback0
192.168.200.0/27 is subnetted, 1 subnets
D 192.168.200.0 [90/409600] via 192.168.100.2, 00:10:13, FastEthernet0/0
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
D 10.1.3.0/30 [90/435200] via 192.168.100.2, 00:10:13, FastEthernet0/0
D 10.1.1.0/29 [90/307200] via 192.168.100.2, 00:10:14, FastEthernet0/0
192.168.100.0/29 is subnetted, 1 subnets
C 192.168.100.0 is directly connected, FastEthernet0/0
D 192.168.0.0/19 [90/435200] via 192.168.100.2, 00:06:21, FastEthernet0/0

Much much cleaner. But can we still ping all our loopbacks? Did I even do this right?
Oh god, let’s quickly test.

R1#traceroute 192.168.200.13

Type escape sequence to abort.
Tracing the route to 192.168.200.13

1 192.168.100.2 32 msec * 28 msec
R1#
R1#traceroute 192.168.1.1

Type escape sequence to abort.
Tracing the route to 192.168.1.1

1 192.168.100.2 52 msec 20 msec 20 msec
2 10.1.1.3 40 msec * 40 msec

Victory! You don’t see it here, but I tried reaching every loopback address and they all worked.

We still have the other addresses to check, but I plan to update this entry later on with that information.

For now, let’s do objective #3, Configure Default Network Advertisement.

This can be done with the command “IP Default-network address” which should be configured on R1.

R1(config)#ip default-network 172.31.0.0

R1 will then automatically advertise its new default route.
And the routing table on R2 says ..

R2#sh ip route eigrp
172.16.0.0/24 is subnetted, 1 subnets
D 172.16.1.0 [90/409600] via 10.1.1.3, 00:25:54, FastEthernet0/1
* 172.31.0.0/24 is subnetted, 1 subnets
D 172.31.1.0 [90/409600] via 192.168.100.1, 00:03:10, FastEthernet0/0
192.168.200.0/24 is variably subnetted, 8 subnets, 2 masks
D 192.168.200.0/27 is a summary, 00:26:27, Null0
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
D 10.1.3.0/30 [90/409600] via 10.1.1.3, 00:25:54, FastEthernet0/1
D 192.168.0.0/19 [90/409600] via 10.1.1.3, 00:22:01, FastEthernet0/1

There’s our default route, the one with the *, indicating it’s a “candidate default”

And that’s a wrap!

Note to self: Come back and check the 10. and 172. routes! 
This lab has been based on chapter 2-3 of the Cisco CCNP Route LAB Manual.
Other references:
cbtnuggets.com
Enhanced Interior Gateway Routing Protocol.

OSPF – Stub Areas

In this update I will explore the different kinds of stub areas for OSPF.

Now, what is this all about and why would you want to use something called a stub anyway?

It’s quite simple really;

A stub area in OSPF is an area that will not learn external routes.
Instead, external routes are replaced, by means of a Type 3 LSA, with a single default route pointing to that area’s ABR.

If you’d like to learn more about the different types of LSA, Wikipedia has a very good entry on them.
Also, you might to refer to the drawing below, where we have different area types interacting with eachother with each area showing the allowed LSA types.

Clever, right? This way you can keep router resources free for areas that do not really need such a detailed routing table. Now, ofcourse they could not keep it as simple as this and had to come up with a bunch of extra types of stubs.

Atleast they gave them funny names.

Here are three kinds we will be exploring in this update.

  1. OSPF Stub area
  2. OSPF Totally Stubby area
  3. OSPF Not-so-Stubby area

Here is the topology we will be working with.

A simple topology, but it will serve our needs for this lab.
You can see that Area 0 is ofcourse present, and another area, Area 1, which we will be making different flavors of stub.
Also note that each router has a loopback interface and router ID reflecting its hostname.

Here is the initial configuration.

R1#sh run int se 0/0
Building configuration…

Current configuration : 83 bytes
!
interface Serial0/0
ip address 100.0.0.1 255.255.255.0
clock rate 2000000
end

R1#sh run int lo 1

Building configuration…

Current configuration : 61 bytes
!
interface Loopback1
ip address 1.1.1.1 255.255.255.0
ip ospf network point-to-point

end

R1#sh run | sec ospf
router ospf 10
router-id 1.1.1.1
log-adjacency-changes
network 1.1.1.0 0.0.0.255 area 0
network 100.0.0.0 0.0.0.255 area 0
R2#sh run int se 0/0

Building configuration…

Current configuration : 83 bytes
!
interface Serial0/0
ip address 100.0.0.2 255.255.255.0
clock rate 2000000
end

R2#sh run int se 0/1
Building configuration…

Current configuration : 83 bytes
!
interface Serial0/1
ip address 200.0.0.2 255.255.255.0
clock rate 2000000
end

R2#sh run int lo 1
Building configuration…

Current configuration : 61 bytes
!
interface Loopback1
ip address 2.2.2.2 255.255.255.0
ip ospf network point-to-point
end

R2#sh run | sec ospf
router ospf 10
router-id 2.2.2.2
log-adjacency-changes
network 2.2.2.0 0.0.0.255 area 1
network 100.0.0.0 0.0.0.255 area 0
network 200.0.0.0 0.0.0.255 area 1

R3#sh run int se 0/1

Building configuration…

Current configuration : 83 bytes
!
interface Serial0/1
ip address 200.0.0.1 255.255.255.0
clock rate 2000000
end

R3#sh run int lo 1
Building configuration…

Current configuration : 61 bytes
!
interface Loopback1
ip address 3.3.3.3 255.255.255.0
ip ospf network point-to-point
end

R3#sh run | sec ospf
router ospf 10
router-id 3.3.3.3
log-adjacency-changes
network 3.3.3.0 0.0.0.255 area 1
network 200.0.0.0 0.0.0.255 area 1

Everything is on the default configuration, so R1 and R3 are seeing the full routing tables.

R1#sh ip route

Gateway of last resort is not set

1.0.0.0/24 is subnetted, 1 subnets
C 1.1.1.0 is directly connected, Loopback1
2.0.0.0/24 is subnetted, 1 subnets
O IA 2.2.2.0 [110/65] via 100.0.0.2, 00:00:02, Serial0/0
100.0.0.0/24 is subnetted, 1 subnets
C 100.0.0.0 is directly connected, Serial0/0
3.0.0.0/24 is subnetted, 1 subnets
O IA 3.3.3.0 [110/129] via 100.0.0.2, 00:00:02, Serial0/0

R3#sh ip route

Gateway of last resort is not set

1.0.0.0/24 is subnetted, 1 subnets
O IA 1.1.1.0 [110/129] via 200.0.0.2, 00:00:22, Serial0/1
2.0.0.0/24 is subnetted, 1 subnets
O 2.2.2.0 [110/65] via 200.0.0.2, 00:00:22, Serial0/1
100.0.0.0/24 is subnetted, 1 subnets
O IA 100.0.0.0 [110/128] via 200.0.0.2, 00:00:22, Serial0/1
3.0.0.0/24 is subnetted, 1 subnets
C 3.3.3.0 is directly connected, Loopback1
C 200.0.0.0/24 is directly connected, Serial0/1

We will now make Area 1 a Stub Area.

R2(config)#router ospf 10
R2(config-router)#area 1 stub

*Mar  1 00:49:27.987: %OSPF-5-ADJCHG: Process 10, Nbr 3.3.3.3 on Serial0/1 from FULL to DOWN, Neighbor Down: Adjacency forced to reset

R3(config)#router ospf 10
R3(config-router)#area 1 stub

We have configured the stub with the command “Area x stub” and it seems our OSPF Adjacency was reset because of it.

Let’s take another look at R3’s routing table.

R3#sh ip route

Gateway of last resort is 200.0.0.2 to network 0.0.0.0

1.0.0.0/24 is subnetted, 1 subnets
O IA 1.1.1.0 [110/129] via 200.0.0.2, 00:01:28, Serial0/1
2.0.0.0/24 is subnetted, 1 subnets
O 2.2.2.0 [110/65] via 200.0.0.2, 00:01:28, Serial0/1
100.0.0.0/24 is subnetted, 1 subnets
O IA 100.0.0.0 [110/128] via 200.0.0.2, 00:01:28, Serial0/1
3.0.0.0/24 is subnetted, 1 subnets
C 3.3.3.0 is directly connected, Loopback1
C 200.0.0.0/24 is directly connected, Serial0/1
O*IA 0.0.0.0/0 [110/65] via 200.0.0.2, 00:01:28, Serial0/1

Here we can see a default Inter-Area route has been added towards the Area 1 ABR, R2.
If for example, Area 0 knew about an ASBR distributing RIPv2 routes, these routes would not be redistributed to Area 1 but would instead be encompassed in the default route we are now seeing.

To verify this, let’s add a RIP route to R1 and enable redistribution with the OSPF router process command “redistribute rip subnets“.

R1(config)#int lo 80
R1(config-if)#ip address 80.0.0.1 255.255.255.0
R1(config)#router rip
R1(config-router)#network 80.0.0.0
R1(config)#router ospf 10
R1(config-router)#redistribute rip subnets

Okay, let’s see if R2 sees the redistributed route.

R2#sh ip route 80.0.0.0
Routing entry for 80.0.0.0/24, 1 known subnets

O E2 80.0.0.0 [110/20] via 100.0.0.1, 00:02:27, Serial0/0

There it is, External type 2 via R1.

And what about our stubby friend, R3?

R3#sh ip route

Gateway of last resort is 200.0.0.2 to network 0.0.0.0

1.0.0.0/24 is subnetted, 1 subnets
O IA 1.1.1.0 [110/129] via 200.0.0.2, 00:06:03, Serial0/1
2.0.0.0/24 is subnetted, 1 subnets
O 2.2.2.0 [110/65] via 200.0.0.2, 00:06:07, Serial0/1
100.0.0.0/24 is subnetted, 1 subnets
O IA 100.0.0.0 [110/128] via 200.0.0.2, 00:06:07, Serial0/1
3.0.0.0/24 is subnetted, 1 subnets
C 3.3.3.0 is directly connected, Loopback1
C 200.0.0.0/24 is directly connected, Serial0/1
O*IA 0.0.0.0/0 [110/65] via 200.0.0.2, 00:06:08, Serial0/1

As it should be, it knows only the default route for external routes.
With the “Show IP OSPF” command, you will see that this is indeed a stub area.

R3#sh ip ospf | begin Area 1
Area 1
Number of interfaces in this area is 2 (1 loopback)
It is a stub area
Area has no authentication
SPF algorithm last executed 00:08:13.540 ago
SPF algorithm executed 2 times
Area ranges are
Number of LSA 5. Checksum Sum 0x04C935
Number of opaque link LSA 0. Checksum Sum 0x000000
Number of DCbitless LSA 0
Number of indication LSA 0
Number of DoNotAge LSA 0
Flood list length 0

Now let’s turn this Stub Area into a TOTALLY STUB AREA!
Wait, why does this have such an exciting sounding name?

First of all, this is only configured on the stub area’s ABR and will allow only a single default route from the backbone area.

This can be done with the command “area 1 stub no-summary” on the ABR R2.

R2(config)#router ospf 10
R2(config-router)#area 1 stub no-summary

I’ve reset the OSPF process to be sure.
Now we’ll look at R3’s current routing table.

 R3#sh ip route

Gateway of last resort is 200.0.0.2 to network 0.0.0.0

2.0.0.0/24 is subnetted, 1 subnets
O 2.2.2.0 [110/65] via 200.0.0.2, 00:01:25, Serial0/1
3.0.0.0/24 is subnetted, 1 subnets
C 3.3.3.0 is directly connected, Loopback1
C 200.0.0.0/24 is directly connected, Serial0/1
O*IA 0.0.0.0/0 [110/65] via 200.0.0.2, 00:01:25, Serial0/1

You can see now that all Inter-Area routes are also gone, except for the default one.
2.0.0.0 is still showing up because I configured it to be in Area 1 earlier, instead of 0. It’s too bad because this is kinda ruining the effect.

In any case, our Totally Stub area is working as intended.

Next up, Not-So-Stubby Areas.

A Not-So-Stubby Area  (NSSA) is similar to a regular stub area, except that it will allow routes to be redistributed from an ASBR into that area with a special LSA type, which gets converted to a normal extended route at the ABR.

A real life situation is where you might have a stub area on the edge of your network which suddenly needs to be connected to another external network in turn. Being a stub, it will not be able to redistribute the routes from the new network. In this case we could configure it as a NSSA, allowing it to do the redistribution, but keeping the benefits of a stub area.

Let’s first remove our config from the previous test.

R2(config)#router ospf 10
R2(config-router)#no area 1 stub no-summary
R2(config-router)#no area 1 stub

R3(config)#router ospf 10
R3(config-router)#no area 1 stub

And take another look at our current routing tables.

R1#sh ip route | begin Gate
Gateway of last resort is not set

1.0.0.0/24 is subnetted, 1 subnets
C 1.1.1.0 is directly connected, Loopback1
2.0.0.0/24 is subnetted, 1 subnets
O IA 2.2.2.0 [110/65] via 100.0.0.2, 00:09:23, Serial0/0
100.0.0.0/24 is subnetted, 1 subnets
C 100.0.0.0 is directly connected, Serial0/0
3.0.0.0/24 is subnetted, 1 subnets
O IA 3.3.3.0 [110/129] via 100.0.0.2, 00:05:15, Serial0/0
O IA 200.0.0.0/24 [110/128] via 100.0.0.2, 00:09:23, Serial0/0
80.0.0.0/24 is subnetted, 1 subnets
C 80.0.0.0 is directly connected, Loopback80

R3#sh ip route | begin Gate
Gateway of last resort is not set

1.0.0.0/24 is subnetted, 1 subnets
O IA 1.1.1.0 [110/129] via 200.0.0.2, 00:05:27, Serial0/1
2.0.0.0/24 is subnetted, 1 subnets
O 2.2.2.0 [110/65] via 200.0.0.2, 00:05:27, Serial0/1
100.0.0.0/24 is subnetted, 1 subnets
O IA 100.0.0.0 [110/128] via 200.0.0.2, 00:05:27, Serial0/1
3.0.0.0/24 is subnetted, 1 subnets
C 3.3.3.0 is directly connected, Loopback1
C 200.0.0.0/24 is directly connected, Serial0/1
80.0.0.0/24 is subnetted, 1 subnets
O E2 80.0.0.0 [110/20] via 200.0.0.2, 00:00:01, Serial0/1

I will now configure the Not-So-Stubby area with the OSPF router process command “area 1 nssa“. To make R3 an ASBR I will also add the loopback 3 interface and redistribute it with the command “redistribute connected subnets”

R2(config)#router ospf 10
R2(config-router)#area 1 nssa

R3(config)#interface loopback 3
R3(config-if)#ip address 192.168.1.1 255.255.255.0
R3(config)#router ospf 10
R3(config-router)#area 1 nssa
R3(config-router)#redistribute connected subnets

If you look at the routing table for R2, you can see the external route for the 192.168.1.0/24 subnet comes in as a Type N2 from R3. This is because it is a special NSSA external route.

R2#sh ip route | begin 192
O N2 192.168.1.0/24 [110/20] via 200.0.0.1, 00:01:00, Serial0/1

If we now look at R1’s routing table, we can see that this same route has ended up as an external type 2 route

R1#sh ip route | begin 192
O E2 192.168.1.0/24 [110/20] via 100.0.0.2, 00:03:28, Serial0/0

NSSA does Type 7 LSA to Type 5 translation. We can see this in the output below from our ABR, R2.

R2#sh ip ospf | begin Area 1
Area 1
Number of interfaces in this area is 2 (1 loopback)
It is a NSSA area
Perform type-7/type-5 LSA translation
Area has no authentication
SPF algorithm last executed 00:04:04.992 ago
SPF algorithm executed 16 times
Area ranges are
Number of LSA 5. Checksum Sum 0x0326BD
Number of opaque link LSA 0. Checksum Sum 0x000000
Number of DCbitless LSA 0
Number of indication LSA 0
Number of DoNotAge LSA 0
Flood list length 0

In this update, I explored some (but not all) types of Stub areas for OSPF.

References:
OSPF Stub area animated
LSA Types
Cisco Learning network
Link-State Advertisement