Skip to content

OSPF forwarding address

November 11, 2011
By Administrator in All, Routing protocols

This article is about an exotic feature available in the OSPF routing protocol. Namely, using the OSPF concept of forwarding address. This same address helps to block hosts or subnets throughout the OSPF domain while configuring only a single router. The underlying assumption is that we can block only destination addresses. This limits the use of the feature, but still we gain two big advantages:

  • First, the traffic is not filtered by an ACL. Instead it is routed and every router does it much more efficiently because it is a router after all.
  • Second, the configuration management is concentrated on one router only and changes are propagated throughout the OSPF network. Think about it if your network numbers 50 routers and you will be writing and rewriting the same ACL 50 times.

One additional advantage is time. Changes are propagates instantaneously and to me this advantage seems bigger than the above.
To achieve this behavior however, there are some prerequisites to be considered (we find them in the official Cisco web site) and some knowledge of the intricacies of the OSPF LSA structure.

A small piece of theory

We start with some theory from Cisco:

Theory from Cisco

What is forwarding address and what is its purpose? It was introduced to avoid extra hops when traffic is routed to an external Autonomous System. When the ASBR router redistributes routing information into OSPF it advertizes it as Type 5 LSA (or Type 7 if the area is NSSA). When doing this the advertizing router becomes the next hop (or forwarding address) for the routes it redistributes into the OSPF domain. The forwarding address concept allows an alternative IP address to be specified as a next hop. When routing to inter-area or external routes the behavior of OSPF resembles the distance vector routing protocols. Generally the next hop address is determined by the Shortest Path First algorithm and we are not allowed to influence its choice. But in case of external routes the forwarding address can be set to a different value than the 0.0.0.0 route.

The 0.0.0.0 address indicates that the originating router (the ASBR) is the next hop. And this is usually the case. If ALL of the conditions below are met, then the forwarding address can be set to a non-0.0.0.0 address:

  • OSPF is enabled on the ASBR’s next hop interface
  • ASBR’s next hop interface is non-passive under OSPF
  • ASBR’s next hop interface is not point-to-point
  • ASBR’s next hop interface is not point-to-multipoint
  • ASBR’s next hop interface address falls under the network range specified in the router ospf command.

Any other conditions besides these set the forwarding address to 0.0.0.0. Though the list may seem lengthy the conditions are easily met and we shouldn’t worry about them.

Network topology

And now it’s time to attend to our network topology and see how this concept is put into practice. All routers are situated in area 0 for simplicity. R1 has a loopback0 interface with an IP address of 10.0.0.1/32. It is the router on which ACL management will occur and for this reason it will be redistributing locally configured static routes into OSPF. Static routes will act as an ACL for the destination addresses. R2 has a loopback0 interface with an IP address 10.0.0.2/32 and It has two more loopback interfaces, which will be used for testing how OSPF ACL works (though we can do without them). R3 has a loopback0 interface with an IP 10.0.0.3/32. The three routers are connected in a full mesh topology as per the diagram. These loopback0s will be router IDs in OSPF domain.

Networking topology diagram:

Network topology

Network topology

We skip initial router configurations because there is nothing special about them. The more interesting commands will be shown in the article. First we test connectivity between R1 and R2 loopback 20.

R1
R1#ping 10.20.0.1

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

When connectivity is verified we also check R1 routing table for the route to 10.20.0.0/24:

R1
R1#sh ip route | in 10.20.0.0

O       10.20.0.1/32 [110/2] via 10.0.2.2, 00:00:24, FastEthernet0/0

As expected there is a host route present for 10.20.0.1 which is the default OSPF behavior for loopback interfaces. To change it we must change the network type:

R2
R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.

R2(config)#int loopback 20
R2(config-if)#ip ospf network point-to-point

And check again R1 routing table:

R1
R1#sh ip route | in 10.20.0.0

O       10.20.0.0/24 [110/2] via 10.0.2.2, 00:00:24, FastEthernet0/0

