Controlling routing updates in OSPF

SonicOS 5.6 (still in beta at time of writing) has the ability to tunnel dynamic routing protocols over IPSec tunnels. Similar to the way Cisco does this by tunneling dynamic routing updates through GRE, then in turn tunneling the resulting packets through the IPSec tunnel.

In preperation for trying out this new SonicOS feature, I cracked open GNS3 and tried to simulate what would be happening. First things first… it’s important to note that SonicOS actually only supports dynamic routing over route-based VPNs. That is, a virtual interface is created to represent the point-to-point IPSec connection. For routing purposes, this virtual tunnel interface is “borrowing” an IP from an admin chosen interface.

This concept is exactly the same as cisco’s ïp unnumbered”. So we have the basis for our simulation. To make the simulation easier and get rid of stuff that can go wrong, let’s forget about the IPSec tunnel and focus purely on the OSPF part. I setup the below:

In this case, UKTL is the hub, with two spokes. They are interconnected using a serial connection, this serves our purposes of simulating an IPSec point to point connection. Imagine the serial connections are our IPSec VPN tunnels configured on the WAN. All the serial interfaces are not configired with an IP directly, instead, we use the ip unnumbered command to force s0/0 and s0/1 to borrow the IP of lo0 in R3. We have a similar setup on R4 and R5. You can see the effect of the ip unnumbered with the sh ip int br command:

UKTL#sh ip int br
Interface                  IP-Address      OK?     Method  Status                Protocol
Serial0/0                  10.71.20.1      YES          TFTP   up                         up
Serial0/1                  10.71.10.1      YES           TFTP   up                         up
Loopback0                  4.2.2.2         YES         manual up                         up
Loopback1                  10.71.20.1      YES    manual up                         up
Loopback2                  10.71.10.1      YES    manual up                         up

Note how s0/0 shares the IP of lo1 while s0/1 shares the IP of lo2. There are similar setups on spoke_A and spoke_B. Why would we need to do this? Well its a good question. Saving IP address space is a good reason, and having to keep track of less IPs is another plus.

Now we go about configuring UKTL’s OSPF process to share the two networks on its LAN:

router ospf 1

log-adjacency-changes
network 10.71.10.0 0.0.0.255 area 0
network 10.71.20.0 0.0.0.255 area 0

Similarly this mut be done on spoke_A and spoke_B. In this example I’m keeping everything in the same area to simplify the ezersize. If everything goes well you should see the OSPF adjancencies form on UKTL:

UKTL#sh ip ospf neighbor
Neighbor ID          Pri   State           Dead Time           Address         Interface
192.168.200.1     0    FULL/  –        00:00:38    192.168.200.1   Serial0/1
4.3.3.3                    0     FULL/  –        00:00:37    192.168.100.1   Serial0/0

We’re not too concerned with router ID here, since these are point to point network, DR and BDR dont exist. So at this point we should see the routing tables updated with some OSPF routes. For example of UKTL:

Gateway of last resort is not set

4.0.0.0/24 is subnetted, 1 subnets
C       4.2.2.0 is directly connected, Loopback0
192.168.200.0/32 is subnetted, 1 subnets
O       192.168.200.1 [110/65] via 192.168.200.1, 00:03:11, Serial0/1
10.0.0.0/24 is subnetted, 2 subnets
C       10.71.10.0 is directly connected, Loopback2
C       10.71.20.0 is directly connected, Loopback1
O    192.168.100.0/24 [110/65] via 192.168.100.1, 00:03:11, Serial0/0

Not too bad, we see the two spoke network visible via OSPF.  Similarly we see from Spoke_B that we can reach both Spoke_A and the UKTL:

Gateway of last resort is not set

4.0.0.0/24 is subnetted, 1 subnets
C       4.3.3.0 is directly connected, Loopback0
192.168.200.0/32 is subnetted, 1 subnets
O       192.168.200.1 [110/129] via 10.71.20.1, 00:04:04, Serial0/0
10.0.0.0/32 is subnetted, 2 subnets
O       10.71.10.1 [110/65] via 10.71.20.1, 00:04:04, Serial0/0
O       10.71.20.1 [110/65] via 10.71.20.1, 00:04:04, Serial0/0
C    192.168.100.0/24 is directly connected, FastEthernet1/0

Now comes the interesting part. Lets say that we want to distribute an internal network (172.16.1.0 /24) from an internal network on Spoke_B_INT. And to make it interesting lets say that we wont to only distribute that one network, but not the other 172.32.1.0 network.

First of all we see that on spoke_B router we have static routes for both these networks:

172.16.0.0/24 is subnetted, 1 subnets
S       172.16.1.0 is directly connected, FastEthernet1/0
172.32.0.0/24 is subnetted, 1 subnets
S       172.32.1.0 is directly connected, FastEthernet1/

Now, we need to redistribute the first static route to the OSPF area, but not the other. How to? The answer is in the nifty ditribution lists. Distribution lists can control routing updates based on route-maps (which are in themselves extremely flexible) or simple access lists. Our first step is going to be defining an access-list that permits the 172.16.0.0 network but not the 172.32.0.0 network:

access-list 2 permit 172.16.1.0 0.0.0.255
access-list 2 deny   any

Then we go back into the OSPF router mode and type:

spoke_B(config-router)#redistribute static subnets
spoke_B(config-router)#distribute-list 2 out static

Simple huh? The first line instructs OSPF to redistribute static lists. In the second line, the distribute list permits only static routes matchin access list 2 to go out. We confirm this by checking the routing table on UKTL, we should see a single E2 (external route):

Gateway of last resort is not set

4.0.0.0/24 is subnetted, 1 subnets
C       4.2.2.0 is directly connected, Loopback0
172.16.0.0/24 is subnetted, 1 subnets
O E2    172.16.1.0 [110/20] via 192.168.100.1, 00:00:45, Serial0/0
192.168.200.0/32 is subnetted, 1 subnets
O       192.168.200.1 [110/65] via 192.168.200.1, 00:00:50, Serial0/1
10.0.0.0/24 is subnetted, 2 subnets
C       10.71.10.0 is directly connected, Loopback2
C       10.71.20.0 is directly connected, Loopback1
O    192.168.100.0/24 [110/65] via 192.168.100.1, 00:00:50, Serial0/

See the single O E2 route? Further confirmation is done by running the sh ip protocols on spoke_B:

spoke_B#sh ip protocols
Routing Protocol is “ospf 1”
Outgoing update filter list for all interfaces is not set
Redistributed static filtered by 2

The last line shows the redistributed static lists are filtered. All done!!

Note : Dont forget to redistribute static subnets in the first place. You cannot filter unless you are redistributing the routes in the first place🙂

Update : I ran across a similar and useful article from Packetlife…. grab it here