Archive
Why OSPF FA is only set on broadcast networks
A friend of mine asked me about the OSPF forwarding address. The question was why
must the network type be broadcast for the FA to be set? Why is not point to point
and point to multipoint network type valid?
First of all, what is the point of having a forwarding address? Look at the topology
below.
R3 is the only one running BGP to R4. If the FA is not set then there will be an
extra hop compared to R2 sending the traffic directly to R4.
R1#sh ip route 10.10.4.0
Routing entry for 10.10.4.0/24
Known via "ospf 1", distance 110, metric 1
Tag 4, type extern 2, forward metric 20
Last update from 10.10.12.2 on FastEthernet0/0, 00:00:23 ago
Routing Descriptor Blocks:
* 10.10.12.2, from 10.10.23.3, 00:00:23 ago, via FastEthernet0/0
Route metric is 1, traffic share count is 1
Route tag 4
R1#sh ip ospf data ex 10.10.4.0
OSPF Router with ID (10.10.12.1) (Process ID 1)
Type-5 AS External Link States
Routing Bit Set on this LSA
LS age: 35
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 10.10.4.0 (External Network Number )
Advertising Router: 10.10.23.3
LS Seq Number: 80000001
Checksum: 0xEB7D
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 1
Forward Address: 0.0.0.0
External Route Tag: 4
R1#traceroute 10.10.4.4 num
Type escape sequence to abort.
Tracing the route to 10.10.4.4
1 10.10.12.2 44 msec 44 msec 32 msec
2 10.10.23.3 60 msec 36 msec 40 msec
3 10.10.234.4 84 msec * 76 msec
Because the forwarding address is set to 0 the traffic must flow through the
ASBR originating the LSA.
Which conditions must be met to set the FA?
The interface on the ASBR must have OSPF enabled. It must not be passive and it
must be broadcast. Let’s enable this on R3.
R3#conf t Enter configuration commands, one per line. End with CNTL/Z. R3(config)#int f0/1 R3(config-if)#ip ospf 1 area 0
Now check the external LSA on R1 and a traceroute.
R1#sh ip ospf data ex 10.10.4.0
OSPF Router with ID (10.10.12.1) (Process ID 1)
Type-5 AS External Link States
Routing Bit Set on this LSA
LS age: 243
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 10.10.4.0 (External Network Number )
Advertising Router: 10.10.23.3
LS Seq Number: 80000002
Checksum: 0xF66E
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 1
Forward Address: 10.10.234.4
External Route Tag: 4
R1#traceroute 10.10.4.4 num
Type escape sequence to abort.
Tracing the route to 10.10.4.4
1 10.10.12.2 48 msec 32 msec 64 msec
2 10.10.234.4 96 msec * 88 msec
The traffic is now flowing directly via R2. The key point here is that in broadcast
networks all routers can communicate with each other (full mesh). We can see this by
looking at the type2 LSA.
R1#sh ip ospf data net 10.10.234.3
OSPF Router with ID (10.10.12.1) (Process ID 1)
Net Link States (Area 0)
Routing Bit Set on this LSA
LS age: 179
Options: (No TOS-capability, DC)
LS Type: Network Links
Link State ID: 10.10.234.3 (address of Designated Router)
Advertising Router: 10.10.23.3
LS Seq Number: 80000001
Checksum: 0x3485
Length: 32
Network Mask: /24
Attached Router: 10.10.23.3
Attached Router: 10.10.12.2
Why isn’t a point to point network valid? Well, the name pretty much says it all.
With point-to-point there can only be two routers connected so there is no use
in setting the FA because the traffic must flow through the router originating
the LSA.
If we look at the router LSA from R2 when we have broadcast network type it looks
like this:
R1#sh ip ospf data router 10.10.12.2
OSPF Router with ID (10.10.12.1) (Process ID 1)
Router Link States (Area 0)
LS age: 7
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 10.10.12.2
Advertising Router: 10.10.12.2
LS Seq Number: 8000000A
Checksum: 0x977B
Length: 60
Number of Links: 3
Link connected to: a Transit Network
(Link ID) Designated Router address: 10.10.234.3
(Link Data) Router Interface address: 10.10.234.2
Number of TOS metrics: 0
TOS 0 Metrics: 1
Link connected to: a Transit Network
(Link ID) Designated Router address: 10.10.23.2
(Link Data) Router Interface address: 10.10.23.2
Number of TOS metrics: 0
TOS 0 Metrics: 10
Link connected to: a Transit Network
(Link ID) Designated Router address: 10.10.12.1
(Link Data) Router Interface address: 10.10.12.2
Number of TOS metrics: 0
TOS 0 Metrics: 10
You can see that the 10.10.234.0 is a transit network and then the type 2 LSA shows
which routers are connected and the network mask. Now if we change to point to point.
R1#sh ip ospf data router 10.10.12.2
OSPF Router with ID (10.10.12.1) (Process ID 1)
Router Link States (Area 0)
LS age: 59
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 10.10.12.2
Advertising Router: 10.10.12.2
LS Seq Number: 8000000B
Checksum: 0xF2E3
Length: 72
Number of Links: 4
Link connected to: another Router (point-to-point)
(Link ID) Neighboring Router ID: 10.10.23.3
(Link Data) Router Interface address: 10.10.234.2
Number of TOS metrics: 0
TOS 0 Metrics: 1
Link connected to: a Stub Network
(Link ID) Network/subnet number: 10.10.234.0
(Link Data) Network Mask: 255.255.255.0
Number of TOS metrics: 0
TOS 0 Metrics: 1
Link connected to: a Transit Network
(Link ID) Designated Router address: 10.10.23.2
(Link Data) Router Interface address: 10.10.23.2
Number of TOS metrics: 0
TOS 0 Metrics: 10
Link connected to: a Transit Network
(Link ID) Designated Router address: 10.10.12.1
(Link Data) Router Interface address: 10.10.12.2
Number of TOS metrics: 0
TOS 0 Metrics: 10
The 10.10.234.0 network is now a stub network which means it can’t be used for transit.
Usually there should only be two routers connected here, we shouldn’t use P2P network
type if there is an Ethernet segment with multiple routers.
So finally why is P2MP not valid? Because P2MP is used in NBMA networks. These networks
are usually partially meshed and from the perspective of OSPF it is a collection of
point to point links. This is how the LSA looks.
R1#sh ip ospf data router 10.10.12.2
OSPF Router with ID (10.10.12.1) (Process ID 1)
Router Link States (Area 0)
LS age: 8
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 10.10.12.2
Advertising Router: 10.10.12.2
LS Seq Number: 8000000D
Checksum: 0xFCD6
Length: 72
Number of Links: 4
Link connected to: another Router (point-to-point)
(Link ID) Neighboring Router ID: 10.10.23.3
(Link Data) Router Interface address: 10.10.234.2
Number of TOS metrics: 0
TOS 0 Metrics: 1
Link connected to: a Stub Network
(Link ID) Network/subnet number: 10.10.234.2
(Link Data) Network Mask: 255.255.255.255
Number of TOS metrics: 0
TOS 0 Metrics: 0
Link connected to: a Transit Network
(Link ID) Designated Router address: 10.10.23.2
(Link Data) Router Interface address: 10.10.23.2
Number of TOS metrics: 0
TOS 0 Metrics: 10
Link connected to: a Transit Network
(Link ID) Designated Router address: 10.10.12.1
(Link Data) Router Interface address: 10.10.12.2
Number of TOS metrics: 0
TOS 0 Metrics: 10
It looks very similar to P2P with the difference that the stub network has a mask
of /32. This is useful in partial mesh where spokes need to reach each other via
the hub and don’t have a DLCI between them.
So it only makes sense to use FA in broadcast networks because that is the only
place where routers are guaranteed to be able to communicate to each other because
it is by nature fully meshed.
Tiebreakers with routes from different OSPF processes
This post is inspired by a discussion at Twitter with Ivan Pepelnjak and
Nicolas Michel. Nicolas asked what happens when there is the same route from two
different OSPF processes. Which one will be selected? Ivan explained how
to use the distance command. First before I show how it works and why we
need to get some few basic concepts explained.
LSDB – Link State Database – All OSPF LSAs populate the LSDB
RIB – Routing Information Base – The best routes from every protocol
compete to get installed to the RIB
FIB – Forwarding Information Base – Routes are copied from the RIB
and used for forwarding (CEF)
CEF – Cisco Express Forwarding – The algorithm that Cisco uses for
the forwarding (FIB)
If we have for example OSPF, this is how a route gets selected to the RIB(global).
The routers exchange LSAs with each other. Within an area every router has the same
view of the network. These LSAs populate the LSDB. If there are multiple paths to
a destination they will compete with each other unless they are of same type and equal
cost. Intra area is preferred first, then inter and finally external routes. There is no
way of modifying this behaviour. The best route then goes to the OSPF RIB, could be several
if they are equal. From there this route will compete with other routing protocols and the
AD will decide which one is installed. If the OSPF one is best then that one goes to the global
RIB. Then finally the RIB populates FIB with this information and forwarding can ensue.
This is a picture I made that describes the process.
We start out with a very basic topology looking like this.
R1 and R3 will announce the same network 1.1.1.1/32. R2 will use two different OSPF processes.
We start out with the basic configuration:
R1
R1(config)#int f1/0 R1(config-if)#ip add 12.12.12.1 255.255.255.0 R1(config-if)#no sh R1(config-if)#ip ospf 1 area 0 R1(config-if)#int lo0 R1(config-if)#ip add 1.1.1.1 255.255.255.255 R1(config-if)#ip ospf 1 area 0
R2
R2(config)#int f1/0 R2(config-if)#ip add 12.12.12.2 255.255.255.0 R2(config-if)#no sh R2(config-if)#ip ospf 1 area 0 R2(config-if)#int f1/1 R2(config-if)#ip add 23.23.23.2 255.255.255.0 R2(config-if)#no sh R2(config-if)#ip ospf 3 area 0 %OSPF-5-ADJCHG: Process 1, Nbr 12.12.12.1 on FastEthernet1/0 from LOADING to FULL, Loading Done
We see the session coming up immediately. Now lets bring up R3 as well.
R3
R3(config)#int f1/0 R3(config-if)#ip add 23.23.23.3 255.255.255.0 R3(config-if)#no sh R3(config-if)#ip ospf 3 area 0 R3(config-if)#int lo0 R3(config-if)#ip add 1.1.1.1 255.255.255.255 R3(config-if)#ip ospf 3 area 0 %OSPF-5-ADJCHG: Process 3, Nbr 23.23.23.2 on FastEthernet1/0 from LOADING to FULL, Loading Done
Both OSPF peerings are up. Now lets follow the steps that was shown in
the picture above starting by looking at the database.
R2#sh ip ospf data router 12.12.12.1
OSPF Router with ID (23.23.23.2) (Process ID 3)
OSPF Router with ID (12.12.12.2) (Process ID 1)
Router Link States (Area 0)
LS age: 184
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 12.12.12.1
Advertising Router: 12.12.12.1
LS Seq Number: 80000003
Checksum: 0xF78
Length: 48
Number of Links: 2
Link connected to: a Stub Network
(Link ID) Network/subnet number: 1.1.1.1
(Link Data) Network Mask: 255.255.255.255
Number of MTID metrics: 0
TOS 0 Metrics: 1
Link connected to: a Transit Network
(Link ID) Designated Router address: 12.12.12.1
(Link Data) Router Interface address: 12.12.12.1
Number of MTID metrics: 0
TOS 0 Metrics: 1
We see that R1 is announcing 1.1.1.1/32 and we have a metric of 2 to it.
Do we see R3 announcing that as well?
R2#sh ip ospf data router 23.23.23.3
OSPF Router with ID (23.23.23.2) (Process ID 3)
Router Link States (Area 0)
LS age: 148
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 23.23.23.3
Advertising Router: 23.23.23.3
LS Seq Number: 80000003
Checksum: 0x54A7
Length: 48
Number of Links: 2
Link connected to: a Stub Network
(Link ID) Network/subnet number: 1.1.1.1
(Link Data) Network Mask: 255.255.255.255
Number of MTID metrics: 0
TOS 0 Metrics: 1
Link connected to: a Transit Network
(Link ID) Designated Router address: 23.23.23.2
(Link Data) Router Interface address: 23.23.23.3
Number of MTID metrics: 0
TOS 0 Metrics: 1
Yes, it’s there. Now we take a look at the OSPF RIB. Which ones do we see there?
R2#sh ip ospf rib
OSPF Router with ID (23.23.23.2) (Process ID 3)
Base Topology (MTID 0)
OSPF local RIB
Codes: * - Best, > - Installed in global RIB
* 1.1.1.1/32, Intra, cost 2, area 0
via 23.23.23.3, FastEthernet1/1
* 23.23.23.0/24, Intra, cost 1, area 0, Connected
via 23.23.23.2, FastEthernet1/1
OSPF Router with ID (12.12.12.2) (Process ID 1)
Base Topology (MTID 0)
OSPF local RIB
Codes: * - Best, > - Installed in global RIB
*> 1.1.1.1/32, Intra, cost 2, area 0
via 12.12.12.1, FastEthernet1/0
* 12.12.12.0/24, Intra, cost 1, area 0, Connected
via 12.12.12.2, FastEthernet1/0
The greater than sign indicates that the one from OSPF process 1 was selected.
Why? When running multiple OSPF processes the one that first installs to the
RIB will be selected to the global RIB. Now we confirm by looking in the
global RIB.
R2# show ip route ospf
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override
Gateway of last resort is not set
1.0.0.0/32 is subnetted, 1 subnets
O 1.1.1.1 [110/2] via 12.12.12.1, 00:06:35, FastEthernet1/0
Yes, that looks correct. Final step is to verify that FIB is also updated.
R2#sh ip cef 1.1.1.1/32 1.1.1.1/32 nexthop 12.12.12.1 FastEthernet1/0
So the one that first writes to the global RIB wins. Now lets bring down the
process that is currently winning.
R2(config)#int f1/0 R2(config-if)#sh R2(config-if)#
The OSPF RIB and global RIB should now be updated.
R2#show ip ospf rib
OSPF Router with ID (23.23.23.2) (Process ID 3)
Base Topology (MTID 0)
OSPF local RIB
Codes: * - Best, > - Installed in global RIB
*> 1.1.1.1/32, Intra, cost 2, area 0
via 23.23.23.3, FastEthernet1/1
* 23.23.23.0/24, Intra, cost 1, area 0, Connected
via 23.23.23.2, FastEthernet1/1
OSPF Router with ID (12.12.12.2) (Process ID 1)
Base Topology (MTID 0)
OSPF local RIB
Codes: * - Best, > - Installed in global RIB
R2#show ip route ospf
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override
Gateway of last resort is not set
1.0.0.0/32 is subnetted, 1 subnets
O 1.1.1.1 [110/2] via 23.23.23.3, 00:00:42, FastEthernet1/1
Now if we bring back OSPF process 1, what will happen? Process 3 should still be
winning since it installed to global RIB first.
R2(config)#int f1/0 R2(config-if)#no sh
R2#sh ip ospf rib
OSPF Router with ID (2.2.2.2) (Process ID 11)
Base Topology (MTID 0)
OSPF local RIB
Codes: * - Best, > - Installed in global RIB
OSPF Router with ID (23.23.23.2) (Process ID 3)
Base Topology (MTID 0)
OSPF local RIB
Codes: * - Best, > - Installed in global RIB
* 1.1.1.1/32, Intra, cost 2, area 0
via 23.23.23.3, FastEthernet1/1
* 23.23.23.0/24, Intra, cost 1, area 0, Connected
via 23.23.23.2, FastEthernet1/1
OSPF Router with ID (12.12.12.2) (Process ID 1)
Base Topology (MTID 0)
OSPF local RIB
Codes: * - Best, > - Installed in global RIB
*> 1.1.1.1/32, Intra, cost 2, area 0
via 12.12.12.1, FastEthernet1/0
* 12.12.12.0/24, Intra, cost 1, area 0, Connected
via 12.12.12.2, FastEthernet1/0
Now process 1 is winning, which is odd. Lets debug ip routing to see what is
really happening. We shutdown interface in process 1.
*Mar 14 23:26:36.555: RT: del 1.1.1.1 via 12.12.12.1, ospf metric [110/2]
*Mar 14 23:26:36.559: RT: delete subnet route to 1.1.1.1/32
*Mar 14 23:26:36.579: RT: updating ospf 1.1.1.1/32 (0x0):
via 23.23.23.3 Fa1/1
*Mar 14 23:26:36.583: RT: add 1.1.1.1/32 via 23.23.23.3, ospf metric [110/2]
Now we bring back process 1.
*Mar 14 23:29:04.163: RT: updating ospf 1.1.1.1/32 (0x0):
via 12.12.12.1 Fa1/0
*Mar 14 23:29:04.171: RT: closer admin distance for 1.1.1.1, flushing 1 routes
*Mar 14 23:29:04.175: RT: add 1.1.1.1/32 via 12.12.12.1, ospf metric [110/2]
We can see that IOS is claiming that distance is lower which it is clearly not.
What happens if we change process 1 to process 11 and we shutdown the interface
in process 3?
R2(config)#int f1/1 R2(config-if)#sh R2(config-if)#int f1/0 R2(config-if)#ip ospf 11 area 0
Now we look at the output from the debug.
*Mar 14 23:33:27.615: RT: updating ospf 1.1.1.1/32 (0x0):
via 12.12.12.1 Fa1/0
*Mar 14 23:33:27.619: RT: add 1.1.1.1/32 via 12.12.12.1, ospf metric [110/2]
*Mar 14 23:33:39.927: RT: updating connected 23.23.23.0/24 (0x0):
via 0.0.0.0 Fa1/1
*Mar 14 23:33:39.931: RT: add 23.23.23.0/24 via 0.0.0.0, connected metric [0/0]
*Mar 14 23:33:39.939: RT: interface FastEthernet1/1 added to routing table
*Mar 14 23:33:39.947: RT: updating connected 23.23.23.2/32 (0x0):
via 0.0.0.0 Fa1/1
*Mar 14 23:33:39.951: RT: network 23.0.0.0 is now variably masked
*Mar 14 23:33:39.951: RT: add 23.23.23.2/32 via 0.0.0.0, connected metric [0/0]
*Mar 14 23:33:55.447: RT: updating ospf 1.1.1.1/32 (0x0):
via 23.23.23.3 Fa1/1
*Mar 14 23:33:55.455: RT: closer admin distance for 1.1.1.1, flushing 1 routes
*Mar 14 23:33:55.455: RT: add 1.1.1.1/32 via 23.23.23.3, ospf metric [110/2]
We can see that first process 11 is the only option available so the 1.1.1.1/32
route is installed via f1/0. Then f1/1 comes back up and now 1.1.1.1/32 is reachable
via f1/1 and is chosen because of “closer admin distance” which is not true. This must
mean that the OSPF process number is the tie breaker.
We take a look at the OSPF RIB and global RIB to verify once more.
R2#sh ip ospf rib
OSPF Router with ID (22.22.22.22) (Process ID 11)
Base Topology (MTID 0)
OSPF local RIB
Codes: * - Best, > - Installed in global RIB
* 1.1.1.1/32, Intra, cost 2, area 0
via 12.12.12.1, FastEthernet1/0
* 12.12.12.0/24, Intra, cost 1, area 0, Connected
via 12.12.12.2, FastEthernet1/0
OSPF Router with ID (23.23.23.2) (Process ID 3)
Base Topology (MTID 0)
OSPF local RIB
Codes: * - Best, > - Installed in global RIB
*> 1.1.1.1/32, Intra, cost 2, area 0
via 23.23.23.3, FastEthernet1/1
* 23.23.23.0/24, Intra, cost 1, area 0, Connected
via 23.23.23.2, FastEthernet1/1
OSPF Router with ID (12.12.12.2) (Process ID 1)
Base Topology (MTID 0)
OSPF local RIB
Codes: * - Best, > - Installed in global RIB
R2#sh ip route ospf
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override
Gateway of last resort is not set
1.0.0.0/32 is subnetted, 1 subnets
O 1.1.1.1 [110/2] via 23.23.23.3, 00:09:02, FastEthernet1/1
What if we change the AD of process 11?
R2(config)#router ospf 11 R2(config-router)#distance ospf intra-area 100
*Mar 14 23:43:31.315: RT: updating ospf 1.1.1.1/32 (0x0):
via 12.12.12.1 Fa1/0
*Mar 14 23:43:31.319: RT: closer admin distance for 1.1.1.1, flushing 1 routes
*Mar 14 23:43:31.323: RT: add 1.1.1.1/32 via 12.12.12.1, ospf metric [100/2]
That makes process 11 win again. So these tests seems to indicate that if everything
is the same then the tiebreaker is the lowest process number. For EIGRP it is the
lowest AS number so maybe Cisco chose to make it comparable.
Also take a look at what Ivan is saying at IOS hints
ASBR in NSSA – Choosing what IP to use as forwarding address
OSPF is one of the protocols where the details are very important. It has lots
of bits and pieces to make it run in a proper way. I have described the forwarding
address in an earlier post and this time I want to show how the IP that is used
as the forwarding address is selected. We start out with this simple topology.
It’s a very basic config where R1 is redistributing a route and running in a
NSSA area.
R1#sh run | s router ospf|ip route router ospf 1 router-id 1.1.1.1 log-adjacency-changes area 10 nssa redistribute static subnets ip route 100.0.0.0 255.0.0.0 Null0
Which IP will R1 use for its forwarding address? We look at R3.
R3#sh ip route ospf | i E2
O E2 100.0.0.0/8 [110/20] via 23.23.23.2, 00:57:59, FastEthernet0/0
R3#sh ip ospf data ex 100.0.0.0
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: 120
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 100.0.0.0 (External Network Number )
Advertising Router: 2.2.2.2
LS Seq Number: 80000005
Checksum: 0x4AC0
Length: 36
Network Mask: /8
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 12.12.12.1
External Route Tag: 0
It has chosen its interface address towards R2. What if we enable OSPF on the other
Ethernet interface of R1?
R1(config)#int f0/1 R1(config-if)#ip ospf 1 area 10
We check R3 again.
R3#sh ip ospf data ex 100.0.0.0
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: 25
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 100.0.0.0 (External Network Number )
Advertising Router: 2.2.2.2
LS Seq Number: 80000006
Checksum: 0x6676
Length: 36
Network Mask: /8
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 112.112.112.1
External Route Tag: 0
The forwarding address has changed. It selected the IP of the other Ethernet interface
of R1. We can see that it prefers to choose a higher IP address. What if we announce
the loopback of R1 in the NSSA area?
R1(config-if)#int lo0 R1(config-if)#ip ospf 1 area 10
R3#sh ip ospf data ex 100.0.0.0
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: 27
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 100.0.0.0 (External Network Number )
Advertising Router: 2.2.2.2
LS Seq Number: 80000007
Checksum: 0xAE53
Length: 36
Network Mask: /8
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 11.11.11.11
External Route Tag: 0
Now the loopback IP is chosen instead. So since the loopback has a lower IP but still
is preferred we can see that loopbacks are preferred in the selection. To see this
clearly defined in words we reference RFC 3101 section 2.3.
When a router is forced to pick a forwarding address for a Type-7 LSA, preference should be given first to the router's internal addresses (provided internal addressing is supported). If internal addresses are not available, preference should be given to the router's active OSPF stub network addresses. These choices avoid the possible extra hop that may happen when a transit network's address is used. When the interface whose IP address is the LSA's forwarding address transitions to a Down state (see [OSPF] Section 9.3), the router must select a new forwarding address for the LSA and then re- originate it. If one is not available the LSA should be flushed.
So the selection process is to choose the highest IP of a loopback advertised
into the NSSA area. If no loopback is advertised then choose the highest
physical interface IP advertised into the NSSA area.
I hope that I have provide another piece to the OSPF puzzle and you now have
a good understanding of the forwarding address.
Route redistribution – Route-maps and tagging
Earlier I have done some posts on route redistribution and on
route filtering in different protocols. I wanted to expand on this
by showing different ways we can tag and do filtering with route-maps
when doing route redistribution.
We start out with this topology where two different OSPF segments are
separated by an EIGRP segment.
R2 will redistribute between OSPF and EIGRP mutually. R1 is redistributing
its loopback so it will be an external OSPF route. R4 and R5 will mutually
redistribute between EIGRP and OSPF. One interesting aspect about EIGRP is
that in the EIGRP packet we can see which protocol that originated the
route from the beginning. Take a look at this output showing the R1 loopback
in the EIGRP domain.
R4#sh ip eigrp topo 10.10.1.0/24
IP-EIGRP (AS 100): Topology entry for 10.10.1.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2560002816
Routing Descriptor Blocks:
10.10.24.2 (FastEthernet0/0), from 10.10.24.2, Send flag is 0x0
Composite metric is (2560002816/2560000256), Route is External
Vector metric:
Minimum bandwidth is 1 Kbit
Total delay is 110 microseconds
Reliability is 1/255
Load is 1/255
Minimum MTU is 1
Hop count is 1
External data:
Originating router is 10.10.24.2
AS number of route is 1
External protocol is OSPF, external metric is 20
Administrator tag is 0 (0x00000000)
We can see that it came from OSPF 1 and that the ASBR is 10.10.24.2.
We also see that it had a metric of 20 and no tag applied to it. Where
is this information carried? Take a look at this packet capture.
We can see that a lot of information is carried for external routes.
This gives us options when doing tagging and filtering.
We configure distribution on R2 and then look at our options for doing
tagging and filtering.
R2#sh run | s router router eigrp 100 redistribute ospf 1 metric 1 1 1 1 1
If we look at R4 we should have two external routes with AD 170 going towards
the OSPF domain.
R4#sh ip route eigrp | i EX D EX 10.10.1.0 [170/2560002816] via 10.10.24.2, 00:07:22, FastEthernet0/0 D EX 10.10.12.0 [170/2560002816] via 10.10.24.2, 00:07:22, FastEthernet0/0
If we traceroute this traffic will go straight to R2.
R4#traceroute 10.10.1.1 num Type escape sequence to abort. Tracing the route to 10.10.1.1 1 10.10.24.2 32 msec 40 msec 28 msec 2 10.10.12.1 60 msec * 64 msec
What if we want external routes to go through R5 instead? We can
match on the route-type and incoming interface to block R2 routes.
This is a pretty blunt tool but can be good for some scenarios.
R4(config)#route-map RM_DENY_EXT_FA0/0 deny 10 R4(config-route-map)#match route-type external R4(config-route-map)#route-map RM_DENY_EXT_FA0/0 permit 100 R4(config-route-map)#router eigrp 100 R4(config-router)#distribute-list route-map RM_DENY_EXT_FA0/0 in fa0/0
So what we just did is filter all external routes coming in on Fa0/0.
Did we achieve the wanted result?
R4#sh ip route eigrp | i EX D EX 10.10.1.0 [170/2560030976] via 10.10.45.5, 00:00:21, FastEthernet0/1 D EX 10.10.12.0 [170/2560030976] via 10.10.45.5, 00:00:21, FastEthernet0/1 R4#traceroute 10.10.1.1 num Type escape sequence to abort. Tracing the route to 10.10.1.1 1 10.10.45.5 40 msec 36 msec 16 msec 2 10.10.35.3 56 msec 40 msec 40 msec 3 10.10.23.2 48 msec 28 msec 44 msec 4 10.10.12.1 68 msec * 68 msec
Now all external routes will go through R5 instead.
Currently we are not doing redistribution on R4 and R5. What will
happen with the EIGRP external routes when we do redistribution?
First we remove the previous configuration and then we configure
redistribution.
R4(config)#router eigrp 100 R4(config-router)#no distribute-list route-map RM_DENY_EXT_FA0/0 in FastEthernet0/0 R4(config-router)#redistribute ospf 1 metric 1 1 1 1 1 R4(config-router)#router ospf 10 R4(config-router)#redistribute eigrp 100 sub R5(config)#router eigrp 100 R5(config-router)#redistribute ospf 10 metric 1 1 1 1 1 R5(config-router)#router ospf 10 R5(config-router)#redistribute eigrp 100 sub
From R4 we now look at how it reaches 10.10.1.0/24.
R4#sh ip route 10.10.1.0
Routing entry for 10.10.1.0/24
Known via "eigrp 100", distance 170, metric 2560002816, type external
Redistributing via eigrp 100, ospf 10
Advertised by ospf 10 subnets
Last update from 10.10.45.5 on FastEthernet0/1, 00:00:52 ago
Routing Descriptor Blocks:
10.10.45.5, from 10.10.45.5, 00:00:52 ago, via FastEthernet0/1
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
* 10.10.24.2, from 10.10.24.2, 00:00:52 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
Why does it have two entries for 10.10.1.0/24? Take a look in the
EIGRP topology table.
R4#sh ip eigrp topo 10.10.1.0/24
IP-EIGRP (AS 100): Topology entry for 10.10.1.0/24
State is Passive, Query origin flag is 1, 2 Successor(s), FD is 2560002816
Routing Descriptor Blocks:
10.10.24.2 (FastEthernet0/0), from 10.10.24.2, Send flag is 0x0
Composite metric is (2560002816/2560000256), Route is External
Vector metric:
Minimum bandwidth is 1 Kbit
Total delay is 110 microseconds
Reliability is 1/255
Load is 1/255
Minimum MTU is 1
Hop count is 1
External data:
Originating router is 10.10.24.2
AS number of route is 1
External protocol is OSPF, external metric is 20
Administrator tag is 0 (0x00000000)
10.10.45.5 (FastEthernet0/1), from 10.10.45.5, Send flag is 0x0
Composite metric is (2560002816/2560000256), Route is External
Vector metric:
Minimum bandwidth is 1 Kbit
Total delay is 110 microseconds
Reliability is 1/255
Load is 1/255
Minimum MTU is 1
Hop count is 1
External data:
Originating router is 10.10.56.5
AS number of route is 10
External protocol is OSPF, external metric is 20
Administrator tag is 0 (0x00000000)
We can see that one route is originating from OSPF 1, which is the true
source of the route and one is originating via OSPF 10. R5 is learning
this route via OSPF and then redistributing it into EIGRP and R4 is
learning that via EIGRP. Let us confirm that R5 sees this as an OSPF
route.
R5#sh ip route 10.10.1.0
Routing entry for 10.10.1.0/24
Known via "ospf 10", distance 110, metric 20, type extern 2, forward metric 2
Redistributing via eigrp 100
Advertised by eigrp 100 metric 1 1 1 1 1
Last update from 10.10.56.6 on FastEthernet1/0, 00:08:12 ago
Routing Descriptor Blocks:
* 10.10.56.6, from 10.10.46.4, 00:08:12 ago, via FastEthernet1/0
Route metric is 20, traffic share count is 1
Which it does. What would happen if R5 was redistributing with a
better metric than R2 is doing? First we enable debugging of ip
routing on R4. Remember that in a stable topology where everything
is converged there should be no changes.
R4#debug ip routing IP routing debugging is on
Then we change the metric on R5.
R5(config)#router eigrp 100 R5(config-router)#redistribute ospf 10 metric 100000 10 255 1 1500
RT: eigrp's 10.10.1.0/24 (via 10.10.45.5) metric changed from distance/metric [170/2560002816] to [170/30720] RT: del 10.10.1.0/24 via 10.10.24.2, eigrp metric [170/2560002816] RT: NET-RED 10.10.1.0/24 RT: NET-RED 10.10.1.0/24 RT: eigrp's 10.10.12.0/24 (via 10.10.45.5) metric changed from distance/metric [170/2560002816] to [170/30720] RT: del 10.10.12.0/24 via 10.10.24.2, eigrp metric [170/2560002816] RT: NET-RED 10.10.12.0/24 RT: NET-RED 10.10.12.0/24
We can see that the metric change but at least we have no flapping.
R4#sh ip route 10.10.1.0
Routing entry for 10.10.1.0/24
Known via "eigrp 100", distance 170, metric 30720, type external
Redistributing via eigrp 100, ospf 10
Advertised by ospf 10 subnets
Last update from 10.10.45.5 on FastEthernet0/1, 00:02:33 ago
Routing Descriptor Blocks:
* 10.10.45.5, from 10.10.45.5, 00:02:33 ago, via FastEthernet0/1
Route metric is 30720, traffic share count is 1
Total delay is 200 microseconds, minimum bandwidth is 100000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1
Do we still have reachability?
R4#traceroute 10.10.1.1 num Type escape sequence to abort. Tracing the route to 10.10.1.1 1 10.10.45.5 40 msec 16 msec 28 msec 2 10.10.56.6 48 msec 32 msec 28 msec 3 10.10.46.4 24 msec 44 msec 28 msec 4 10.10.45.5 52 msec 48 msec 52 msec 5 10.10.56.6 60 msec 60 msec 64 msec 6 10.10.46.4 64 msec 60 msec 60 msec 7 10.10.45.5 84 msec 108 msec 100 msec
Now we have a routing loop. What is happening here is that R4
is learning the route first via EIGRP and redistributes it into
OSPF. R5 learns this route via OSPF and then redistributes it
back into EIGRP and then R4 learns this route. They are now
both pointing at each other which means we have a loop.
What are our options of solving this? One way of solving it is
to increase the OSPF external AD on R5. That way R5 should not
redistribute it back to R4.
R5(config-router)#distance ospf external 180
R4#sh ip route 10.10.1.1
Routing entry for 10.10.1.0/24
Known via "ospf 10", distance 110, metric 20, type extern 2, forward metric 2
Last update from 10.10.46.6 on FastEthernet1/0, 00:00:38 ago
Routing Descriptor Blocks:
* 10.10.46.6, from 10.10.56.5, 00:00:38 ago, via FastEthernet1/0
Route metric is 20, traffic share count is 1
R4#traceroute 10.10.1.1 num
Type escape sequence to abort.
Tracing the route to 10.10.1.1
1 10.10.46.6 56 msec 36 msec 16 msec
2 10.10.56.5 48 msec 40 msec 40 msec
3 10.10.35.3 52 msec 52 msec 52 msec
4 10.10.23.2 112 msec 76 msec 72 msec
5 10.10.12.1 96 msec * 120 msec
That solved the loop changing the distance is a bit of a hack unless
we incorporate the same policy on all devices. At least all devices
involved in redistribution should have the same policy.
R4(config)#router ospf 10 R4(config-router)#distance ospf external 180 R4#traceroute 10.10.1.1 num Type escape sequence to abort. Tracing the route to 10.10.1.1 1 10.10.24.2 28 msec 32 msec 12 msec 2 10.10.12.1 44 msec * 60 msec
Yes, that solved it. A more elegant way is to use tagging and
filtering. We remove the previous distance commands.
What we can do now is to tag all external routes coming from OSPF 1
and then deny those routes from coming in if they have a tag set.
On R4 we tag routes with tag 444 and on R5 we will tag with 555.
First we confirm that the loop is back. You should note that with
redistribution you may see different results than I due to order of
operation. If that happens you could shutdown R5 link to R3 and
the loop should be back.
R4#traceroute 10.10.1.1 num Type escape sequence to abort. Tracing the route to 10.10.1.1 1 10.10.45.5 16 msec 44 msec 24 msec 2 10.10.56.6 36 msec 28 msec 36 msec 3 10.10.46.4 32 msec 40 msec 32 msec 4 10.10.45.5 48 msec 56 msec 48 msec 5 10.10.56.6 64 msec 56 msec 68 msec 6 10.10.46.4 48 msec 64 msec 60 msec
It is still there. Time for some route-maps.
R4(config)#route-map RM_DENY_EXT_FROM_R5 deny 10 R4(config-route-map)#match tag 444 R4(config-route-map)#route-map RM_DENY_EXT_FROM_R5 permit 100 R4(config-route-map)#route-map RM_SET_TAG_444 permit 10 R4(config-route-map)#match source-protocol ospf 1 R4(config-route-map)#match route-type external R4(config-route-map)#set tag 444 R4(config-route-map)#route-map RM_SET_TAG_444 permit 100 R4(config-route-map)#router eigrp 100 R4(config-router)#distribute-list route-map RM_DENY_EXT_FROM_R5 in R4(config-router)#router ospf 10 R4(config-router)#redistribute eigrp 100 route-map RM_SET_TAG_444 sub
First we will confirm on R5 that we now see a tag.
R5#sh ip route 10.10.1.0
Routing entry for 10.10.1.0/24
Known via "ospf 10", distance 110, metric 20
Tag 444, type extern 2, forward metric 2
Redistributing via eigrp 100
Advertised by eigrp 100 metric 100000 10 255 1 1500
Last update from 10.10.56.6 on FastEthernet1/0, 00:00:48 ago
Routing Descriptor Blocks:
* 10.10.56.6, from 10.10.46.4, 00:00:48 ago, via FastEthernet1/0
Route metric is 20, traffic share count is 1
Route tag 444
We now see the tag. There should be no tag on EIGRP internal routes.
We can confirm this on R6.
R6#sh ip route 10.10.24.0
Routing entry for 10.10.24.0/24
Known via "ospf 10", distance 110, metric 20, type extern 2, forward metric 1
Last update from 10.10.56.5 on FastEthernet0/1, 08:28:39 ago
Routing Descriptor Blocks:
10.10.56.5, from 10.10.56.5, 08:28:39 ago, via FastEthernet0/1
Route metric is 20, traffic share count is 1
* 10.10.46.4, from 10.10.46.4, 08:30:34 ago, via FastEthernet0/0
Route metric is 20, traffic share count is 1
There should be no loop on R4 now. We will test with a traceroute.
R4#traceroute 10.10.1.1 num Type escape sequence to abort. Tracing the route to 10.10.1.1 1 10.10.24.2 28 msec 44 msec 12 msec 2 10.10.12.1 36 msec * 48 msec
The loop is gone. We should implement the same policy on R5 so if
R4 sends routes back to R5 it should stop it from learning them.
R5(config)#route-map RM_DENY_EXT_FROM_R4 deny 10 R5(config-route-map)#match tag 555 R5(config-route-map)#route-map RM_DENY_EXT_FROM_R4 permit 100 R5(config-route-map)#route-map RM_SET_TAG_555 permit 10 R5(config-route-map)#match source-protocol ospf 1 R5(config-route-map)#match route-type external R5(config-route-map)#set tag 555 R5(config-route-map)#router eigrp 100 R5(config-router)#distribute-list route-map RM_DENY_EXT_FROM_R4 in R5(config-router)#router ospf 10 R5(config-router)#redistribute eigrp 100 route-map RM_SET_TAG_555 sub
And that concludes this lesson. Route redistribution is always fun 
You can look at some of my older posts for more ideas about filtering
routes.
OSPF – Use of forwarding address
In OSPF and other routing protocols we have something called forwarding address.
This can be used to route traffic in another direction than to the router that
originated the LSA. We start with the following topology.
It’s a basic OSPF setup where area 1 is a NSSA area. As you can see we have
two ABRs. Remember that in NSSA area, redistributed routes will be seen as N
internally but as E outside the area. To make this happen the ABR must translate
the type 7 LSA to type 5 LSA. If we have multiple ABRs, which one is responsible
for this task? The ABR with the highest RID will do the translation.
If we look at the LSA at R1, this is what it looks like.
R1#sh ip ospf data ex 10.10.4.0
OSPF Router with ID (10.10.13.1) (Process ID 1)
Type-5 AS External Link States
Routing Bit Set on this LSA
LS age: 1373
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 10.10.4.0 (External Network Number )
Advertising Router: 3.3.3.3
LS Seq Number: 80000001
Checksum: 0x7306
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 10.10.234.4
External Route Tag: 0
So R3 is the ABR doing the translation but the forward address is set to
10.10.234.4 which is the address of R4. This means that traffic doesn’t need
to pass through R3 to reach the R4 network. The router will lookup the
10.10.234.0/24 prefix and use the routing information to reach the
10.10.4.0 network. This is proven by a traceroute.
R1#traceroute 10.10.4.4 Type escape sequence to abort. Tracing the route to 10.10.4.4 1 10.10.12.2 44 msec 44 msec 20 msec 2 10.10.234.4 60 msec * 72 msec
What happens if the forwarding address network is not advertised? We will
do some filtering on R2.
R2(config-router)#area 1 range 10.10.234.0 255.255.255.0 not-advertise R3(config-router)#area 1 range 10.10.234.0 255.255.255.0 not-advertise R1#sh ip route 10.10.4.0 % Subnet not in table
There is no reachability for the network any longer? How can we resolve
this without removing the filtering?
We can tell R3 to suppress the FA in the LSA.
R3(config-router)#area 1 nssa translate type7 suppress-fa
The network is back and we have reachability but now traffic must pass
through R3 since the FA is not set.
R1#sh ip route 10.10.4.0
Routing entry for 10.10.4.0/24
Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 2
Last update from 10.10.12.2 on FastEthernet0/0, 00:00:07 ago
Routing Descriptor Blocks:
* 10.10.12.2, from 3.3.3.3, 00:00:07 ago, via FastEthernet0/0
Route metric is 20, traffic share count is 1
R1#traceroute 10.10.4.4
Type escape sequence to abort.
Tracing the route to 10.10.4.4
1 10.10.12.2 52 msec 76 msec 48 msec
2 10.10.23.3 36 msec 48 msec 40 msec
3 10.10.234.4 72 msec * 72 msec
So by setting the FA we achieve more effecient routing. The reason to have
a forwarding address is to reduce the number of LSAs needed. If all ABRs were
doing type 7 to type 5 translation then there would be more LSAs than what is
optimal.
Lets take a look at the LSA now. Note that the FA will be set to 0.0.0.0.
R1#sh ip ospf data ex 10.10.4.0
OSPF Router with ID (10.10.13.1) (Process ID 1)
Type-5 AS External Link States
Routing Bit Set on this LSA
LS age: 212
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 10.10.4.0 (External Network Number )
Advertising Router: 3.3.3.3
LS Seq Number: 80000003
Checksum: 0x6218
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
By default the FA is always set when using NSSA areas. Now we take a look
at another use case where we have another routing protocol involved and
redistribution is done between the routing domains.
This is our example topology. Very similar to before. We just changed from
OSPF to RIP on the lefthand side.
R3 will be the router doing mutual redistribution between RIP and OSPF.
We will see that the FA will be set to 0.0.0.0. We check the route on R1.
R1#sh ip route 10.10.4.0
Routing entry for 10.10.4.0/24
Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 2
Last update from 10.10.12.2 on FastEthernet0/0, 00:01:07 ago
Routing Descriptor Blocks:
* 10.10.12.2, from 3.3.3.3, 00:01:07 ago, via FastEthernet0/0
Route metric is 20, traffic share count is 1
R1#sh ip ospf data ex 10.10.4.0
OSPF Router with ID (10.10.13.1) (Process ID 1)
Type-5 AS External Link States
Routing Bit Set on this LSA
LS age: 79
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 10.10.4.0 (External Network Number )
Advertising Router: 3.3.3.3
LS Seq Number: 80000001
Checksum: 0x6616
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
As expected the FA is set to 0.0.0.0. This means that traffic must traverse
R3. We confirm with a traceroute.
R1#traceroute 10.10.4.4 Type escape sequence to abort. Tracing the route to 10.10.4.4 1 10.10.12.2 64 msec 28 msec 24 msec 2 10.10.23.3 68 msec 40 msec 40 msec 3 10.10.234.4 96 msec * 76 msec
Now what happens if we enable OSPF on R3 interface towards R4?
R3(config-if)#ip ospf 1 area 0 R1#traceroute 10.10.4.4 Type escape sequence to abort. Tracing the route to 10.10.4.4 1 10.10.12.2 56 msec 32 msec 24 msec 2 10.10.234.4 60 msec * 72 msec
Traceroute is now takinig the shorter path. How did this happen? Take a
look at the LSA on R1.
R1#sh ip ospf data ex 10.10.4.0
OSPF Router with ID (10.10.13.1) (Process ID 1)
Type-5 AS External Link States
Routing Bit Set on this LSA
LS age: 59
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 10.10.4.0 (External Network Number )
Advertising Router: 3.3.3.3
LS Seq Number: 80000002
Checksum: 0x7107
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 10.10.234.4
External Route Tag: 0
The FA has now been set. How did this happen? The FA will be set for
external routes if we meet the following conditions.
- OSPF is enabled on the ASBR’s next hop interface AND
- ASBR’s next hop interface is non-passive under OSPF AND
- ASBR’s next hop interface is not point-to-point AND
- ASBR’s next hop interface is not point-to-multipoint AND
- ASBR’s next hop interface address falls under the network range specified in the router ospf command.
So we have met all the conditions needed to set the FA. I hope that
you know have a better understanding of the forwarding address and
as usual always poste questions/feedback in the comments field.
Some interesting facts of OSPF
OK so clearly I haven’t been updating a lot lately due to my very busy situation. I’m sorry for that but my former colleague Henri keeps nagging me for an update so I decided to write on some interesting tidbits of OSPF that I gathered in my notes recently.
We start with doing MD5 authentication to show something interesting.
R1#sh run int f0/0 Building configuration... Current configuration : 151 bytes ! interface FastEthernet0/0 ip address 12.12.12.1 255.255.255.0 ip ospf authentication message-digest ip ospf 1 area 0
The adjacency comes up even though no key has been configured, everything should be fine right? CCIE candidates don’t get off that easily, we need to verify.
%OSPF-5-ADJCHG: Process 1, Nbr 12.12.12.2 on FastEthernet0/0 from LOADING to FULL, Loading Done
R1#sh ip ospf int f0/0 | be Message
Message digest authentication enabled
No key configured, using default key id 0
So we are using a default key even though we didn’t configure any key! What is the next step in verifying? Debug…
R1#debug ip ospf adj OSPF adjacency events debugging is on R1# *Mar 1 00:08:11.327: OSPF: Send with youngest Key 0
Indeed, authentication is working without a key! Not that useful but still an interesting fact.
OSPF does not use key chains like EIGRP and RIP. What can we do if we want to change the key used without disrupting the adjacency? We start by defining a key with ID 3.
R1(config-if)#ip ospf message-digest-key 3 md5 cisco
Then we configure another key with ID 1.
R1(config-if)#ip ospf message-digest-key 1 md5 cisco1
R1#sh ip ospf int f0/0 | be Message
Message digest authentication enabled
Youngest key id is 1
Rollover in progress, 1 neighbor(s) using the old key(s):
key id 3
So the old key is using ID 3 and the router will accept that key until the other side is also configured for key with ID 1. Now what happens if we configure another key with ID 5?
R1#sh ip ospf int f0/0 | be Message
Message digest authentication enabled
Youngest key id is 5
Rollover in progress, 1 neighbor(s) using the old key(s):
key id 3
key id 1
So now we have two old keys and the newest one is the one with ID 5. I just wanted to show that the ID itself does not decide which one is newer, the last one you enter is the youngest key. So if we want to do a rollover we simply configure one side with the newer key and then the other side and the adjacency won’t flap.
When the keys are matching the output will look like this:
R1#sh ip ospf int f0/0 | be Message
Message digest authentication enabled
Youngest key id is 5
You might have heard that OSPF is distance vector between areas, how can we prove this? Lets try a simple 3 router setup looking like this.
We configure OSPF according to the topology and check that R3 is receiving the loopback of R1.
R3#sh ip route 1.1.1.1
Routing entry for 1.1.1.1/32
Known via "ospf 1", distance 110, metric 3, type inter area
Last update from 23.23.23.2 on FastEthernet0/0, 00:00:02 ago
Routing Descriptor Blocks:
* 23.23.23.2, from 12.12.12.2, 00:00:02 ago, via FastEthernet0/0
Route metric is 3, traffic share count is 1
Which it is. Now what happens if we use a distribute-list on R2? OSPF is link state and LSA should still be advertised?
R2(config)#ip prefix-list DENY_R1_LO deny 1.1.1.1/32 R2(config)#ip prefix-list DENY_R1_LO permit 0.0.0.0/0 le 32 R2(config)#router ospf 1 R2(config-router)#distribute-list prefix DENY_R1_LO in
Is the prefix still in R3s routing table?
R3#sh ip route 1.1.1.1
% Network not in table
R3#sh ip ospf data sum 1.1.1.1
OSPF Router with ID (23.23.23.3) (Process ID 1)
There is not even a LSA there. What about R2?
R2#sh ip route 1.1.1.1
% Network not in table
R2#sh ip ospf data sum 1.1.1.1
OSPF Router with ID (12.12.12.2) (Process ID 1)
Summary Net Link States (Area 0)
Routing Bit Set on this LSA
LS age: 344
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 1.1.1.1 (summary Network Number)
Advertising Router: 12.12.12.1
LS Seq Number: 80000001
Checksum: 0x3ED4
Length: 28
Network Mask: /32
TOS: 0 Metric: 1
There is a type 3 LSA originating from R1 but R2 is not originating one for area 2. It is proven that OSPF is distance vector between areas!
Finally I want to show something that can be useful when you want to take a router out of service gracefully. Rather than just rebooting or shutting down links it can be down this way. First we announce loopback from R3 and verify that it is seen on R2.
R1#sh ip route 3.3.3.3
Routing entry for 3.3.3.3/32
Known via "ospf 1", distance 110, metric 3, type inter area
Last update from 12.12.12.2 on FastEthernet0/0, 00:00:00 ago
Routing Descriptor Blocks:
* 12.12.12.2, from 12.12.12.2, 00:00:00 ago, via FastEthernet0/0
Route metric is 3, traffic share count is 1
OK, so the route is there. Now assume that we want to take R3 out of service. How can we do that? By setting the LSA to the maximum metric available. If there is any other path to reach the prefix that will be preferred.
R3(config-router)#max-metric router-lsa
Now we have a look at R2. All router LSAs from R3 now have a maximum metric of 65535. So the route is not installed in the RIB.
R2#sh ip ospf data router 23.23.23.3
OSPF Router with ID (12.12.12.2) (Process ID 1)
Router Link States (Area 2)
Routing Bit Set on this LSA
LS age: 30
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 23.23.23.3
Advertising Router: 23.23.23.3
LS Seq Number: 80000005
Checksum: 0xEC21
Length: 36
Area Border Router
Number of Links: 1
Link connected to: a Transit Network
(Link ID) Designated Router address: 23.23.23.3
(Link Data) Router Interface address: 23.23.23.3
Number of TOS metrics: 0
TOS 0 Metrics: 65535
This means that we can do work on a router and announce all router LSAs with the maximum metric and when we are done we remove the maximum metric and traffic will once again flow through the router. It’s a good option for those planned maintenance windows.
That’s all for this time!
OSPF: Anatomy of a routing protocol
To become a CCIE you need detailed knowledge of OSPF. Most candidates will have read the TCP/IP Volumes by Doyle and maybe even the RFC written by J Moy.
This book is also written by J Moy and it is basically the bible on OSPF. The great thing about this book is that is like a less dry version of the RFC and it explains the design decisions in OSPF.
Why did they choose to make it link state instead of distance vector? RIP had issues with large networks and the large updates being sent and your network diameter was limited due to the hop count limit. Why did they choose to run it over IP instead of making it a link layer protocol or run it over UDP or TCP? This is also explained in the book.
Creating a protocol takes a lot of work and making it interoperable is a challenge. Moy describes how they did interoperability tests where the first test was hosted at Proteon. It was a common occurence to see developers from several companies leaning over a competitor’s shoulder, trying to fix a bug!
I’m still reading the book but it has been great so far. I you get a Safari subscription you can read all the books you like. I recently did and I can really recommend it.
OSPF magic – Make interarea routes become intraarea
This is a follow up post to my last OSPF post about repairing area 0.
In the comments section Ray asked me what we can do if we have a
scenario where we have another area that is discontigous. In this
example we are using area 1. Area 1 is used everywhere but between
R1 and R4 is the backbone area. The routes will therefore be
interarea. What if we were told to make these routes appear as
intra area? First look at the topology. Download .net file and
initial and final configs here.
First we start by confirming that routes received on R1
are coming in as interarea routes.
Yes they are. This is expected behaviour. So what can we do to
make them appear as intraarea? Using a virtual link does not help
since it always belongs to area 0. We could use the tunnel technique
that was used in the previous post. Let’s try that. Same procedure as
last time. Source tunnel from physical interface. Use IP unnumbered
from an interface in area 1.
The tunnel is up and we have a new adjacency.
The IP address is 0.0.0.0/0 and located in area 1. Lets look at the
router LSA for area 1.
The address is 0.0.0.16 just as the last time. This should be 10 according
to the SNMP MIB but as one of my friends Patrick pointed out 16 in decimal
is 0×10 in hex. Maybe it is encoded in hex?
So now lets check the routing table.
Problem solved. Routes are now received as intraarea. So there you have it,
another OSPF problem solved.
Repairing a discontigous area 0 in OSPF
First start by looking at the diagram above. This is a scenario I ran into while
doing my mock lab. It is pretty obvious that we will have issues with OSPF since area 0
is discontigous. You should be able to spot this by just looking at the diagram.
So what are the tools we have to repair discontigous areas? The most common and
straightforward is to use a virtual-link. However in this scenario it is not allowed.
First lets look what issues we will have in this topology. I have prepared the
topology and initial configs with OSPF for you which can be downloaded here, final configs are also included.
We start by looking at the routing table of R1.
We can only see the loopback of R2. Why is that? R1 is an ABR. It has an
interface in area 0 and in another area. It will not install interarea routes
received on a non backbone interface.
This is the database on R1. We can see that all IA routes are indeed in
the database but they are not being installed into the RIB. To test our
thesis from the last OSPF post, lets shutdown Fa0/0 on R1. This should in
theory mean that R1 is no longer an ABR and that it can install routes
received on a non backbone area.
It works. So our knowledge of OSPF seems good. So this is an option we
can use, although we would not have reachability to R2′s loopback. The techniques
I show here would generate no points for the OSPF section but having reachability
in IGP is critial so if you can’t do something the right way, cheat!
What I mean by that is that if you don’t have reachability you will loose points
later in BGP, MPLS, multicast and maybe even IPv6 and security section. So you
see a lot of points are at stake and if we can’t solve a task the right way do it
some other way. Use static routes if you must!
We were not allowed to use a virtual-link but lets try that anyway to
see that we can install all the routes.
Yes, now we have reachability. We would loose 2 or 3 points probably for doing
this but could potentially save us 10-15 points later. I ended up having to do
this on my mock since I had problems configuring the solution below.
So if we can’t use a virtual link, where does that leave us? We need a link
between R1 and R4 that is located in area 0. How about a tunnel? Yes, that is
definately an option. However we are not allowed to introduce any new
IP addresses into the network. How do we solve that? IP unnumbered, we have to
borrow an IP from another interface. Lets setup the tunnel.
We source the tunnel from a physical interface and the destination is the other
side of the FR connection. Why source from the physical interface? We don’t have
reachability to loopbacks yet since our IGP is broken, therefore we have to use
the physical address. Why unnumbered from the Ethernet interfaces? They are located
in area 0. We must have an IP that is located in area 0 to repair the discontigous network.
So now we have an adjacency both over serial0/0 and over the tunnel. The tunnel
interface is point-to-point and has a very high cost. Notice that the IP for
the tunnel is 0.0.0.0/0.
Now look at the routing table of R1.
We can see that prefixes are reached via 155.1.34.4. This is the IP of Fa0/0
on R4 which was derived from the IP unnumbered. So what is interesting here
is that the adjacency between R1 and R4 is not in the same subnet, so we
are bypassing that check. We can also see that we need to recurse routing
lookups since the routes are pointing at 155.1.34.4.
This route is reached via the tunnel. If we look at the OSPF database on R1
we see a router LSA for R4 and there is the P2P link.
Router Interface address is 0.0.0.16. This is interesting, normally this is
the IP address of the interface. We are now using unnumbered. I’m not sure
why it is choosing 16. RFC says the following:
“For unnumbered point-to-pointlinks, the Link Data field should be set to
the unnumbered interface’s MIB-II [Ref8] ifIndex value.
If we look at the SNMP MIB, must enable SNMP first.
So this value should be 10. Seems like Cisco is not really following
the RFC (RFC2328) here. We can enable that behaviour with interface-id snmp-if-index.
Now we have the expected value of 10.
You can read more at Cisco.
So this should give you a look into OSPF. I have also attached a packet capture so that you can look at the LS Update going over the tunnel interface. We can see that the source of the
packet is 155.1.14.4 which is R4 IP addess and the destination is 155.1.14.1.
In there we have the other IP packet which has a source of 155.1.34.4 and a destination
of 224.0.0.5.
How well do you really know OSPF?
OSPF is by far the most complicated IGP on the RS lab if we go in to the details of the protocol and the loop prevention mechanisms. While doing some labs this week I ran in to some interesting issues. This post will describe different scenarios and test your understanding of OSPF. I will show a diagram and ask a question, try to answer it and when you want to know the answer then the text is hidden below. You can see the text by marking it since it’s written with a white font.
Lets begin. We will start with an issue I ran into while doing an ASET lab (Cisco partner labs). Look at the following diagram.
R5 is a PE in a MPLS VPN backbone. R5 is running OSPF in a VRF towards the CE R4. However R5 will not install interarea routes received from R4, why? Look at the following output.
R5#sh ip ospf data sum 1.1.1.3
OSPF Router with ID (1.1.1.5) (Process ID 100)
OSPF Router with ID (5.5.5.5) (Process ID 1)
Summary Net Link States (Area 51)
Routing Bit Set on this LSA
LS age: 1386
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 1.1.1.3 (summary Network Number)
Advertising Router: 1.1.1.4
LS Seq Number: 80000003
Checksum: 0xED3
Length: 28
Network Mask: /32
TOS: 0 Metric: 76
R5 is part of the MPLS super backbone (area0) so it is an ABR. ABRs will not install interarea routes that are received over a non backbone area. If the area between R4 and R5 was area 0 then there would be no issues but since we are using area 51 we have to use a workaround. We enable the capability vrf-lite under the ospf process which disables the loop checks of the PE
Now lets define some of the concepts of OSPF and test your understanding. Look at the diagram.
Is R3 an ABR?
No, the definition is that an ABR is a router with an UP interface in the backbone area and at least another area.
Will R3 generate IA routes for Area 1 and 2?
No, it is not an ABR so it will not generate any IA routes.
Now we create a loopback on R3 and put it in OSPF area 0. No OSPF adjacencies can of course be built over this interface. Will R3 generate any summary routes now?
Yes, even though R3 is not really connected to Area 0 it has an UP interface in area 0 so it will announce itself as an ABR and generate summary routes.
R2#sh ip ospf border-routers
OSPF Process 1 internal Routing Table
Codes: i – Intra-area route, I – Inter-area route
i 1.1.1.1 [1] via 155.1.12.1, FastEthernet0/1, ABR, Area 1, SPF 7
i 3.3.3.3 [1] via 155.1.23.3, FastEthernet0/0, ABR, Area 1, SPF 7
Summary Net Link States (Area 1)
Link ID ADV Router Age Seq# Checksum
33.33.33.33 3.3.3.3 13 0×80000001 0×004566
155.1.16.0 1.1.1.1 1958 0x8000000D 0x00B9C5
155.1.34.0 1.1.1.1 939 0×80000006 0x00155D
155.1.34.0 3.3.3.3 19 0×80000001 0x00CEA2
155.1.35.0 1.1.1.1 942 0×80000006 0x00145C
155.1.35.0 3.3.3.3 21 0×80000001 0x00C3AC
155.1.45.0 1.1.1.1 942 0×80000006 0x009BCB
155.1.45.0 3.3.3.3 21 0×80000001 0x005F06
155.1.46.0 1.1.1.1 942 0×80000006 0x0086E0
If we traceroute the IP of R5 this is the path.
R1#traceroute 155.1.35.5
Type escape sequence to abort.
Tracing the route to 155.1.35.5
1 155.1.16.6 140 msec 76 msec 48 msec
2 155.1.46.4 92 msec 64 msec 64 msec
3 155.1.45.5 184 msec * 108 msec
Why is this and how can we make the path go directly from R1 to R3 to R5? Look at the OSPF database.
Summary Net Link States (Area 1)
Link ID ADV Router Age Seq# Checksum
33.33.33.33 3.3.3.3 534 0×80000001 0×004566
155.1.16.0 1.1.1.1 437 0x8000000E 0x00B7C6
155.1.34.0 1.1.1.1 1459 0×80000006 0x00155D
155.1.34.0 3.3.3.3 542 0×80000001 0x00CEA2
155.1.35.0 1.1.1.1 1463 0×80000006 0x00145C
155.1.35.0 3.3.3.3 543 0×80000001 0x00C3AC
155.1.45.0 1.1.1.1 1463 0×80000006 0x009BCB
155.1.45.0 3.3.3.3 543 0×80000001 0x005F06
155.1.46.0 1.1.1.1 1463 0×80000006 0x0086E0
R3 is announcing the summary but it is not being used by R1. Why?
R1 and R4 have full adjacencies via Area 0 so they will not accept summary routes received on a non backbone interface. To fix this we need a full adjacency between R1 and R3 which is created with a virtual link.
R3(config-router)#area 1 virtual-link 1.1.1.1
R1(config-router)#area 1 virtual-link 3.3.3.3
R1#sh ip ospf data sum 155.1.35.0
OSPF Router with ID (1.1.1.1) (Process ID 1)
Summary Net Link States (Area 0)
Routing Bit Set on this LSA
LS age: 10 (DoNotAge)
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 155.1.35.0 (summary Network Number)
Advertising Router: 3.3.3.3
LS Seq Number: 80000001
Checksum: 0xC3AC
Length: 28
Network Mask: /24
TOS: 0 Metric: 1
R1#traceroute 155.1.35.5
Type escape sequence to abort.
Tracing the route to 155.1.35.5
1 155.1.13.3 64 msec 40 msec 44 msec
2 155.1.35.5 80 msec * 64 msec
R1 is now using the direct path since R3 is now a real ABR. However as R3 now has an adjacency to Area 0 it will no longer accept summary routes from R4. If we want to fix this another virtual link is needed.
I hope this post gave you some things to think about regarding OSPF. This post was mostly inspired by the great document from Petr Lapukhov