Now the host route has been replaced with the R2 loopback20 interface subnet.

Additional configuration

And we are ready for testing. Before that a brief explanation is needed about the idea employed in black hole routing. We use it as a substitution of ACLs. On R1 we configure a static route for the subnet we’ll be going to drop packets to. In our case this is 10.20.0.0/28. The subnet mask is 28 bits because the route should be more precise for OSPF to install it in the routing table. Otherwise inter-area routes will always be preferred to external. The most important thing about this route is the next hop address. It should be a free IP address from the directly connected subnets. We’ll test both of them. And the latter IP address will be advertised in Type 5 LSA as Forwarding Address provided, all prerequisites are met. I’ve chosen an unoccupied address of 10.0.1.200. One last thing. In order to drop the packets we also add a host route for 10.0.1.200 directing it to the null interface. Here is the necessary configuration on R1:

R1
R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#ip route 10.0.1.200 255.255.255.255 null0
R1(config)#ip route 10.20.0.0 255.255.255.240 10.0.1.200
R1(config)#router ospf 1
R1(config-router)#redistribute static subnets

R1#ping 10.20.0.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.20.0.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

We are redistributing the static route we’ve just configured and it is advertised throughout the OSPF domain. Next we tested the configuration and now R1 drops the packets destined to 10.20.0.1. We also need to verify R2 and R1 OSPF database to see if the forwarding address is correctly set.

R2
R2#sh ip ospf database external 10.20.0.0

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

                Type-5 AS External Link States

  LS age: 489
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 10.20.0.0 (External Network Number )
  Advertising Router: 10.0.0.1
  LS Seq Number: 80000001
  Checksum: 0x970B
  Length: 36
  Network Mask: /28
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 20
        Forward Address: 10.0.2.200
        External Route Tag: 0
R1
R1#sh ip ospf database external 10.20.0.0

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

                Type-5 AS External Link States

  LS age: 623
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 10.20.0.0 (External Network Number )
  Advertising Router: 10.0.0.1
  LS Seq Number: 80000001
  Checksum: 0x970B
  Length: 36
  Network Mask: /28
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 20
        Forward Address: 10.0.2.200
        External Route Tag: 0

Indeed both routers have the correct address in place. The same steps are repeated for the 10.30.0.0/28 route except that we already have redistribution working. And verification:

R2
R2#sh ip ospf database external 10.30.0.0

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

                Type-5 AS External Link States

  LS age: 145
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 10.30.0.0 (External Network Number )
  Advertising Router: 10.0.0.1
  LS Seq Number: 80000001
  Checksum: 0xB7F0
  Length: 36
  Network Mask: /28
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 20
        Forward Address: 10.0.1.200
        External Route Tag: 0

An unanticipated issue

So far so good. If we check R2 routing table, however, we see that neither of the routes is installed:

R2
R2#sh ip route

Gateway of last resort is not set

     10.0.0.0/8 is variably subnetted, 12 subnets, 2 masks
S       10.0.2.10/32 is directly connected, Null0
C       10.0.2.0/24 is directly connected, FastEthernet0/0
C       10.0.0.2/32 is directly connected, Loopback0
O       10.0.0.3/32 [110/2] via 10.0.3.1, 01:57:11, FastEthernet0/1
C       10.0.3.0/24 is directly connected, FastEthernet0/1
O       10.0.0.1/32 [110/2] via 10.0.2.1, 01:57:11, FastEthernet0/0
O       10.0.1.0/24 [110/2] via 10.0.3.1, 01:57:11, FastEthernet0/1
                    [110/2] via 10.0.2.1, 01:57:11, FastEthernet0/0
C       10.30.0.0/24 is directly connected, Loopback30
C       10.20.0.0/24 is directly connected, Loopback20
O E2    10.0.2.200/32 [110/20] via 10.0.2.1, 01:57:11, FastEthernet0/0

