Frame-relay Fragmentation

R4 --- FR CLOUD --- R6

Both ends configured:

R6(config)#int s1/1
R6(config-if)#frame-relay fragment 200 end-to-end
R6(config-if)#^Z

R6#ping 172.14.45.4 size 8000

Type escape sequence to abort.
Sending 5, 8000-byte ICMP Echos to 172.14.45.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 676/756/796 ms

R6#show frame-relay fragment
interface dlci frag-type size in-frag out-frag dropped-frag
Se1/1 604 end-to-end 200 220 220 0
Se1/1 605 end-to-end 200 0 0 0

Frame-relay Compression

Compression must be configured on both ends for it to be enabled:

R5 --- FR CLOUD --- R6

R6(config)#interface s1/1
R6(config-if)#frame-relay map ip 172.14.45.5 605 payload-compression FRF9 stac

R6#ping 172.14.45.5

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

R6#show compress
Serial1/1 - DLCI: 605
Compression not active
uncompressed bytes xmt/rcv 0/0
compressed bytes xmt/rcv 0/0
Compressed bytes sent: 0 bytes 0 Kbits/sec
Compressed bytes recv: 0 bytes 0 Kbits/sec
1 min avg ratio xmt/rcv 0.000/0.000
5 min avg ratio xmt/rcv 0.000/0.000
10 min avg ratio xmt/rcv 0.000/0.000
no bufs xmt 0 no bufs rcv 0
resyncs 0
Additional Stac Stats:
Transmit bytes: Uncompressed = 0 Compressed = 0
Received bytes: Compressed = 0 Uncompressed = 0

Now on R5:

R6(config)#interface s1/0
R6(config-if)#frame-relay map ip 172.14.45.6 506 payload-compression FRF9 stac

Check R6 and see compression is enabled:

R6#ping 172.14.45.5

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

R6#show compress
Serial1/1 - DLCI: 605
Software compression enabled
uncompressed bytes xmt/rcv 1232/1232
compressed bytes xmt/rcv 381/382
Compressed bytes sent: 381 bytes 0 Kbits/sec ratio: 3.233
Compressed bytes recv: 382 bytes 0 Kbits/sec ratio: 3.225
1 min avg ratio xmt/rcv 0.055/0.057
5 min avg ratio xmt/rcv 0.113/0.118
10 min avg ratio xmt/rcv 0.113/0.118
no bufs xmt 0 no bufs rcv 0
resyncs 0
Additional Stac Stats:
Transmit bytes: Uncompressed = 0 Compressed = 290
Received bytes: Compressed = 291 Uncompressed = 0

CCIE Home Lab - Rack Diagram

I'm almost done building my rack. I thought a diagram will help when I get ready to mount the devices and cable them. Here is what I've come up with. I excluded connections between switches because I have another diagram for those.

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!

OSPF - Type 5 and Type 7 LSA Comparison

R2 --- R5 is in standard area 25.
R5 is and ABR connected to area 0 as well.
R2 is redistributing connected interfaces.
These show up as E2 routes on R5.

Here is how he type LSA for R2's loopback 2.2.2.2:

R5# show ip ospf database external 2.2.2.2

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

Type-5 AS External Link States

Routing Bit Set on this LSA
LS age: 121
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 2.2.2.2 (External Network Number )
Advertising Router: 2.2.2.5
LS Seq Number: 80000001
Checksum: 0x3D50
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

Now Let's convert area 25 to an nssa area:

R5(config)#router ospf 1
R5(config-router)#area 25 nssa

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

Here is how the type 7 LSA looks, can you see the difference?

R2#show ip ospf database nssa-external 2.2.2.2

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

Type-7 AS External Link States (Area 25)

LS age: 85
Options: (No TOS-capability, Type 7/5 translation, DC)
LS Type: AS External Link
Link State ID: 2.2.2.2 (External Network Number )
Advertising Router: 2.2.2.5
LS Seq Number: 80000001
Checksum: 0x7A8
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 before flooding to area 0. Here's how it looks now:

R5# show ip ospf database external 2.2.2.2

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

Type-5 AS External Link States

LS age: 100
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 2.2.2.2 (External Network Number )
Advertising Router: 5.5.5.5
LS Seq Number: 80000001
Checksum: 0x535D
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 that the forwarding address is listed as 0.0.0.0 in the first example. After area 25 was changed to a nssa, then the forwarding address appeared in the type 7 lsa and in the translated type 5 lsa.

