OSPF filtering issue when virtual-links are present

Here is the topology I will start off with:


R4 has two INTER-area routes to 1.1.1.1:

R4#sho ip route 1.1.1.1
Routing entry for 1.1.1.1/32
  Known via "ospf 1", distance 110, metric 4, type inter area
  Last update from 192.168.45.5 on Serial1/0, 00:00:11 ago
  Routing Descriptor Blocks:
    192.168.45.5, from 5.5.5.5, 00:00:11 ago, via Serial1/0
      Route metric is 4, traffic share count is 1
  * 192.168.34.3, from 2.2.2.2, 00:00:11 ago, via Serial1/1
      Route metric is 4, traffic share count is 1

If we want to filter the path from R2 through 192.168.34.3 we could do it this way:

R4(config)#access-list 1 permit 1.1.1.1
R4(config)#access-list 2 permit 2.2.2.2
R4(config)#route-map OSPF deny 10
R4(config-route-map)#match ip address 1
R4(config-route-map)#match ip route-source 2
R4(config-route-map)#route-map OSPF permit 20
R4(config-route-map)#router ospf 1
R4(config-router)#distribute-list route-map OSPF in
R4(config-router)#^Z
      
R4#sho ip route 1.1.1.1        
Routing entry for 1.1.1.1/32
  Known via "ospf 1", distance 110, metric 4, type inter area
  Last update from 192.168.45.5 on Serial1/0, 00:00:12 ago
  Routing Descriptor Blocks:
  * 192.168.45.5, from 5.5.5.5, 00:00:12 ago, via Serial1/0
      Route metric is 4, traffic share count is 1

But let's say we have a task that asks us to create a new area attached to R4 as follows:


Now we need two virtual-links and look at was happened to our route 1.1.1.1.

R4(config)#router ospf 1                 
R4(config-router)#area 1 virtual-link 5.5.5.5          
R4(config-router)#area 1 virtual-link 2.2.2.2

*Mar  3 01:31:13.935: %OSPF-5-ADJCHG: Process 1, Nbr 5.5.5.5 on
OSPF_VL2 from LOADING to FULL, Loading Done
*Mar  3 01:31:16.979: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on
OSPF_VL3 from LOADING to FULL, Loading Done

R4#sho ip route 1.1.1.1
Routing entry for 1.1.1.1/32
  Known via "ospf 1", distance 110, metric 4, type intra area
  Last update from 192.168.34.3 on Serial1/1, 00:00:00 ago
  Routing Descriptor Blocks:
  * 192.168.45.5, from 1.1.1.1, 00:00:00 ago, via Serial1/0
      Route metric is 4, traffic share count is 1
    192.168.34.3, from 1.1.1.1, 00:00:00 ago, via Serial1/1
      Route metric is 4, traffic share count is 1

What gives? Well now we are learning 1.1.1.1 as an INTRA-area route so the router-ID advertising the LSA has changed. We are now learning the route from type-1 LSAs originated by R1 directly in Area 0. If we filter based on router-id we will lose both paths so now we need to filter based on next-hop:

R4(config)#access-list 3 permit 192.168.34.3
R4(config)#no route-map OSPF
R4(config)#route-map OSPF deny 10
R4(config-route-map)#match ip add 1
R4(config-route-map)#match ip next-hop 3
R4(config-route-map)#route-map OSPF pe 20  
R4(config-route-map)#^Z

R4#sho ip route 1.1.1.1
Routing entry for 1.1.1.1/32
  Known via "ospf 1", distance 110, metric 4, type intra area
  Last update from 192.168.45.5 on Serial1/0, 00:00:02 ago
  Routing Descriptor Blocks:
  * 192.168.45.5, from 1.1.1.1, 00:00:02 ago, via Serial1/0
      Route metric is 4, traffic share count is 1

All of this change could of course been prevented had we read ahead :-)

OSPF on unnumbered links

I was reviewing the OSPF chapter in the CCIE exam guide today and something irked me. It said that OSPF neighbors will become adjacent if one or both of the neighbors are using unnumbered interfaces between them. I swear this was not case as I had experienced before so I labbed it up.

R3#sho ip ospf ne

Neighbor ID     Pri   State           Dead Time   Address         Interface
2.2.2.2           0   FULL/  -        00:00:37    192.168.23.2    Serial1/1
4.4.4.4           0   FULL/  -        00:00:39    192.168.34.4    Serial1/0
R3#

R3(config)#int s1/0
R3(config-if)#ip unnumbered lo 0
R3(config-if)#
*Mar  2 06:31:01.600: %OSPF-5-ADJCHG: Process 1, Nbr 4.4.4.4 on Serial1/0
from FULL to DOWN, Neighbor Down: Interface down or detached

The adjcency will not come back up. Let's configure R4:

R4(config)#int s1/1
R4(config-if)#ip unnumbered lo 0
R4(config-if)#
*Mar  2 06:33:14.288: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on Serial1/1
from LOADING to FULL, Loading Done

There we go! If one side is unnumbered, the other side needs to be also. I am running 12.4(7) so maybe this was not the case awhile ago, but right now it seems so. There are a few other mistakes in this chapter, especially in the beginning quiz - SO QUESTION (LAB) EVERYTHING!

Overlapping/Duplicate AS-External-LSA IDs

I was reading OSPF: Anatomy of an Internet Routing Protocol by John T. Moy today and I came across an issue with AS-external LSA Link-State IDs. The LSA uses the network address as the identifier. If one router was to generate multiple Type 5 LSA's with the same network number but different masks, only 1 would be advertised because the LSA ID would be the same.

The book was published in 1998 and at the time there was no way of dealing with this. After doing this lab, I realized there was a way and it had since been documented in Appendix E of RFC 2328:

RFC 2328 Appendix E

Here I create 3 static routes, that all end up with the same network number and would normally have the same LSA ID:

R1(config)#ip route 192.9.0.0 255.255.0.0 Null0  
R1(config)#ip route 192.9.0.0 255.255.254.0 Null0
R1(config)#ip route 192.9.0.0 255.255.255.0 Null0
R1(config)#router ospf 1
R1(config-router)#redistribute static subnets 

Let's see what the LSA IDs are:

R1#sho ip osp database | inc 192.9
192.9.0.0       1.1.1.1         246         0x80000001 0x00933F 0
192.9.0.255     1.1.1.1         149         0x80000001 0x00933F 0
192.9.1.255     1.1.1.1         234         0x80000001 0x00834F 0
R1#

R1#sho ip ospf database external 192.9.0.0

            OSPF Router with ID (1.1.1.1) (Process ID 1)

                Type-5 AS External Link States

  LS age: 14
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 192.9.0.0 (External Network Number )
  Advertising Router: 1.1.1.1
  LS Seq Number: 80000003
  Checksum: 0x8F41
  Length: 36
  Network Mask: /16
        Metric Type: 2 (Larger than any link state path)
        TOS: 0 
        Metric: 20 
        Forward Address: 0.0.0.0
        External Route Tag: 0

