[Xorp-users] OSPF point-to-multipoint issue

[Vincent, Michael - 0665 - MITLL]

We're doing some testing with 6 Redhat VM's.

# uname -a
Linux nlet-89-1 2.6.18-194.el5.g63 #1 SMP Wed Apr 7 00:08:09 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux

All the VM's have an interface to 172.16.1.0 /24 on which OSPF is configured in point to multipoint mode creating a full-mesh.

We're using a linux kernel module to selectively drop packets between certain hosts (based on MAC address) to simulate link loss.  We expect OSPF to route around the failures by multi-hopping to hosts it can still reach.  This works fine.

----
EXAMPLE:
- host IP's are host numbers
- IP's are on interface eth1
- eth1 is OSPF point-to-multipoint *

        host1      host2

host3     172.16.1.0/24    host4

    host5              host6

* Example config for host1
protocols {
    ospf4 {
        router-id: 10.10.1.1
        area 0.0.0.0 {
            area-type: "normal"
            interface eth1 {
                link-type: "p2m"
                vif eth1 {
                    address 172.16.1.1 {
                        hello-interval: 1
                        router-dead-interval: 4
                        neighbor 172.16.1.2 {
                            router-id: 10.10.1.2
                        }
...
----

As we simulate loss of link between host1 and host3, host1 continues to forward packets to host3 via a new host route created to host5.  This is verified by a "route -n" from the linux command line also.

ISSUE:
When we re-establish the link between host1 and host3, host1 *CONTINUES* to forward packets to host3 via the host route created to host5.  OSPF does *NOT* recover and remove the host route from the table.  This is verified by a "route -n" from the linux command line also.


QUESTION:
Is there some configuration option I'm missing that will allow OSPF to remove host routes from the routing table (and kernel/linux routing table) when OSPF converges?


It's important to note we did this exact experiment with Quagga 0.99.16 (ospfd) and it behaved as expected - OSPF recovered and the multi-hop host route was removed.


    Cheers.

-- 
Michael J. Vincent
Group 65 - Advanced Networks and Applications
MIT Lincoln Laboratory
244 Wood Street
Lexington, MA 02420
Office:  +1.781.981.3459