The advertisement is received but it is not installed in the routing table. If we change the forwarding address the route is not installed either.

R1
R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#no ip route 10.30.0.0 255.255.255.0 10.0.1.200
%No matching route to delete
R1(config)#no ip route 10.30.0.0 255.255.255.240 10.0.1.200
R1(config)#ip route 10.30.0.0 255.255.255.240 10.0.2.200
R1(config)#exit

The result is the same:

R2
R2#sh ip route

Gateway of last resort is not set

     10.0.0.0/8 is variably subnetted, 10 subnets, 2 masks
C       10.0.2.0/24 is directly connected, FastEthernet0/0
C       10.0.0.2/32 is directly connected, Loopback0
O       10.0.0.3/32 [110/2] via 10.0.3.1, 00:02:05, FastEthernet0/1
C       10.0.3.0/24 is directly connected, FastEthernet0/1
O       10.0.0.1/32 [110/2] via 10.0.2.1, 00:02:05, FastEthernet0/0
O       10.0.1.0/24 [110/2] via 10.0.3.1, 00:02:05, FastEthernet0/1
                    [110/2] via 10.0.2.1, 00:02:05, FastEthernet0/0
C       10.30.0.0/24 is directly connected, Loopback30
C       10.20.0.0/24 is directly connected, Loopback20
O E2    10.0.2.200/32 [110/20] via 10.0.2.1, 00:02:05, FastEthernet0/0

To cut the long story short, if the forwarding address is received as an external route by the OSPF the route using it as a next hop is not placed in the routing table. We can fix the problem by configuring another next hop address on R1 and then routing it to the previous next hop of 10.0.1.200 which in turn is sent to null:

R1
R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#no ip route 10.20.0.0 255.255.255.240 10.0.1.200
R1(config)#no ip route 10.30.0.0 255.255.255.240 10.0.1.200
R1(config)#ip route 10.20.0.0 255.255.255.240 10.0.1.10
R1(config)#ip route 10.30.0.0 255.255.255.240 10.0.1.10
R1(config)#ip route 10.0.2.10 255.255.255.255 10.0.2.200

And if we now check R2 routing table, this is the result:

R2
R2#sh ip route

Gateway of last resort is not set

     10.0.0.0/8 is variably subnetted, 13 subnets, 3 masks
C       10.0.2.0/24 is directly connected, FastEthernet0/0
C       10.0.0.2/32 is directly connected, Loopback0
O       10.0.0.3/32 [110/2] via 10.0.3.1, 02:14:32, FastEthernet0/1
C       10.0.3.0/24 is directly connected, FastEthernet0/1
O       10.0.0.1/32 [110/2] via 10.0.2.1, 02:14:32, FastEthernet0/0
O       10.0.1.0/24 [110/2] via 10.0.3.1, 02:14:32, FastEthernet0/1
                    [110/2] via 10.0.2.1, 02:14:32, FastEthernet0/0
O E2    10.30.0.0/28 [110/20] via 10.0.2.10, 00:09:26, FastEthernet0/0
C       10.30.0.0/24 is directly connected, Loopback30
O E2    10.20.0.0/28 [110/20] via 10.0.2.10, 00:09:27, FastEthernet0/0
C       10.20.0.0/24 is directly connected, Loopback20
O E2    10.0.2.200/32 [110/20] via 10.0.2.1, 00:09:28, FastEthernet0/0
S       10.0.1.201/32 is directly connected, Null0
S       10.0.1.200/32 [1/0] via 10.0.1.201

The route is installed as external type 2 and the forwarding address is set to the new IP. The same check for R3:

R3
R3#sh ip route

Gateway of last resort is not set

     10.0.0.0/8 is variably subnetted, 12 subnets, 3 masks
O       10.0.0.2/32 [110/2] via 10.0.3.2, 02:32:12, FastEthernet0/0
O       10.0.2.0/24 [110/2] via 10.0.3.2, 02:32:12, FastEthernet0/0
                    [110/2] via 10.0.1.1, 02:32:12, FastEthernet0/1