The router gives the last 2 networks the broadcast address of that respective network as the Link State ID. The /16 network got the network address as the ID. I wonder if order of operations has anything to do with it

R1(config)#no ip route 192.9.0.0 255.255.0.0 Null0
R1(config)#no ip route 192.9.0.0 255.255.254.0 Null0
R1(config)#no ip route 192.9.0.0 255.255.255.0 Null0
R1(config)#ip route 192.9.0.0 255.255.255.0 Null0   

Ok, so now the /24 is the only in there and it is using 192.9.0.0 as its ID:

R1#sho ip osp database external 192.9.0.0

            OSPF Router with ID (1.1.1.1) (Process ID 1)

                Type-5 AS External Link States

  LS age: 36
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 192.9.0.0 (External Network Number )
  Advertising Router: 1.1.1.1
  LS Seq Number: 80000001
  Checksum: 0x933F
  Length: 36
  Network Mask: /24
        Metric Type: 2 (Larger than any link state path)
        TOS: 0 
        Metric: 20 
        Forward Address: 0.0.0.0
        External Route Tag: 0

What happens if we add a /16 now?

R1(config)#ip route 192.9.0.0 255.255.0.0 Null0

R1#sho ip osp database external 192.9.0.0

            OSPF Router with ID (1.1.1.1) (Process ID 1)

                Type-5 AS External Link States

  LS age: 12
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 192.9.0.0 (External Network Number )
  Advertising Router: 1.1.1.1
  LS Seq Number: 80000002
  Checksum: 0x9140
  Length: 36
  Network Mask: /16
        Metric Type: 2 (Larger than any link state path)
        TOS: 0 
        Metric: 20 
        Forward Address: 0.0.0.0
        External Route Tag: 0

R1#

The /16 stold the ID from the /24!

R1#sho ip osp database | inc 192.9       
192.9.0.0       1.1.1.1         45          0x80000002 0x009140 0
192.9.0.255     1.1.1.1         45          0x80000001 0x00933F 0

How OSPF transmit capability can prevent virtual-link routing loops

I ran into the command "capability transit" some time ago but never really understood how it worked. The explanation in the RFC and the DocCD may seem pretty vague unless you understand what issues cause it to be necessary or desirable. It is on by default so you probably will never have any issues with it, but I find it an interesting feature to look into. And by doing so, you tend to learn more about how OSPF works.

In this lab, I turn it off so we can see what issues arise. We will focus on R2's path to R4's loopback of 4.4.4.4. Each router's interface IP address ends ends with the router number so we can tell easily where traffic is flowing. Here is the topology:


I disabled capability transit on all routers, but I found that in this lab R2 is where the action is, so that might be only place we need to do it:

router ospf 1
  no capability transit

Now we begin...

R1 has a virtual link to R3 in order to connect area 234 to area 0. This works fine. R3 has become an ABR and R2 will use R3 to get to R4's loopback:

R2#sho ip route 4.4.4.4
Routing entry for 4.4.4.4/32
Known via "ospf 1", distance 110, metric 66, type inter area
Last update from 192.168.23.3 on Serial1/0, 00:00:07 ago
Routing Descriptor Blocks:
* 192.168.23.3, from 3.3.3.3, 00:00:07 ago, via Serial1/0
  Route metric is 66, traffic share count is 1

Now let's say R2 needs to add a network to area 2 as follows

R2(config)#int lo 0
R2(config-if)#ip address 2.2.2.2 255.255.255.255
R2(config-if)#ip ospf 1 area 2

Since R2 does not have an interface in area 0 we can build a virtual-link to R1:

R2(config)#router ospf 1                    
R2(config-router)#area 123 virtual-link 1.1.1.1 

R1(config)#router ospf 1              
R1(config-router)#area 123 virtual-link 2.2.2.2
*Mar  1 00:59:19.191: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on
OSPF_VL3 from LOADING to FULL, Loading Done

Perfect, right?

Let's take a look at that route towards R4 again:

R2#sho ip route 4.4.4.4
Routing entry for 4.4.4.4/32
  Known via "ospf 1", distance 110, metric 194, type inter area
  Last update from 192.168.12.1 on Serial1/1, 00:00:04 ago
  Routing Descriptor Blocks:
  * 192.168.12.1, from 3.3.3.3, 00:00:04 ago, via Serial1/1
      Route metric is 194, traffic share count is 1

Oh-no...Let's trace:

R2#trace 4.4.4.4      

Type escape sequence to abort.
Tracing the route to 4.4.4.4

  1 192.168.12.1 72 msec 24 msec 8 msec
  2 192.168.12.2 56 msec 20 msec 84 msec
  3  *  *  *
  4  *  *  *

We have a loop all-right.To fix it, on R2:

R2(config)#router ospf 1
R2(config-router)#capability transit

R2#clear ip ospf process
Reset ALL OSPF processes? [no]: yes
R2#

Few moments later:

R2#sho ip route 4.4.4.4
Routing entry for 4.4.4.4/32
  Known via "ospf 1", distance 110, metric 66, type inter area
  Last update from 192.168.23.3 on Serial1/0, 00:00:18 ago
  Routing Descriptor Blocks:
  * 192.168.23.3, from 3.3.3.3, 00:00:18 ago, via Serial1/0
      Route metric is 66, traffic share count is 1

From cisco.com

"The OSPF Area Transit Capability feature provides an OSPF Area Border Router (ABR) with the ability to discover shorter paths through the transit area for forwarding traffic that would normally need to travel through the virtual-link path."

OSPF Area Transit Capability

So in this case, we have allowed R2 to use it direct path to R3 instead of it's own path through the backbone area. We have basically made area 123 a transit area that can carry traffic to destinations not in it's own area. We are flowing from Area 0 (R2 is an ABR now) to Area 123 to Area 234!

Since this command is enabled by default on recent IOS versions, I am not sure you would ever run into this issue in the lab. However, it is still an interesting feature and it is always good to know what's really going on under the hood :-)

OSPF - Lowest IP address in OSPF is used as forwarding address on ASBR

I was labbing some NSSA today and I was wondering how the OSPF ASBR chose the forward address since it seem to appear on the opposite side of traffic flow. Example:

R3----SW1----R6