Also notice the type 7 lsa has an advertising router of 2.2.2.5 (R2's router-id) but the type is advertised by R5 for flooding into area 0 and beyond. In the original type 5 lsa the advertising router was 2.2.2.5 throughout the ospf domain. Take a look below at R3 in a distant area 345.

When area 25 is standard area:

R3#show ip osp database external 2.2.2.2 | inc Advertising
Advertising Router: 2.2.2.5

When area 25 is nssa:

R3#show ip osp database external 2.2.2.2 | inc Advertising
Advertising Router: 5.5.5.5

We can also supress the advertisement of the forwarding address with this command on R5, the ABR:

R5(config-router)#are 25 nssa translate type7 suppress-fa

R3#show ip osp database external 2.2.2.2 | inc Forward
Forward Address: 0.0.0.0

Why would we do this? not exactl sure right now, but I have read the when the forward address is 0.0.0.0 then the router sends the packet to the advertising router...it seems this would have happened anyway...right?

I remember running into problems with type7/5 translation when I was doing labs studying for the CCNP routing exam. There were some interesting issues and I'll do some more research. This was just a quick lab to see what happens to external lsa depending on the type of area.

Here's a link that explains more:

When to Suppress OSPF Forwarding Address in Translated Type-5 LSAs

Book: OSPF Network Design Solutions

I am reading the 2nd edition of this book and I recommend it to anyone who wants to know more about OSPF. I skipped chapter 1 and read chapters 2 and 3 today. A lot of this stuff was review from Routing TCP/IP volume 1 and from what I read of the RFC for OSPFv2. However I did learn some new things, so here is a quick rundown of what I read or found out while labbing and reading:

·You can filter out LSAs intra area with the following commands:
ip ospf database-filter all out (interface mode)
neighbor x.x.x.x database-filter out (router ospf mode)

·The BDR is elected before the DR, then promoted to DR if there is not a current DR.

·When summary routes or external LSA's change, only a partial SPF calculation is required. Full SPF calculations are run when there is a type 1 LSA change.

·Debug the SPF calculation with the following:
debug ip ospf spf inter
debug ip ospf spf external

·Stub area flag is known as the E bit

·External Summary LSA's are not specific to an area. In other words, they are contained in their own section in the "show ip ospf database" command output.

·If forwarding address is 0.0.0.0 in a type 5 LSA, then traffic is forward to the originator of the advertisement.

·LSA group pacing:
timers pacing lsa-group (router ospf mode)

There are also some real good case studies at the end of each chapter. The more I read, the more I will post.

OSPF - Using the max-metric router-lsa command

Don't exactly have all the theory down or a "real-world view" about this one but I wanted to do a lab so here it is:



R1 --- R3 --- R4 --- BACKBONE AREA 0 ---> other routers/areas

R1 connects to R3 on subnet 172.12.123.0/24
R3 connects to R4 on subnet 172.12.34.0/24
All interfaces are in area 345 except the right side of R4.
R4 is an ABR connected to area 0

R4 is advertising a type 3 LSA for 172.12.123.0 into area 0:

R4#show ip ospf database summary 172.12.123.0

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

Summary Net Link States (Area 0)

LS age: 1
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 172.12.123.0 (summary Network Number)
Advertising Router: 4.4.4.4
LS Seq Number: 80000001
Checksum: 0x8175
Length: 28
Network Mask: /24
TOS: 0 Metric: 2

Now suppose R3 didn't want to be a transit network for 172.12.123.0 and the other links connected to R1. Perhaps it just wants to be a backup link. We could have R3 set a maximum metric on that LSA ensuring that any other LSA would be more preferred:

R3(config)#router ospf 1
R3(config-router)#max-metric router-lsa

Verify:

R3#show ip ospf
Routing Process "ospf 1" with ID 3.3.3.3
Start time: 00:00:29.944, Time elapsed: 06:24:37.160
Supports only single TOS(TOS0) routes
Supports opaque LSA
Supports Link-local Signaling (LLS)
Supports area transit capability
It is an autonomous system boundary router
Redistributing External Routes from,
eigrp 1
Originating router-LSAs with maximum metric
Condition: always, State: active

(output omitted)

Notice the high metric on R4 now:

R4#show ip ospf database summary 172.12.123.0

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

Summary Net Link States (Area 0)

LS age: 43
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 172.12.123.0 (summary Network Number)
Advertising Router: 4.4.4.4
LS Seq Number: 80000006
Checksum: 0x6B87
Length: 28
Network Mask: /24
TOS: 0 Metric: 65536 <-- MAXIMUM!

Now if there are any other paths to 172.12.123.0, other OSPF routers in the domain are more likely to use those.

OSPF - Filtering type 3 LSAs

R3 and R4 share the same Ethernet segment 172.12.34.0 via their fastethernet0/1 interfaces

Router IDs:
R3 = 3.3.3.3
R4 = 4.4.4.4

The link between R3 and R4 is in area 345 and R4 is an ABR connected to area 0.

Below is a snapshot of the area 345 LSDB. You can see the type 3 LSAs that R3 is getting from R4:

R3#show ip ospf database | begin Summary Net Link States

Summary Net Link States (Area 345)

Link ID ADV Router Age Seq# Checksum
6.6.6.6 4.4.4.4 545 0x80000001 0x00884B
172.12.25.0 4.4.4.4 545 0x80000001 0x00AC2E
172.12.45.4 4.4.4.4 555 0x80000001 0x00A2A0
172.12.45.5 4.4.4.4 545 0x80000001 0x001BE6
172.12.45.6 4.4.4.4 545 0x80000001 0x0011EF

(output omitted)

Suppose we want to filter the host route LSAs (#1,3,4 and 5 in the list above). Here's how we could do it:

On R4:

R4(config)#ip prefix-list BLOCK32 deny 0.0.0.0/0 ge 32
R4(config)#ip prefix-list BLOCK32 permit 0.0.0.0/0 le 32
R4(config-router)#area 0 filter-list prefix BLOCK32 out

Clear the OSPF process on R3 and now let's have a look:

R3#show ip ospf database | begin Summary Net
Summary Net Link States (Area 345)

Link ID ADV Router Age Seq# Checksum
172.12.25.0 4.4.4.4 1074 0x80000001 0x00AC2E

(output omitted)

You can verify on R4 like this:

R4#show ip ospf | section Area
Area BACKBONE(0)
Area has no authentication
Area ranges are
Area-filter BLOCK32 out
Area 345
Area has no authentication
Area ranges are
R4#

Of course this did break some connectivity in my lab, so be careful when you use this :)

OSPF - Filtering LSAs (intra-area)

R3 and R4 share the same Ethernet segment 172.12.34.0 via their fastethernet0/1 interfaces

Router IDs:
R3 = 3.3.3.3
R4 = 4.4.4.4

R4 has the following LSAs from R3:

R4# show ip ospf database adv-router 3.3.3.3

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

Router Link States (Area 345)

Link ID ADV Router Age Seq# Checksum Link count
3.3.3.3 3.3.3.3 7 0x80000012 0x00C568 2

Type-5 AS External Link States

Link ID ADV Router Age Seq# Checksum Tag
172.12.123.0 3.3.3.3 550 0x8000000C 0x00D381 0

On R3 we enter the following command:

R3(config)#int f0/1
R3(config-if)#ip ospf database-filter all out
R3(config-if)#
*Mar 1 04:41:41.162: %OSPF-5-ADJCHG: Process 1, Nbr 4.4.4.4 on FastEthernet0/1
from FULL to DOWN, Neighbor Down: Interface down or detached
*Mar 1 04:41:41.382: %OSPF-5-ADJCHG: Process 1, Nbr 4.4.4.4 on FastEthernet0/1
from LOADING to FULL, Loading Done

Notice the adjacency bounced. However, R4 still has LSAs from R3 in it's database (they haven't been aged):