C       10.0.3.0/24 is directly connected, FastEthernet0/0
C       10.0.0.3/32 is directly connected, Loopback0
O       10.0.0.1/32 [110/2] via 10.0.1.1, 02:32:12, FastEthernet0/1
C       10.0.1.0/24 is directly connected, FastEthernet0/1
O E2    10.30.0.0/28 [110/20] via 10.0.1.1, 02:32:11, FastEthernet0/1
                     [110/20] via 10.0.3.2, 02:32:12, FastEthernet0/0
O       10.30.0.0/24 [110/2] via 10.0.3.2, 02:32:12, FastEthernet0/0
O E2    10.20.0.0/28 [110/20] via 10.0.1.1, 02:32:12, FastEthernet0/1
                     [110/20] via 10.0.3.2, 02:32:12, FastEthernet0/0
O       10.20.0.0/24 [110/2] via 10.0.3.2, 02:32:12, FastEthernet0/0
O E2    10.50.0.0/24 [110/20] via 10.0.1.1, 02:32:12, FastEthernet0/1
                     [110/20] via 10.0.3.2, 02:32:12, FastEthernet0/0
S       10.0.2.200/32 is directly connected, Null0
S       10.0.1.200/32 is directly connected, Null0

A new surprise – the route is installed but the forwarding address is not used. Instead, we see packets are load-balanced through the two existing interfaces.

The missing forwarding address

The issue is due to the fact that on R3 we don’t have an OSPF enabled interface which contains the next hop address in its subnet scope. In such a case it is just not used. To fix this we issue the following command to create a dummy interface with a subnet of 10.0.2.0/24:

R3
R3#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R3(config)#int loo
R3(config)#int loopback 1
R3(config-if)#ip address
R3(config-if)#ip address 10.0.2.6 255.255.255.0
R3(config-if)#no shut

And check the routing table again:

R3
R3#sh ip route

Gateway of last resort is not set

     10.0.0.0/8 is variably subnetted, 12 subnets, 3 masks
O       10.0.0.2/32 [110/2] via 10.0.3.2, 00:04:19, FastEthernet0/0
C       10.0.2.0/24 is directly connected, Loopback1
C       10.0.3.0/24 is directly connected, FastEthernet0/0
C       10.0.0.3/32 is directly connected, Loopback0
O       10.0.0.1/32 [110/2] via 10.0.1.1, 00:04:19, FastEthernet0/1
C       10.0.1.0/24 is directly connected, FastEthernet0/1
O E2    10.30.0.0/28 [110/20] via 10.0.2.10, 00:04:19, Loopback1
O       10.30.0.0/24 [110/2] via 10.0.3.2, 00:04:19, FastEthernet0/0
O E2    10.20.0.0/28 [110/20] via 10.0.2.10, 00:04:19, Loopback1
O       10.20.0.0/24 [110/2] via 10.0.3.2, 00:04:19, FastEthernet0/0
S       10.0.2.200/32 is directly connected, Null0
S       10.0.1.200/32 is directly connected, Null0

This time R3 is using the forwarding address and the newly configured interface. One more thing is needed to drop packets:

R3
R3#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R3(config)#ip route 10.0.2.10 255.255.255.255 null0
R3(config)#exit

Same configuration on R2:

R2
R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#ip route 10.0.2.10 255.255.255.255 null0
R2(config)#exit

And just to make sure everything is working as expected we configure an extended ACL to capture icmp packets destined to 10.20.0.1 and issue the debug ip packet command:

R2
R2#debug ip packet 100
IP packet debugging is on for access list 100
R2#ping 10.20.0.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.20.0.1, timeout is 2 seconds:

04:18:00: IP: tableid=0, s=10.0.2.2 (local), d=10.20.0.1
(FastEthernet0/0), routed via RIB
04:18:00: IP: s=10.0.2.2 (local), d=10.20.0.1
(FastEthernet0/0), len 100, sending
04:18:00: IP: s=10.0.2.2 (local), d=10.20.0.1
(FastEthernet0/0), len 100, encapsulation failed.
04:18:02: IP: tableid=0, s=10.0.2.2 (local), d=10.20.0.1
(FastEthernet0/0), routed via RIB
04:18:02: IP: s=10.0.2.2 (local), d=10.20.0.1
(FastEthernet0/0), len 100, sending
04:18:02: IP: s=10.0.2.2 (local), d=10.20.0.1
(FastEthernet0/0), len 100, encapsulation failed.
04:18:04: IP: tableid=0, s=10.0.2.2 (local), d=10.20.0.1
(FastEthernet0/0), routed via RIB
04:18:04: IP: s=10.0.2.2 (local), d=10.20.0.1
(FastEthernet0/0), len 100, sending
04:18:04: IP: s=10.0.2.2 (local), d=10.20.0.1
(FastEthernet0/0), len 100, encapsulation failed.
04:18:06: IP: tableid=0, s=10.0.2.2 (local), d=10.20.0.1
(FastEthernet0/0), routed via RIB
04:18:06: IP: s=10.0.2.2 (local), d=10.20.0.1
(FastEthernet0/0), len 100, sending
04:18:06: IP: s=10.0.2.2 (local), d=10.20.0.1
(FastEthernet0/0), len 100, encapsulation failed.
04:18:08: IP: tableid=0, s=10.0.2.2 (local), d=10.20.0.1
(FastEthernet0/0), routed via RIB
04:18:08: IP: s=10.0.2.2 (local), d=10.20.0.1
(FastEthernet0/0), len 100, sending
04:18:08: IP: s=10.0.2.2 (local), d=10.20.0.1
(FastEthernet0/0), len 100, encapsulation failed.
Success rate is 0 percent (0/5)

R2#sh access-lists 100
Extended IP access list 100
    permit icmp any any (15 matches)
R2#

At last, the black hole routing is working.

The easy way

The same results can be achieved if we use loopback interfaces as next hop addresses. So choose an unused subnet, configure OSPF enabled loopback interfaces and everything will be fine concerning OSPF black whole routing. And why didn’t we do that before? For the sake of exercise. Now we know much more about OSPF than before we started. The same topology na configuration is kept.

On R1 we configure loopback100 interface:

R1
R1#sh run int loopback100
Building configuration...

Current configuration : 66 bytes
!
interface Loopback100
 ip address 10.0.100.1 255.255.255.0
end

We add a static route through the loopback interface:

R1
R1#sh run | in 10.70.0.0
ip route 10.70.0.0 255.255.255.0 10.0.100.100

And on R3:

R3
R3#sh run int loopback 100
Building configuration...

Current configuration : 98 bytes
!
interface Loopback100
 ip address 10.0.100.2 255.255.255.0
end

Check OSPF database to verify the forwarding address:

R3
R3#sh ip ospf database external 10.70.0.0

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

                Type-5 AS External Link States

  Routing Bit Set on this LSA
  LS age: 1121
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 10.70.0.0 (External Network Number )
  Advertising Router: 10.0.0.1
  LS Seq Number: 80000002
  Checksum: 0xBCB4
  Length: 36
  Network Mask: /24
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 20
        Forward Address: 10.0.100.100
        External Route Tag: 0

It is non zero so everything is fine. Next check R3 routing table for the new route:

R3
R3#sh ip route | in 10.70.0.0
O E2    10.70.0.0/24 [110/20] via 10.0.100.100, 00:12:19, Loopback100

The only thing left is to direct the 10.0.100.100 IP to the null interface and we are done.

I hope you enjoyed it as much as I did.

Tags: , , , , ,

Comment Feed

No Responses (yet)



Some HTML is OK

or, reply to this post via trackback.