SW1 is the ASBR (redistributing it's loopback). Traffic was flowing through R6, but the address pointing to R3 was the "forward address". It doesn't really matter as long as the link is in OSPF but it can impact metric calculations since SW1's interface cost to R3 will be included.

I did a short search on GS and RFC2328 but could not find anything. I had a guess it was the lowest IP in OSPF on the router and it turns out that is right:

SW1#show run | sec router ospf
router ospf 1
router-id 11.11.11.11
log-adjacency-changes
area 2 nssa
redistribute connected metric-type 1 subnets route-map con2ospf
network 2.0.0.1 0.0.0.0 area 2
network 192.168.37.7 0.0.0.0 area 2
network 192.168.67.7 0.0.0.0 area 2

SW1#show ip int bri
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 192.168.37.7 YES manual up up
FastEthernet2/0 192.168.67.7 YES manual up up
Loopback2 2.0.0.1 YES manual up up
Loopback100 100.100.100.100 YES manual up up

SW1#show ip ospf database external

OSPF Router with ID (11.11.11.11) (Process ID 1)
SW1#show ip ospf database ns
SW1#show ip ospf database nssa-external

OSPF Router with ID (11.11.11.11) (Process ID 1)

Type-7 AS External Link States (Area 2)

LS age: 243
Options: (No TOS-capability, Type 7/5 translation, DC)
LS Type: AS External Link
Link State ID: 100.100.100.100 (External Network Number )
Advertising Router: 11.11.11.11
LS Seq Number: 80000009
Checksum: 0x8EBF
Length: 36
Network Mask: /32
Metric Type: 1 (Comparable directly to link state metric)
TOS: 0
Metric: 20
Forward Address: 2.0.0.1
External Route Tag: 0

SW1#

Routing Loop - Part I

I was reading "Optimal Routing Design" by Cisco Press today and a routing loop scenario was described (chapter 2), but they had it all wrong and screwy and it gave me a routing loop in my brain. So I wanted to actually do a similar scenario some justice. This hopefully will be first part in maybe a series of posts that deal with routing loops, since they can be real buggers.

The Topology:



The Scenario:

R2 is hub with R5 and R6 as OSPF neighbors.
R5 and R6 are also EIGRP neighbors with R7.
R7 is redistributing it's serial interface with R8 into the EIGRP domain.
R5 and R6 are mutually redistributing between OSPF and EIGRP.

If R5 and R6 redistribute OSPF into EIGRP with equal metrics, everything stabilizes, even though you have a suboptimal path. This is because External OSPF (AD=110) is preferred over External EIGRP (AD=170). So whichever device (R5 or R6) redistributes R7's serial network into OSPF first, will keep it's route via EIGRP but the other router will learn it via OSPF.

Let's take a look at R5 and R6 OSPF and EIGRP config (there both the same):

R5#show run | sec router ospf|eigrp
router eigrp 1
redistribute ospf 1 metric 1 1 1 1 1
network 150.100.0.0
no auto-summary
router ospf 1
log-adjacency-changes
redistribute eigrp 1 subnets
network 150.100.100.0 0.0.0.255 area 0
R5#

This results in the following route entries for 150.100.78.0

R5#show ip route 150.100.78.0
Routing entry for 150.100.78.0/24
Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 128
Redistributing via eigrp 1
Advertised by eigrp 1 metric 1 1 1 1 1
Last update from 150.100.100.2 on Serial1/0, 00:10:23 ago
Routing Descriptor Blocks:
* 150.100.100.2, from 6.6.6.6, 00:10:23 ago, via Serial1/0
Route metric is 20, traffic share count is 1

R6#show ip route 150.100.78.0
Routing entry for 150.100.78.0/24
Known via "eigrp 1", distance 170, metric 2560002816, type external
Redistributing via eigrp 1, ospf 1
Advertised by ospf 1 subnets
Last update from 150.100.56.7 on FastEthernet0/0, 00:01:21 ago
Routing Descriptor Blocks:
150.100.56.7, from 150.100.56.7, 00:01:21 ago, via FastEthernet0/0
Route metric is 2560002816, traffic share count is 1
Total delay is 110 microseconds, minimum bandwidth is 1 Kbit
Reliability 1/255, minimum MTU 1 bytes
Loading 1/255, Hops 1
* 150.100.56.5, from 150.100.56.5, 00:01:21 ago, via FastEthernet0/0
Route metric is 2560002816, traffic share count is 1
Total delay is 110 microseconds, minimum bandwidth is 1 Kbit
Reliability 1/255, minimum MTU 1 bytes
Loading 1/255, Hops 1

R2#trace 150.100.78.7

Type escape sequence to abort.
Tracing the route to 150.100.78.7

1 150.100.100.6 76 msec 72 msec 20 msec
2 150.100.56.7 48 msec * 72 msec
R2#

Notice that R5 has learned the route via OSPF and has advertised it back into EIGRP with the same metric that R7 is originally advertising it with. R6 has installed them both. So far it's not impacting anything.

Now let's suppose we had a task that said R7 should prefer R5 to reach the OSPF domain and you must configure the solution on R5. How could we do that? We could adjust the metric when redistributing. Let's do this by increasing the bandwidth metric on R5:

R5(config)#router eigrp 1
R5(config-router)#redistribute ospf 1 metric 2 1 1 1 1

Now let's look at R6's entry:

R6#show ip route 150.100.78.0
Routing entry for 150.100.78.0/24
Known via "eigrp 1", distance 170, metric 1280002816, type external
Redistributing via eigrp 1, ospf 1
Advertised by ospf 1 subnets
Last update from 150.100.56.5 on FastEthernet0/0, 00:01:37 ago
Routing Descriptor Blocks:
* 150.100.56.5, from 150.100.56.5, 00:01:37 ago, via FastEthernet0/0
Route metric is 1280002816, traffic share count is 1
Total delay is 110 microseconds, minimum bandwidth is 2 Kbit
Reliability 1/255, minimum MTU 1 bytes
Loading 1/255, Hops 1

Its' pointing back to R5!! Let's look at R5:

R5#show ip route 150.100.78.0
Routing entry for 150.100.78.0/24
Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 128
Redistributing via eigrp 1
Advertised by eigrp 1 metric 2 1 1 1 1
Last update from 150.100.100.2 on Serial1/0, 00:15:35 ago
Routing Descriptor Blocks:
* 150.100.100.2, from 6.6.6.6, 00:15:35 ago, via Serial1/0
Route metric is 20, traffic share count is 1

It's still pointing to R2!! Trace from R2:


R2#trace 150.100.78.7

Type escape sequence to abort.
Tracing the route to 150.100.78.7

1 150.100.100.6 40 msec 76 msec 16 msec
2 150.100.56.5 96 msec 28 msec 44 msec
3 150.100.100.2 44 msec 36 msec 44 msec
4 * * *
5 * * *
6 * * *

So...how would you fix it?

R5 and R6 should learn this route via EIGRP...but last time I tried you could not alter AD for specific external routes...but you can do it for OSPF.

access-list 78 permit 150.100.78.0 0.0.0.255
router ospf 1
distance 180 0.0.0.0 255.255.255.255 78

Now the OSPF route will never be preffered but we do have failover should R5 or R6 lose its LAN connection. Doing this on one side actually fixes it, but leaves R6 with a suboptimal route. I prefer to do it on both.

Final verification of the solution:

R5#show ip route 150.100.78.0
Routing entry for 150.100.78.0/24
Known via "eigrp 1", distance 170, metric 2560002816, type external
Redistributing via eigrp 1, ospf 1
Advertised by ospf 1 subnets
Last update from 150.100.56.7 on FastEthernet0/0, 00:00:16 ago
Routing Descriptor Blocks:
* 150.100.56.7, from 150.100.56.7, 00:00:16 ago, via FastEthernet0/0
Route metric is 2560002816, traffic share count is 1
Total delay is 110 microseconds, minimum bandwidth is 1 Kbit
Reliability 1/255, minimum MTU 1 bytes
Loading 1/255, Hops 1

R6#show ip route 150.100.78.0
Routing entry for 150.100.78.0/24
Known via "eigrp 1", distance 170, metric 2560002816, type external
Redistributing via eigrp 1, ospf 1
Advertised by ospf 1 subnets
Last update from 150.100.56.7 on FastEthernet0/0, 00:00:12 ago
Routing Descriptor Blocks:
* 150.100.56.7, from 150.100.56.7, 00:00:12 ago, via FastEthernet0/0
Route metric is 2560002816, traffic share count is 1
Total delay is 110 microseconds, minimum bandwidth is 1 Kbit
Reliability 1/255, minimum MTU 1 bytes
Loading 1/255, Hops 1

2#trace 150.100.78.7

Type escape sequence to abort.
Tracing the route to 150.100.78.7

1 150.100.100.6 44 msec
150.100.100.5 104 msec
150.100.100.6 20 msec
2 150.100.56.7 56 msec * 72 msec
R2#

If you know any other scenarios, please let me know.

Redistribution filtering with distribute list

This command still gets me because of the "out" keyword but here is it how it works. It might help to remember there is no "in" keyword when you filter from a routing process.

Topology:

R1---OSPF---R2---OSPF---R5---EIGRP---R6---EIGRP---R9

R9 has loopback 9.9.9.9
R2 has loopback 2.2.2.2

We will filter these routes during redistribution but allow all others.

Will start by filtering R9's loopback from EIGRP to OSPF. On R5 we create the prefix-list:

R5(config)#ip prefix-list BLOCK9 deny 9.9.9.9/32
R5(config)#ip prefix-list BLOCK9 permit 0.0.0.0/0 le 32

Then we apply it under the OSPF process. I know it looks weird but just remember there is no "in" direction when you filter this way.

R5(config)#router ospf 1
R5(config-router)#distribute-list prefix BLOCK9 out eigrp 1

Lets' check R2, notice we see R6's loopback but not R9's

R2#show ip route | inc E2
E1 - OSPF external type 1, E2 - OSPF external type 2
O E2 6.6.6.6 [110/20] via 150.100.100.5, 00:00:11, Serial1/0.2
O E2 150.100.69.0/24 [110/20] via 150.100.100.5, 00:07:51, Serial1/0.2
O E2 150.100.56.0/24 [110/20] via 150.100.100.5, 00:07:51, Serial1/0.2

Now let's do the other direction. First Let's check R9's table:

R9#show ip route | inc EX
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
D EX 1.1.1.1 [170/2560514816] via 150.100.69.6, 00:00:06, Serial1/1
D EX 2.2.2.2 [170/2560514816] via 150.100.69.6, 00:00:06, Serial1/1
D EX 4.4.4.4 [170/2560514816] via 150.100.69.6, 00:00:06, Serial1/1
D EX 192.168.100.2 [170/2560514816] via 150.100.69.6, 00:00:06, Serial1/1
D EX 150.100.100.2/32
D EX 150.100.24.0/24 [170/2560514816] via 150.100.69.6, 00:00:06, Serial1/1
D EX 150.100.12.0/24 [170/2560514816] via 150.100.69.6, 00:00:06, Serial1/1

Configure R5. remember this blocks FROM ospf process 1:

R5(config)#ip prefix-list BLOCK2 seq 5 deny 2.2.2.2/32
R5(config)#ip prefix-list BLOCK2 seq 10 permit 0.0.0.0/0 le 32
R5(config)#router eigrp 1
R5(config-router)#distribute-list prefix BLOCK2 out ospf 1

The neighbors will resync:

*Mar 1 00:20:38.571: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 150.100.56.6 (FastEthernet0/0) is resync: route configuration changed

Now check R9 and R2's loopback has been filtered:

R9#show ip route | inc EX
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
D EX 1.1.1.1 [170/2560514816] via 150.100.69.6, 00:02:11, Serial1/1
D EX 4.4.4.4 [170/2560514816] via 150.100.69.6, 00:02:11, Serial1/1
D EX 192.168.100.2 [170/2560514816] via 150.100.69.6, 00:02:11, Serial1/1
D EX 150.100.100.2/32
D EX 150.100.24.0/24 [170/2560514816] via 150.100.69.6, 00:02:11, Serial1/1
D EX 150.100.12.0/24 [170/2560514816] via 150.100.69.6, 00:02:11, Serial1/1

Task Interpretation (probably part 1 of many)

Recently I had a task that told me a serial link between two routers will only be used if the Ethernet and frame-relay links between these routers went down. Detection of the failed links and convergence should happen within 10 seconds. Immediately I thought of the backup interface command, however:

R4(config)#interface e0/0
R4(config-if)#backup interface s0/1
Serial0/1 is already a backup for Serial0/0
R4(config-if)#

You can only have an interface be a backup for one interface!

What the task was really asking for was to make OSPF detect the failed neighbors within 10 seconds and thus install the direct serial link route. We do this by adjusting the hello-interval on the Ethernet and frame-relay links to 2 seconds (2 x 4 = 8 second dead interval).

Another reason it is important to think a little outside the box and try to understand what the goal of the task is.

Route Redistribution Issues Part I – RIP and OSPF

This is part of task I had on IEWB volume 3 workbook lab 1. I tweaked it a little. I wanted to get better idea of redistribution when there are multiple points of redistribution. It is always the hardest concept for me to get my head around because there so many things going on. I know the tasks may only be a few points, but it affects reachability which can hurt you later if you do not have it.

If you develop a thought process for it and recognize patterns and spot issues beforehand, you will be better off. I don't have any configurations here, just my thought flow. I was doing this practice lab at the same but I just wanted to document the thoughts.


Perform redistribution between RIP and OSPF on R4 and R5 and ensure reachability to the loopback interfaces on R1 and R9 from anywhere when R4 or R5’s frame link are down. If both are down then reachability to R9 and R1 cannot be achieved from R2.

Thought Process:

First thing I would do is identify which networks need to be learned via each protocol on each router, along with back up routes:

Router	Destination	Primary Route	Backup Route
R1	R9, LAN59	RIP via R4	n/a
R4	R9, LAN59 R1	RIP via R5 RIP via R1	OSPF via R5 n/a
R5	R1, LAN14 R9	RIP via R4 RIP via R9	OSPF via R4 n/a
R9	R1, LAN14	RIP via R5	n/a
R2	All	OSPF via R4 or R5	n/a

Next thing is to break down the redistribution into steps. These steps can be in various orders which may affect traffic flow, but I like to start with the edge networks in and resolve issues as we progress. We have 4 steps here:

Step 1: Redistribute RIP into OSPF on R5
R2 now has access to R9 loopback and LAN59 via R5
R5 has no changes to it’s routes
R4 now learns the route to R9 and LAN59 via OSPF through R5
R1 no longer has a route to R9 or LAN59 because R4 learns these via OSPF, not RIP anymore

Step 2: Redistribute RIP into OSPF on R4
R2 now has access to R1 loopback and LAN14 via R4.
R4 is the same as in step 1.
R5 now learns the route to R1 Loopback and LAN14 via OSPF through R4
R9 cannot reach R1 anymore because R5 is learning R1 and LAN14 through OSPF, not RIP

Issues remaining after steps 1 and 2:
R1 or R9 cannot respond to pings from R2 because they do not have a route for the OSPF network.
R1 and R9 cannot reach each other’s loopbacks or connected LANs.

Step 3: Redistribute OSPF into RIP on R4
Here is we encounter a loop. The reason is that once R4 does this it will now advertise RIP routes back to R1 and R5 that may have already been in RIP to begin with. So the problems will be with any existing RIP routes on these routers. R5 currently has a RIP route for R9 loopback with a metric of 1. R4 is going to redistribute this route back to R5 also with a mteric of 1 (the metric is up to use, but I use 1 for example). R5 now will load share between two routes to R9. One router will be a loop (the one through R4). R5 has no way of knowing that this route is the same route it redistributed into OSPF. We can resolve this by setting a higher metric on the routes that R4 redistributes into RIP. Setting the metric to 2 in this example resolves the issue.

R2 now has reachability to R1 and LAN14, but still no reachability to R9 because R9 has no route back. R9 also has no route to R1.

Step 4: Redistribute OSPF into RIP on R5
In the final step of redistribution R5, we may cause another loop by advertising R1’s loopback back to R4 over the serial link with a metric 1. However, we set the metric to 2 to rpevent this.

Shutting down serial link between R4 and R5:
Because this link is not used for any transit networks, this link does not affect reachability to R1 or R9 whether up or down.

Shutting down only R5 frame-relay interface:
R5 loses its OSPF networks and learns all routes via RIP through R4. R4 uses the RIP link to reach R9 and LAN59.

Shutting down only R4 frame-relay interface:
R4 loses it OSPF networks and learns all routes via RIP through R5. LAN14 and R1 are still learned directly from R1.

OSPF - dead time expiring

I was setting up a frame-relay lab a few moments ago and I ran into strange issue. R5 and R6 are going to connect via EBGP with their loopbacks. To connect to each other's loopbacks I was using OSPF over the Frame cloud.

However, I kept getting this message on R6:

R6#
Mar 1 00:34:18.895: %OSPF-5-ADJCHG: Process 1, Nbr 5.5.5.5 on Serial1/1 from FULL to DOWN, Neighbor Down: Dead timer expired
R6#
Mar 1 00:34:46.323: %OSPF-5-ADJCHG: Process 1, Nbr 5.5.5.5 on Serial1/1 from LOADING to FULL, Loading Done
R6#

These are point-to-multipoint links by the way. I started monitoring the neighbor relationship to se if hello's were being received. I was alarmed when I saw this:

R6#show ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface
5.5.5.5 0 FULL/ - 00:01:08 172.14.45.5 Serial1/1
4.4.4.4 0 FULL/ - 00:01:50 172.14.45.4 Serial1/1

The dead time crept well below 1:20 which is the period during which I should have received a hello. I ran "debug ip ospf packet" on R6 and was not receiving any hellos from R5. But how was the adjacency forming in the first place! It did however receive replies when R6 initiated the process. This was immediately after the neighbor went down.

So I did some more searching on R5 and found this:

R5#show run int s1/1
Building configuration...

Current configuration : 217 bytes
!
interface Serial1/1
ip address 172.14.45.5 255.255.255.0
encapsulation frame-relay
ip ospf network point-to-multipoint
serial restart-delay 0
frame-relay map ip 172.14.45.6 506
no frame-relay inverse-arp
end

What's the problem? No broadcast statement on the frame-relay map command!

OSPF - overload protection Part 2

This is a follow up to the last overload protection post which kind of sucked and was very long-winded considering I didn't really know what I was looking for at the time.

Here I use a different example to give OSPF some time to keep from permanently ignoring neighbors. We do this by using the the ignore-count, reset-time, and ignore-time options of the max-lsa router mode command:

R4(config-router)#max-lsa 14 50 ignore-count 2 ignore-time 3 reset-time 2

Limit reached:

Mar 1 04:08:53.359: %OSPF-4-OSPF_MAX_LSA: Maximum number of non self-generated LSA has been exceeded "ospf 1" - 15 LSAs

Neighbors come down after 1 minute:

Mar 1 04:09:53.487: %OSPF-5-ADJCHG: Process 1, Nbr 5.5.5.5 on Serial1/0 from FULL to DOWN, Neighbor Down: Interface down or detached
Mar 1 04:09:53.495: %OSPF-5-ADJCHG: Process 1, Nbr 6.6.6.6 on Serial1/0 from FULL to DOWN, Neighbor Down: Interface down or detached
Mar 1 04:09:53.547: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on FastEthernet0/1 from FULL to DOWN, Neighbor Down: Interface down or detached

Ignore time is 3 minutes and counting down, notice our current ignore-count is 1. Once this reaches 3 all neighbors will be permanently ignored.

R4#show ip ospf | section Maximum number of non self-generated
Maximum number of non self-generated LSA allowed 14
Threshold for warning message 50%
Ignore-time 3 minutes, reset-time 2 minutes
Ignore-count allowed 2, current ignore-count 1
Ignoring all neighbors due to max-lsa limit, time remaining: 00:02:36

R4#show ip ospf | section Maximum number of non self-generated
Maximum number of non self-generated LSA allowed 14
Threshold for warning message 50%
Ignore-time 3 minutes, reset-time 2 minutes
Ignore-count allowed 2, current ignore-count 1
Ignoring all neighbors due to max-lsa limit, time remaining: 00:00:05

Neighbors come back up after the ignore-timer expires and reset timer is now triggered.

Mar 1 04:12:57.060: %OSPF-4-OSPF_MAX_LSA_THR: Threshold for maximum number of non self-generated LSA has been reached "ospf 1" - 7 LSAs
Mar 1 04:12:57.072: %OSPF-5-ADJCHG: Process 1, Nbr 6.6.6.6 on Serial1/0 from LOADING to FULL, Loading Done
Mar 1 04:13:01.498: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on FastEthernet0/1 from LOADING to FULL, Loading Done
Mar 1 04:13:23.937: %OSPF-5-ADJCHG: Process 1, Nbr 5.5.5.5 on Serial1/0 from LOADING to FULL, Loading Done

The count is still 1 and reset timer counts down from 2 minutes:

R4#show ip ospf | section Maximum number of non self-generated
Maximum number of non self-generated LSA allowed 14
Threshold for warning message 50%
Ignore-time 3 minutes, reset-time 2 minutes
Ignore-count allowed 2, current ignore-count 1 - time remaining: 00:01:51

If the timer expires, ignore-count is reset to 0 and OSPF will remain stable as long as the number of LSA's received is under the max-lsa limit. However if the max-lsa is reached again (which it will do in my lab) before the reset timer expires, the ignore count will be incremented and the ignore-timer will start. Eventually the ignore-count limit will be reached and neighbors will be ignored permanently.

OSPF - overload protection

This lab again uses the topology of another OSPF post:

R2 ---> R5 in area 25
R5 ---> R4 in area 0
R4 ---> R3 in area 345

Area 25 is an NSSA.
R2 is an ASBR redistruting connected and static routes into OSPF:

R2#show run | section router ospf
router ospf 1
log-adjacency-changes
area 25 nssa
redistribute maximum-prefix 4 50 warning-only
redistribute connected subnets tag 100
redistribute static metric-type 1 subnets tag 200
network 172.12.25.0 0.0.0.255 area 25

R4 has the following ospf database:

R4# show ip ospf database

OSPF Router with ID (4.4.4.4) (Process ID 1)

Router Link States (Area 0)

Link ID ADV Router Age Seq# Checksum Link count
4.4.4.4 4.4.4.4 70 0x80000003 0x009BEB 3
5.5.5.5 5.5.5.5 112 0x8000000D 0x0093E2 3
6.6.6.6 6.6.6.6 71 0x8000000F 0x0050F6 4

Summary Net Link States (Area 0)

Link ID ADV Router Age Seq# Checksum
3.3.3.3 4.4.4.4 124 0x80000001 0x009A84
4.4.4.4 4.4.4.4 124 0x80000001 0x0062B9
172.12.25.0 5.5.5.5 982 0x80000006 0x000210
172.12.34.0 4.4.4.4 124 0x80000001 0x004E03

Router Link States (Area 345)

Link ID ADV Router Age Seq# Checksum Link count
3.3.3.3 3.3.3.3 140 0x80000014 0x009F90 2
4.4.4.4 4.4.4.4 121 0x80000002 0x00F23E 2

Net Link States (Area 345)

Link ID ADV Router Age Seq# Checksum
172.12.34.3 3.3.3.3 140 0x80000001 0x0089AA

Summary ASB Link States (Area 345)

Link ID ADV Router Age Seq# Checksum
5.5.5.5 4.4.4.4 106 0x80000001 0x009E39

Type-5 AS External Link States

Link ID ADV Router Age Seq# Checksum Tag
1.1.1.1 5.5.5.5 459 0x80000002 0x00BB83 200
2.2.2.2 5.5.5.5 459 0x80000002 0x00021D 100
2.2.2.3 5.5.5.5 459 0x80000002 0x00F726 100
2.2.2.4 5.5.5.5 459 0x80000002 0x00ED2F 100
2.2.2.5 5.5.5.5 459 0x80000002 0x00E338 100
5.5.5.5 5.5.5.5 985 0x80000006 0x006013 0
172.12.123.0 5.5.5.5 459 0x80000002 0x00BA38 100
192.168.254.0 5.5.5.5 459 0x80000002 0x004397 200

There are 19 LSAs here, 6 of them generated by this router (router-id = 4.4.4.4) for a total of 13 non-self-generated LSAs. We can limit the number of these such LSA received by the OSPF process as follows:

R4(config)#router ospf 1
R4(config-router)#max-lsa ?
<1-4294967294> Maximum number of non self-generated LSAs this process can receive

R4(config-router)#max-lsa 14 ?
<1-100> Threshold value (%) at which to generate a warning msg

R4(config-router)#max-lsa 14 50 ?
ignore-count maximum number of times adjacencies can be suppressed
ignore-time time during which all adjacencies are suppressed
reset-time time after which ignore-count is reset to zero
warning-only Only give warning message when limit is exceeded

R4(config-router)#max-lsa 14 50 ignore-count 1 ignore-time ?
<1-17895> number of minutes during which all adjacencies are suppressed

R4(config-router)#max-lsa 14 50 ignore-count 1 ignore-time 1 reset-time ?
<2-35791> number of minutes after which ignore-count is reset to zero

R4(config-router)#max-lsa 14 50 ignore-count 1 ignore-time 1 reset-time 2

After the command is entered, the adjacencies are reset and th follwoing log message appears when the adjacencies come back up.

R4(config-router)#
Mar 1 03:07:58.209: %OSPF-4-OSPF_MAX_LSA_THR: Threshold for maximum number of n
on self-generated LSA has been reached "ospf 1" - 7 LSAs

So we have passed the 50% threshold and are near the limit, let's add a new LSA buy creating a new loopback being advertised on a distant router:

R2(config)#int lo 4
R2(config-if)#ip address 2.2.2.6 255.255.255.255

Nothing happened on R4, so let's add another network to OSPF:

R2(config)#int lo 5
R2(config-if)#ip address 2.2.2.7 255.255.255.255

Now we see something:

Mar 1 03:10:59.144: %OSPF-4-OSPF_MAX_LSA: Maximum number of non self-generated
LSA has been exceeded "ospf 1" - 15 LSAs

One minute later the adjacencies are dropped:

Mar 1 03:11:59.264: %OSPF-5-ADJCHG: Process 1, Nbr 6.6.6.6 on Serial1/0 from FULL to DOWN, Neighbor Down: Interface down or detached
Mar 1 03:11:59.272: %OSPF-5-ADJCHG: Process 1, Nbr 5.5.5.5 on Serial1/0 from FULL to DOWN, Neighbor Down: Interface down or detached
Mar 1 03:11:59.320: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on FastEthernet0/1 from FULL to DOWN, Neighbor Down: Interface down or detached

R4#show ip ospf neighbor

R4#

After 1 minute the adjacencies come back up:

Mar 1 03:13:01.403: %OSPF-4-OSPF_MAX_LSA_THR: Threshold for maximum number of non self-generated LSA has been reached "ospf 1" - 7 LSAs
Mar 1 03:13:01.407: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on FastEthernet0/1 from LOADING to FULL, Loading Done
Mar 1 03:13:16.335: %OSPF-5-ADJCHG: Process 1, Nbr 5.5.5.5 on Serial1/0 from LOADING to FULL, Loading Done
Mar 1 03:13:27.123: %OSPF-5-ADJCHG: Process 1, Nbr 6.6.6.6 on Serial1/0 from LOADING to FULL, Loading Done
R4#
R4#show ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface
6.6.6.6 0 FULL/ - 00:01:44 172.12.45.6 Serial1/0
5.5.5.5 0 FULL/ - 00:01:44 172.12.45.5 Serial1/0
3.3.3.3 1 FULL/BDR 00:00:35 172.12.34.3 FastEthernet0/1

-An Anti-summary-

Let's review exactly what happens with these timers with a new example On R4:

R4(config)#router ospf 1
R4(config-router)#max-lsa 15 50 ignore-count 1 ignore-time 2 reset-time 5

R2(config-if)#int lo 6
R2(config-if)#ip address 2.2.2.8 255.255.255.255

R4#
Mar 1 03:24:54.040: %OSPF-4-OSPF_MAX_LSA: Maximum number of non self-generated
LSA has been exceeded "ospf 1" - 16 LSAs

Neighbors are still up:

R4#show ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface
6.6.6.6 0 FULL/ - 00:01:38 172.12.45.6 Serial1/0
5.5.5.5 0 FULL/ - 00:01:57 172.12.45.5 Serial1/0
3.3.3.3 1 FULL/DR 00:00:32 172.12.34.3 FastEthernet0/

Neighbors finally come down after 1 minute:

Mar 1 03:25:54.160: %OSPF-5-ADJCHG: Process 1, Nbr 6.6.6.6 on Serial1/0 from FULL to DOWN, Neighbor Down: Interface down or detached
Mar 1 03:25:54.168: %OSPF-5-ADJCHG: Process 1, Nbr 5.5.5.5 on Serial1/0 from FULL to DOWN, Neighbor Down: Interface down or detached
Mar 1 03:25:54.212: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on FastEthernet0/1 from FULL to DOWN, Neighbor Down: Interface down or detached

After 2 minutes, the adjacencies should come back up, you can view th time remaining as follows:

R4#show ip ospf | section Maximum number of non self-generated
Maximum number of non self-generated LSA allowed 15
Threshold for warning message 50%
Ignore-time 2 minutes, reset-time 5 minutes
Ignore-count allowed 1, current ignore-count 1
Ignoring all neighbors due to max-lsa limit, time remaining: 00:01:06

R4#show ip ospf | section Maximum number of non self-generated
Maximum number of non self-generated LSA allowed 15
Threshold for warning message 50%
Ignore-time 2 minutes, reset-time 5 minutes
Ignore-count allowed 1, current ignore-count 1
Ignoring all neighbors due to max-lsa limit, time remaining: 00:00:25

Adjacencies come back up after two minutes and the warning threshold is reached:

Mar 1 03:27:57.127: %OSPF-4-OSPF_MAX_LSA_THR: Threshold for maximum number of non self-generated LSA has been reached "ospf 1" - 7 LSAs
Mar 1 03:27:57.127: %OSPF-5-ADJCHG: Process 1, Nbr 6.6.6.6 on Serial1/0 from LOADING to FULL, Loading Done
Mar 1 03:28:01.367: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on FastEthernet0/1 from LOADING to FULL, Loading Done
Mar 1 03:28:24.531: %OSPF-5-ADJCHG: Process 1, Nbr 5.5.5.5 on Serial1/0 from LOADING to FULL, Loading Done

R4#show ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface
5.5.5.5 0 FULL/ - 00:01:59 172.12.45.5 Serial1/0
6.6.6.6 0 FULL/ - 00:01:59 172.12.45.6 Serial1/0
3.3.3.3 1 FULL/BDR 00:00:33 172.12.34.3 FastEthernet0/1

Let's look at the next timer in effect:

R4#show ip ospf | section Maximum number of non self-generated
Maximum number of non self-generated LSA allowed 15
Threshold for warning message 50%
Ignore-time 2 minutes, reset-time 5 minutes
Ignore-count allowed 1, current ignore-count 1 - time remaining: 00:03:12

Notice that we have already ignored our neighbors once - this was the ignore-count in the configuration. We cannot ignore our neighbors again until the ignore count is reset at 5 minutes. While we waiting for the timer to count down, R4 has normal adjacencies with all it's neighbors and a full LSDB.

Roughly 5 minutes later and nothing has happened again:

R4#show clock
03:35:09.169 UTC Fri Mar 1 2002

R4#show ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface
5.5.5.5 0 FULL/ - 00:01:34 172.12.45.5 Serial1/0
6.6.6.6 0 FULL/ - 00:01:45 172.12.45.6 Serial1/0
3.3.3.3 1 FULL/BDR 00:00:39 172.12.34.3 FastEthernet0/1

R4#show ip ospf | section Maximum number of non self-generated
Maximum number of non self-generated LSA allowed 15
Threshold for warning message 50%
Ignore-time 2 minutes, reset-time 5 minutes
Ignore-count allowed 1, current ignore-count 0

hmmm....what gives?

Well it turns out I lost an LSA somewhere a long the way so I still had 15 after adjacencies came back up! Very strange...I quickly created a new one on R2 and we'll try to catch up to where we were...

I'm back waiting for the 5 minute timer to expire. In the meantime adjacencies are up and max-lsa limit has been reached again.

Mar 1 03:41:31.451: %OSPF-4-OSPF_MAX_LSA: Maximum number of non self-generated
LSA has been exceeded "ospf 1" - 16 LSAs

R4#show ip ospf | section Maximum number of non self-generated
Maximum number of non self-generated LSA allowed 15
Threshold for warning message 50%
Ignore-time 2 minutes, reset-time 5 minutes
Ignore-count allowed 1, current ignore-count 1 - time remaining: 00:04:47

R4#show ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface
5.5.5.5 0 FULL/ - 00:01:46 172.12.45.5 Serial1/0
6.6.6.6 0 FULL/ - 00:01:57 172.12.45.6 Serial1/0
3.3.3.3 1 FULL/BDR 00:00:31 172.12.34.3 FastEthernet0/1

But wait! Adjacencies come down about a minute later:

R4#
Mar 1 03:42:31.575: %OSPF-5-ADJCHG: Process 1, Nbr 5.5.5.5 on Serial1/0 from FULL to DOWN, Neighbor Down: Interface down or detached
Mar 1 03:42:31.579: %OSPF-5-ADJCHG: Process 1, Nbr 6.6.6.6 on Serial1/0 from FULL to DOWN, Neighbor Down: Interface down or detached
Mar 1 03:42:31.627: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on FastEthernet0/1 from FULL to DOWN, Neighbor Down: Interface down or detached

Notice the last line:

R4#show ip ospf | section Maximum number of non self-generated
Maximum number of non self-generated LSA allowed 15
Threshold for warning message 50%
Ignore-time 2 minutes, reset-time 5 minutes
Ignore-count allowed 1, current ignore-count 2
Permanently ignoring all neighbors due to max-lsa limit

R4#show ip ospf neighbor

R4#

The configured ignore-count is 1 so upon reaching the max-lsa limit the second time, all neighbors are now ignored until ospf is cleared manually. Well this was a pretty helter skelter lab. I hope it gives you some idea of what overload protection does, and maybe gives you some ideas for testing it yourself.

OSPF - Limiting number of redistributed routes

This short lab uses the topology of previous OSPF posts:

R2 ---> R5 in area 25
R5 ---> R4 in area 0
R4 ---> R3 in area 345

Area 25 is an NSSA.
R2 is an ASBR redistruting connected and static routes into OSPF:

R2#show run | section router ospf
router ospf 1
log-adjacency-changes
area 25 nssa
redistribute connected subnets tag 100
redistribute static metric-type 1 subnets tag 200
network 172.12.25.0 0.0.0.255 area 25

static: 1.1.1.1, 192.168.254.0
connected 2.2.2.2-5, 172.12.123.0

These routes are tagged with 100 and 200 respectively for easy filtering. Below is the database on R4, we have 7 LSA's:

R4#show ip ospf database | inc 100|200
1.1.1.1 5.5.5.5 48 0x80000001 0x00BD82 200
2.2.2.2 5.5.5.5 48 0x80000001 0x00041C 100
2.2.2.3 5.5.5.5 48 0x80000001 0x00F925 100
2.2.2.4 5.5.5.5 48 0x80000001 0x00EF2E 100
2.2.2.5 5.5.5.5 48 0x80000001 0x00E537 100
172.12.123.0 5.5.5.5 48 0x80000001 0x00BC37 100
192.168.254.0 5.5.5.5 48 0x80000001 0x004596 200

Let's configure a redistribution limit on R2:

R2(config)#router ospf 1

R2(config-router)#redistribute maximum-prefix ?
<1-4294967295> Maximum number of IP prefixes redistributed

R2(config-router)#redistribute maximum-prefix 4 ?
<1-100> Threshold value (%) at which to generate a warning message
warning-only Only give warning message when limit is exceeded

R2(config-router)#redistribute maximum-prefix 4 50

Now wait a few moments and the following message appears on R2:

Mar 1 02:21:01.775: %IPRT-4-REDIST_THR_PFX: Redistribution prefix threshold has been reached "ospf 1" - 2 prefixes
Mar 1 02:21:01.783: %IPRT-4-REDIST_MAX_PFX: Redistribution prefix limit has been reached "ospf 1" - 4 prefixes

The threshold was reached at 50% of 4 (2 routes). The maximum limit was reached shortly thereafter. Let's check R4 to see how many external LSA's it has now:

R4#show ip ospf database | inc 100|200
1.1.1.1 5.5.5.5 92 0x80000001 0x00BD82 200
2.2.2.2 5.5.5.5 92 0x80000001 0x00041C 100
2.2.2.3 5.5.5.5 92 0x80000001 0x00F925 100
2.2.2.4 5.5.5.5 92 0x80000001 0x00EF2E 100

Only 4 show up the rest have been filtered. We can also set up R2 to only give a warning and not actually limit the redistribution of the routes:

R2(config-router)#redistribute maximum-prefix 4 50 warning-only
Mar 1 02:23:53.487: %IPRT-4-REDIST_THR_PFX: Redistribution prefix threshold has been reached "ospf 1" - 2 prefixes
Mar 1 02:23:53.495: %IPRT-4-REDIST_MAX_PFX: Redistribution prefix limit has been reached "ospf 1" - 4 prefixes

Warning only, no filtering:

R4#show ip ospf database | inc 100|200
1.1.1.1 5.5.5.5 43 0x80000001 0x00BD82 200
2.2.2.2 5.5.5.5 43 0x80000001 0x00041C 100
2.2.2.3 5.5.5.5 43 0x80000001 0x00F925 100
2.2.2.4 5.5.5.5 43 0x80000001 0x00EF2E 100
2.2.2.5 5.5.5.5 43 0x80000001 0x00E537 100
172.12.123.0 5.5.5.5 43 0x80000001 0x00BC37 100
192.168.254.0 5.5.5.5 43 0x80000001 0x004596 200

Note that this command doesn't require you to clear ospf but it can take a few moments (20+ seconds) if you don't.

OSPF - when you should suppress forward address in type7/5 translation

This topic really piqued my curiosity. You can see from my previous post that I know how to do this but could not think of an example of when it would be necessary. Well now I have found one. After reading a bunch of cisco doc's I came up with this scenario:


R2 ---> R5 in area 25
R5 ---> R4 in area 0
R4 ---> R3 in area 345

Area 25 is an NSSA.
R2 is an ASBR redistruting a static route to R1's Loopback into OSPF:

R2#show run | section router ospf|ip route
router ospf 1
log-adjacency-changes
area 25 nssa
redistribute connected subnets
redistribute static subnets
network 172.12.25.0 0.0.0.255 area 25
ip route 1.1.1.1 255.255.255.255 172.12.123.1
ip route 192.168.254.0 255.255.255.0 Null0

R2#ping 1.1.1.1
Translating "1.1.1.1"

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/31/84 ms

R2 generates a type 7 LSA for this route:

R2#show ip ospf database nssa-external 1.1.1.1

OSPF Router with ID (2.2.2.5) (Process ID 1)

Type-7 AS External Link States (Area 25)

LS age: 114
Options: (No TOS-capability, Type 7/5 translation, DC)
LS Type: AS External Link
Link State ID: 1.1.1.1 (External Network Number )
Advertising Router: 2.2.2.5
LS Seq Number: 80000002
Checksum: 0x337F
Length: 36
Network Mask: /32
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 172.12.25.2
External Route Tag: 0

R5 converts this to a type 5 LSA and eventually winds up in area 345 on R3:

R3#show ip ospf database external 1.1.1.1

OSPF Router with ID (3.3.3.3) (Process ID 1)

Type-5 AS External Link States

LS age: 69
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 1.1.1.1 (External Network Number )
Advertising Router: 5.5.5.5
LS Seq Number: 80000004
Checksum: 0x7B36
Length: 36
Network Mask: /32
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 172.12.25.2
External Route Tag: 0

Notice the forwarding address for this LSA is 172.12.25.2. This address is being filtered on R4 as follows:

R4(config)#ip prefix-list BLOCK25 deny 172.12.25.0/24
R4(config)#ip prefix-list BLOCK25 permit 0.0.0.0/0 le 32
R4(config)#router ospf 1
R4(config-router)#area 345 filter-list prefix BLOCK25 in

R3#show ip ospf data summ 172.12.25.0

OSPF Router with ID (3.3.3.3) (Process ID 1)

R3#show ip route 1.1.1.1
% Network not in table
R3#

R3 cannot put this route in the route table if it does not have an LSA for the forwarding address. The only way to let R3 install this route is to make the forward address of the type 5 LSA for 1.1.1.1 to 0.0.0.0. This way R3 will forward traffic to the advertising router.

Let's try it:

R5(config)#router ospf 1
R5(config-router)#area 25 nssa translate type7 suppress-fa

Now let's look on R3:

R3#show ip ospf data ex 1.1.1.1

OSPF Router with ID (3.3.3.3) (Process ID 1)

Type-5 AS External Link States

Routing Bit Set on this LSA
LS age: 326
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 1.1.1.1 (External Network Number )
Advertising Router: 5.5.5.5
LS Seq Number: 80000007
Checksum: 0x176B
Length: 36
Network Mask: /32
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 0.0.0.0
External Route Tag: 0

R3#show ip route 1.1.1.1
Routing entry for 1.1.1.1/32
Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 65599
Redistributing via eigrp 1
Advertised by eigrp 1
Last update from 172.12.34.4 on FastEthernet0/1, 00:00:06 ago
Routing Descriptor Blocks:
* 172.12.34.4, from 5.5.5.5, 00:00:06 ago, via FastEthernet0/1
Route metric is 20, traffic share count is 1

Ta-da!