R4# show ip ospf database adv-router 3.3.3.3

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

Router Link States (Area 345)

Link ID ADV Router Age Seq# Checksum Link count
3.3.3.3 3.3.3.3 59 0x80000012 0x00C568 2

Type-5 AS External Link States

Link ID ADV Router Age Seq# Checksum Tag
172.12.123.0 3.3.3.3 603 0x8000000C 0x00D381 0

We must clear the ospf process on R4:

R4#clear ip ospf process
Reset ALL OSPF processes? [no]: yes
Mar 1 04:52:47.442: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on FastEthernet0/1 f
rom FULL to DOWN, Neighbor Down: Interface down or detached
Mar 1 04:52:47.806: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on FastEthernet0/1 f
rom LOADING to FULL, Loading Done

Now the type 1 router LSA from R3 is gone from R4's LSDB:

R4# show ip ospf database adv-router 3.3.3.3

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

Type-5 AS External Link States

Link ID ADV Router Age Seq# Checksum Tag
172.12.123.0 3.3.3.3 674 0x8000000C 0x00D381 0

But the type 5 LSA still exists...Why? Don't know yet, stay tuned...

WCCP notes

Well I saw this topic on the blueprint and I don't think I have enough equipment to do a wccp lab so for now I'll just make some notes and post them here:

WCCPv1
---------
-Single router serves a cluster
-Cache engine is configured with ip address of control router (max 32)
-Cache engines send ip's to router via control port udp 2048
-Control creates a cluster view, sends to cache engines
-Lead cache engine selected, decides how traffic is redirected.
-HTTP only

WCCPv2
---------
-Multiple routers can server a cluster
-Service group: routers + cache engines
-Unicast or multicast control (ip wccp group-listen)
-Non-HTTP support, TCP and UDP
-MD5 security
-Error handling keeps track of cache misses
-Load distribution (hot spot handling, load balancing, load shedding)
-IP only
-Multicast TTL must be 15 or lower
-32 cache engines and 32 routers max per service group
-Dynamic services are defined by the cache engines

Configuration
--------------
Router(config)# ip wccp version 2
Router(config)# ip wccp {web-cache | service-number} [group-address groupaddress] [redirect-list access-list] [group-list access-list] [password password]
Router(config)# interface type number
Router(config-if)# ip wccp {web-cache | service-number} redirect {out | in}

Exclude an interface from redirecting inbound traffic:
Router(config-if)# ip wccp redirect exclude in

Debugging IPv6 Neighbor Discovery

R1 and R2 are on the same LAN segment via their f0/0 interfaces.

IPv6 addressing:

R1(config)#interface f0/0
R1(config-if)#ipv6 address 2001::1/64
R1(config-if)#ipv6 address FE80::1 link-local

R2(config)#interface f0/0
R2(config-if)#ipv6 address 2001::2/64
R2(config-if)#ipv6 address FE80::2 link-local

Let's also enable ipv6 icmp debugging since that what ipv6 uses instead of ARP tp discover neighbors:

R1#debug ipv6 icmp
ICMP packet debugging is on

R2#debug ipv6 icmp
ICMP packet debugging is on

Shut both interfaces down and bring them up at the same time. Here is what we see on R1:

R1#
*Mar 1 00:35:28.615: ICMPv6: Received ICMPv6 packet from FE80::2, type 136
*Mar 1 00:35:29.695: ICMPv6: Received ICMPv6 packet from 2001::2, type 136

R1 has received icmp type 136 messages from R2's ipv6 address and ipv6 link-local address. R2 will receive the same messages. However, each router still has not "discovered" the other router (in other words, the ipv6 to layer 2 mac address resolution has not taken place)

R1#show ipv6 neighbors
R1#

Let's ping from R1:

R1#ping ipv6 2001::2 repeat 1

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

on R1:

Jun 11 21:26:11.569: ICMPv6: Sending echo request to 2001::2
Jun 11 21:26:11.749: ICMPv6: Received ICMPv6 packet from 2001::2, type 136
Jun 11 21:26:11.813: ICMPv6: Received echo reply from 2001::2

on R2:

Jun 11 21:26:11.299: ICMPv6: Received ICMPv6 packet from 2001::1, type 135
Jun 11 21:26:11.343: ICMPv6: Received echo request from 2001::1
Jun 11 21:26:11.343: ICMPv6: Sending echo reply to 2001::1

Some of these things seem a bit out of sequence but let's analyze a little further. Specifically let's focus on icmpv6 message types 135 and 136. Looking up these codes at http://www.iana.org/assignments/icmpv6-parameters you will see that these are Neighbor Solicitation and Advertisement messages.

Here's the breakdown:

· When R1 sends a ping to 2001::2 it realizes it doesn't have the MAC address to put in that packet.
· It sends a icmpv6 type 135 message to FF02::1:FF00:2 which is the solicited-node multicast address for 2001::2
· R2 is listening to this address because for every ipv6 unicast address it owns, it listens for the corresponding solicited-node multicast address.

You can verify this as follows, look under the "Joined group address(es)" section to see the multicast addresses that this router is listening for:

R2#show ipv6 int f0/0
FastEthernet0/0 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::2
Global unicast address(es):
2001::2, subnet is 2001::/64
Joined group address(es):
FF02::1
FF02::2
FF02::1:FF00:2
MTU is 1500 bytes
ICMP error messages limited to one every 100 milliseconds
ICMP redirects are enabled
ND DAD is enabled, number of DAD attempts: 1
ND reachable time is 30000 milliseconds

· R2 will then see this message and reply because it's address, 2001::2 is in the "target" section of the packet.
· R2 responds with a type 136 neighbor advertisement message and put its MAC address in the portion of the icmpv6 packet designed for this purpose (of course the source of the packet also has the MAC address, but this is not used for resolution).
· Then R1 can send the icmpv6 echo, and R2 will reply (R2 already resolved R1's address via the very first packet it received from R1 which had both the IPv6 and L2 MAC addresses)

Let's check those neighbors now:

R1#show ipv6 neighbors
IPv6 Address Age Link-layer Addr State Interface
2001::2 0 c201.0e8c.0000 REACH Fa0/0
FE80::2 10 c201.0e8c.0000 STALE Fa0/0

BGP aggregation with unsuppress-map option

In a previous post we learned how to aggregate BGP routes and use the suppress-map to suppress certain component routes from being advertised. With the summary-only option on the aggregate-address command you can suppress ALL component subnets. Suppose you had a bunch of component routes but only wanted to advertise a few, it would be a lot of work to make that big of a suppress-map. I don't know the exact reason behind this, but you can instead use the summary-only option of the aggregate-address command and then use an unsuppress-map to advertise the few component subnets you want. Here's how:

Topology:
R1 [AS 100] connects to R2 [AS 200]

R1 is currently summarizing a bunch of subnets in the 1.0.0.0/8 range.

R1# show ip route | in C
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
C 1.1.1.1/32 is directly connected, Loopback0
C 1.3.3.3/32 is directly connected, Loopback3
C 1.2.2.2/32 is directly connected, Loopback2
C 1.5.5.5/32 is directly connected, Loopback5
C 1.4.4.4/32 is directly connected, Loopback4
C 1.7.7.7/32 is directly connected, Loopback7
C 1.6.6.6/32 is directly connected, Loopback6

R1 is configured as such:

router bgp 100
no synchronization
bgp log-neighbor-changes
network 1.1.1.1 mask 255.255.255.255
network 1.2.2.2 mask 255.255.255.255
network 1.3.3.3 mask 255.255.255.255
network 1.4.4.4 mask 255.255.255.255
network 1.5.5.5 mask 255.255.255.255
aggregate-address 1.0.0.0 255.0.0.0 summary-only
neighbor 172.12.12.2 remote-as 200
neighbor 172.12.14.4 remote-as 100

The following route shows up on R2:

R2#show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
* 1.0.0.0 172.12.23.3 0 300 100 i
*> 172.12.12.1 0 100 i

As you can see we are supressing all of the 1.0.0.0 subnets. Suppose we wanted to advertise one of the subnets as well, to do so we can use the unsuppress-map option on the neighbor command.

On R1:

R1(config)#access-list 12 permit 1.1.1.1
R1(config)#access-list 12 permit 1.2.2.2
R1(config)#access-list 12 permit 1.3.3.3
R1(config)#route-map ALLOW
R1(config-route-map)#match ip address 12
R1(config-route-map)#exit
R1(config)#router bgp 100
R1(config-router)#neighbor 172.12.12.2 unsuppress-map ALLOW

Clear BGP:

R1#clear ip bgp *
R1#
00:41:47: %BGP-5-ADJCHANGE: neighbor 172.12.12.2 Down User reset
00:42:28: %BGP-5-ADJCHANGE: neighbor 172.12.12.2 Up

Now on R2 we have "unsuppressed" 3 routes:

R2#show ip bgp | inc 1\.
* 1.0.0.0 172.12.23.3 0 300 100 i
*> 1.1.1.1/32 172.12.12.1 0 0 100 i
*> 1.2.2.2/32 172.12.12.1 0 0 100 i
*> 1.3.3.3/32 172.12.12.1 0 0 100 i

BGP aggregation with suppress-map

This scenario involves use of the suppress-map with BGP aggregate-address command. It is fairly simple to understand but I could use the practice.

R1 is getting the following routes from R2 in AS 200:

R1#show ip bgp | Begin Network
Network Next Hop Metric LocPrf Weight Path
*> 2.2.2.2/32 172.12.12.22 0 0 200 i
r> 2.2.2.3/32 172.12.12.22 0 0 200 i
*> 200.1.1.2/32 172.12.12.22 0 0 200 i
*> 200.2.2.2/32 172.12.12.22 0 0 200 i
*> 200.3.3.2/32 172.12.12.22 0 0 200 i

On R2 we can configure aggregation with the following command:

R2(config-router)#aggregate-address 200.0.0.0 255.0.0.0

Without clearing BGP, here is R1's BGP table with the aggregate 200.0.0.0/8:

R1#show ip bgp | Begin Network
Network Next Hop Metric LocPrf Weight Path
*> 2.2.2.2/32 172.12.12.22 0 0 200 i
r> 2.2.2.3/32 172.12.12.22 0 0 200 i
*> 200.0.0.0/8 172.12.12.22 0 0 200 i
*> 200.1.1.2/32 172.12.12.22 0 0 200 i
*> 200.2.2.2/32 172.12.12.22 0 0 200 i
*> 200.3.3.2/32 172.12.12.22 0 0 200 i

Suppose we wanted to suppress only some of the "component routes", but not all. With the summary-only keyword we would suppress all, but with a suppress-map we can supress a few.

on R2 we add the following:

access-list 50 permit 200.1.1.2
access-list 50 permit 200.3.3.2
!
route-map BLOCK permit 10
match ip address 50
!
router bgp 200
aggregate-address 200.0.0.0 255.0.0.0 suppress-map BLOCK
!

Note that the access-list "permits" the networks and the supress-map matches whatever networks are permitted by the ACL and suppresses them.

Now on R1 we have:

R1#show ip bgp | Begin Network
Network Next Hop Metric LocPrf Weight Path
*> 2.2.2.2/32 172.12.12.22 0 0 200 i
r> 2.2.2.3/32 172.12.12.22 0 0 200 i
*> 200.0.0.0/8 172.12.12.22 0 0 200 i
*> 200.2.2.2/32 172.12.12.22 0 0 200 i

NTP authentication

This is scenario 3 dealing with NTP and in this post I will set up NTP authentication. Remember that the purpose is for the client to authenticate the server. First will make sure NTP is synchronized on the client. Next, we will turn on authentication on the client only until the clocks become unsynchronized. Finally, we will configure the server with the appropriate key and make sure the client is synchronized again.

We use the same topology as the other NTP scenarios:
R4, R5 and R6 connected via full mesh frame-relay on subnet 172.12.45.0/24

Let's make sure R6, the master, is synchronized first:

R6#show clock
20:14:37.215 MDT Mon Jun 2 2008

R6#show ntp status | inc Clock is
Clock is synchronized, stratum 2, reference is 127.127.7.1

R4:

R4#show ntp status | in Clock
Clock is synchronized, stratum 3, reference is 172.12.45.6

and R5:

R5#show ntp status | inc Clock
Clock is synchronized, stratum 3, reference is 172.12.45.6

Let's configure authentication on R4:

R4(config)#ntp authenticate
R4(config)#ntp authentication-key 1 md5 cisco
R4(config)#ntp trusted-key 1
R4(config)#ntp server 172.12.45.6 key 1

R4#debug ntp validity
NTP peer validity debugging is on
R4#debug ntp authentication
NTP authentication debugging is on

In a few moments we get these debug messages:

R4(config)#
Jun 3 03:24:49.759: NTP: packet from 172.12.45.6 failed validity tests 10
Jun 3 03:24:49.763: Authentication failed
R4(config)#

What's strange is that R4 is still synchronized with R6:

R4#show ntp status
Clock is synchronized, stratum 3, reference is 172.12.45.6

So I waited about 10 minutes (it seemed that long) and now R4 is unsynchronized:

R4#show ntp status | inc Clock
Clock is unsynchronized, stratum 16, no reference clock

Now let's configure NTP authentication on R6:

R6(config)#ntp authenticate
R6(config)#ntp authentication-key 1 md5 cisco

On R4 I will set up some debugging, a lot of the output doesn't make much sense, but here it is:

R4#debug ntp packets
NTP packets debugging is on

!! HERE R4 TRANSMITS A PACKET WITH AUTHENTICATION-KEY 1

.Jun 3 03:36:10.711: NTP: xmit packet to 172.12.45.6:
.Jun 3 03:36:10.715: leap 3, mode 3, version 3, stratum 0, ppoll 64
.Jun 3 03:36:10.715: rtdel 0D4E (51.971), rtdsp 05CD (22.659), refid AC0C2D06 (172.12.45.6)
.Jun 3 03:36:10.719: ref CBEF37C1.C8A9606E (20:23:45.783 MDT Mon Jun 2 2008)
.Jun 3 03:36:10.719: org CBEF3A6A.BF8D3204 (20:35:06.748 MDT Mon Jun 2 2008)
.Jun 3 03:36:10.723: rec CBEF3A6A.C784D317 (20:35:06.779 MDT Mon Jun 2 2008)
.Jun 3 03:36:10.723: xmt CBEF3AAA.B614DB93 (20:36:10.711 MDT Mon Jun 2 2008)
.Jun 3 03:36:10.727: Authentication key 1

!! HERE R4 RECEIVES A PACKET WITH AUTHENTICATION-KEY 1

.Jun 3 03:36:10.771: NTP: rcv packet from 172.12.45.6 to 172.12.34.4 on FastEthernet0/1:
.Jun 3 03:36:10.775: leap 0, mode 4, version 3, stratum 2, ppoll 64
.Jun 3 03:36:10.779: rtdel 0000 (0.000), rtdsp 0002 (0.031), refid 7F7F0701 (127.127.7.1)
.Jun 3 03:36:10.779: ref CBEF3A89.50E1C8AB (20:35:37.315 MDT Mon Jun 2 2008)
.Jun 3 03:36:10.783: org CBEF3AAA.B614DB93 (20:36:10.711 MDT Mon Jun 2 2008)
.Jun 3 03:36:10.783: rec CBEF3AAA.C3941C78 (20:36:10.763 MDT Mon Jun 2 2008)
.Jun 3 03:36:10.787: xmt CBEF3AAA.C39DD400 (20:36:10.764 MDT Mon Jun 2 2008)
.Jun 3 03:36:10.791: inp CBEF3AAA.C565D38F (20:36:10.771 MDT Mon Jun 2 2008)
.Jun 3 03:36:10.791: Authentication key 1

R4 is now synchronized:

R4#show ntp status
Clock is synchronized, stratum 3, reference is 172.12.45.6
nominal freq is 250.0000 Hz, actual freq is 250.0004 Hz, precision is 2**18
reference time is CBEF3AAA.C565D38F (20:36:10.771 MDT Mon Jun 2 2008)
clock offset is 22.8825 msec, root delay is 59.68 msec
root dispersion is 15897.92 msec, peer dispersion is 15875.02 msec

Let's check R5 to see if it is still synchronized:

R5#show ntp status | inc Clock
Clock is synchronized, stratum 3, reference is 172.12.45.6

As you can see, R5 is still synchronized because it is not requesting authentication from R6. R4 on the other sends the request with an authentication key and requires that the time-source, R6, does so as well.

Well, this lab went okay. I have had many problems with ntp authentication before. Initially, I thought I would have problems again when R4 was not un-synchronizing with R6 when we first set up a key on R4. Well, it took a few minutes, so I guess patience is this key. You can't afford to be too patient though, you only have 8 hours on lab day :)

OSPF - auto-cost reference-bandwidth

The default reference bandwidth for OSPF is 10^8 bps or 100Mbit. Increasing the reference-bandwidth allows a more granular OSPF design. If changed it should be changed on all routers in the OSPF domain.

The reason you would change the reference-bandwidth is that you may have link faster than 100M in your network. If you have Gigabit networks but are using the default reference-bandwidth, then Gigabit links are equal in cost to fast Ethernet.

This example uses serial interfaces, but it will allow you to get an idea of what this command does.

Here is our basic topology, with R1 and R2 connected via 1544K serial links.

R1 ---area0--- R2

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

1.0.0.0/32 is subnetted, 2 subnets
C 1.1.1.1 is directly connected, Loopback0
C 1.1.1.2 is directly connected, Loopback1
2.0.0.0/32 is subnetted, 1 subnets
O 2.2.2.2 [110/65] via 172.12.12.2, 00:08:50, Serial1/0
4.0.0.0/32 is subnetted, 1 subnets
O IA 4.4.4.4 [110/129] via 172.12.12.2, 00:08:50, Serial1/0
172.12.0.0/24 is subnetted, 2 subnets
C 172.12.12.0 is directly connected, Serial1/0
O IA 172.12.23.0 [110/128] via 172.12.12.2, 00:08:50, Serial1/0

R1#show ip ospf int s1/0 | inc Cost
Process ID 1, Router ID 1.1.1.1, Network Type POINT_TO_POINT, Cost: 64

Chaging the reference-bandwidth under the ospf process as follows:

R1(config)#router ospf 1
R1(config-router)#auto-cost reference-bandwidth 1000
% OSPF: Reference bandwidth is changed.
Please ensure reference bandwidth is consistent across all routers.
R1(config-router)#^Z

The cost of the interface has changed from 64 to 647

R1#show ip ospf int s1/0 | inc Cost
Process ID 1, Router ID 1.1.1.1, Network Type POINT_TO_POINT, Cost: 647

Here are the calculations:

100000000/1544000 = 64
1000000000/1544000 = 647

All routes have through this interface have a higher metric now:

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

1.0.0.0/32 is subnetted, 2 subnets
C 1.1.1.1 is directly connected, Loopback0
C 1.1.1.2 is directly connected, Loopback1
2.0.0.0/32 is subnetted, 1 subnets
O 2.2.2.2 [110/648] via 172.12.12.2, 00:01:30, Serial1/0
4.0.0.0/32 is subnetted, 1 subnets
O IA 4.4.4.4 [110/712] via 172.12.12.2, 00:01:30, Serial1/0
172.12.0.0/24 is subnetted, 2 subnets
C 172.12.12.0 is directly connected, Serial1/0
O IA 172.12.23.0 [110/711] via 172.12.12.2, 00:01:30, Serial1/0

OSPF - configuring the shortest hello interval

For super fast convergence in ospf, you can change the ospf timers to the minimal setting. This will turn out to be a dead time of 1 second and a sub-second hello time.

Topology:

R1 --- R2

R1:

R1(config)#int s1/0
R1(config-if)#ip ospf dead-interval minimal hello-multiplier 3

Notice the hello interval is now 333 milliseconds:

R1#show ip ospf interface s1/0
Serial1/0 is up, line protocol is up
Internet Address 172.12.12.1/24, Area 0
Process ID 1, Router ID 1.1.1.1, Network Type POINT_TO_POINT, Cost: 64
Transmit Delay is 1 sec, State POINT_TO_POINT,
Timer intervals configured, Hello 333 msec, Dead 1, Wait 1, Retransmit 5
oob-resync timeout 40
Hello due in 217 msec
Supports Link-local Signaling (LLS)
Index 1/1, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 1, maximum is 1
Last flood scan time is 0 msec, maximum is 4 msec
Neighbor Count is 0, Adjacent neighbor count is 0
Suppress hello for 0 neighbor(s)

R2:

R2(config)#int s1/0
R2(config-if)#ip ospf dead-interval ?
<1-65535> Seconds
minimal Set to 1 second

R2(config-if)#ip ospf dead-interval minimal ?
hello-multiplier Set multiplier for Hellos

R2(config-if)#ip ospf dead-interval minimal hello-multiplier ?
<3-20> Number of Hellos sent within 1 second

R2(config-if)#ip ospf dead-interval minimal hello-multiplier 3

R1#show ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface
2.2.2.2 0 FULL/ - 704 msec 172.12.12.2 Serial1/0
R1#show ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface
2.2.2.2 0 FULL/ - 936 msec 172.12.12.2 Serial1/0
R1#show ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface
2.2.2.2 0 FULL/ - 636 msec 172.12.12.2 Serial1/0

As you can see with the "show ip ospf neighbor" command, the dead time counts down from 1 second and is reset every 333 msec when it receives a hello.

Changing the dead interval on R1 reverts the hello time back to the default:

R1(config)#int s1/0
R1(config-if)#ip ospf dead-interval 50

R1#show ip ospf int s1/0
Serial1/0 is up, line protocol is up
Internet Address 172.12.12.1/24, Area 0
Process ID 1, Router ID 1.1.1.1, Network Type POINT_TO_POINT, Cost: 64
Transmit Delay is 1 sec, State POINT_TO_POINT,
Timer intervals configured, Hello 10, Dead 50, Wait 50, Retransmit 5
oob-resync timeout 50
Hello due in 00:00:04
Supports Link-local Signaling (LLS)
Index 1/1, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 1, maximum is 1
Last flood scan time is 0 msec, maximum is 4 msec
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 2.2.2.2
Suppress hello for 0 neighbor(s)

Pretty easy command, but it still helps labbing it, now I should never forget it...