OSPF problems

English Network/Internet
#1

I have 2 SuSE 10.3 systems serving as gateways for two very small networks. Both boxes’ “external” interfaces are bound to a shared lab network. I’m going to be using OSPF (via Quagga) on each box (and, eventually, many more routers) to distribute route information throughout the primary lab network so that systems on that lab network will be able to route into systems on the small networks hanging off the SuSE boxes. The topology looks something like this:

------------------------------- Lab Network (10.5.0.0/16)
   |eth0                 |eth0
   |10.5.100.152         |10.5.100.159
|=====|               |=====|
|     |               |     |
|     |               |     |
|=====|               |=====|
   |                     |eth2.274 (virt)
   |                     |192.168.0.49
   |eth2.273 (virt)   ---------- Subnet (192.168.0.48/28)
   |192.168.0.33
-----------Subnet (192.168.0.32/28)

My intention is for each router to advertise itself as a route into the small 192.168.0.X subnets wired up to the backend virtual interfaces. E.g., I’m trying to facilitate a system on the 10.5 network to be able to get a route to a system on the 192.168.0.48/28 network, and I’m also trying to enable a system on the 192.168.0.32/28 network to do the same thing.

My ospfd.conf files for the 10.5.100.59 node looks like this:

interface eth0
interface eth2.274
router ospf
 ospf router-id 10.5.100.159
 network 192.168.0.48/28 area 192.168.0.48
 area 192.168.0.48 range 192.168.0.48/28
 network 10.5.0.0/16 area 10.5.0.0

When I telnet to the OSPF daemon, it looks like this config is legit. However, when I bring up a similarly configured OSPF daemon on it’s peer (10.5.100.152), they aren’t advertising each other’s 192.168.0.X networks to each other. I.e., I see both systems listed as each other’s neighbor:


10.5.100.159> show ip ospf neighbor

    Neighbor ID Pri State           Dead Time Address         Interface            RXmtL RqstL DBsmL
10.5.100.152      1 Full/DR           37.692s 10.5.100.152    eth0:10.5.100.159        0     0     0

…but the ospf routing tables don’t reflect each other’s 192.168.0.X networks:

10.5.100.159> show ip ospf route
============ OSPF network routing table ============
N    10.5.0.0/16           [10] area: 10.5.0.0
                           directly attached to eth0
N    192.168.0.48/28       [10] area: 192.168.0.48
                           directly attached to eth2.274

============ OSPF router routing table =============

============ OSPF external routing table ===========

I played around with a few other config options, like “redistribute connected” and tried establishing an area for the 10.5 network (even though I don’t need them advertising this area). Nothing seems to be doing the trick. I should note that I also have zebra running, with config entries for both interfaces on each box. In case it might shed any light on things, here’s the contents of my ospfd.log file:

2008/11/18 14:38:42 OSPF: OSPFd 0.99.7 starting: vty@2604
2008/11/18 14:38:42 OSPF: interface 10.5.100.159 [2] join AllSPFRouters Multicast group.
2008/11/18 14:38:42 OSPF: interface 192.168.0.49 [7] join AllSPFRouters Multicast group.
2008/11/18 14:38:42 OSPF: ospfTrapNbrStateChange trap sent: 10.5.100.152 now Init/DROther
2008/11/18 14:38:42 OSPF: DR-Election[1st]: Backup 10.5.100.159
2008/11/18 14:38:42 OSPF: DR-Election[1st]: DR     10.5.100.152
2008/11/18 14:38:42 OSPF: DR-Election[2nd]: Backup 10.5.100.159
2008/11/18 14:38:42 OSPF: DR-Election[2nd]: DR     10.5.100.152
2008/11/18 14:38:42 OSPF: ospfTrapIfStateChange trap sent: 10.5.100.159 now Backup
2008/11/18 14:38:42 OSPF: interface 10.5.100.159 [2] join AllDRouters Multicast group.
2008/11/18 14:38:42 OSPF: DR-Election[1st]: Backup 10.5.100.159
2008/11/18 14:38:42 OSPF: DR-Election[1st]: DR     10.5.100.152
2008/11/18 14:38:42 OSPF: Packet[DD]: Neighbor 10.5.100.152: Initial DBD from Slave, ignoring.
2008/11/18 14:38:42 OSPF: Packet[DD]: Neighbor 10.5.100.152 Negotiation done (Master).
2008/11/18 14:38:42 OSPF: nsm_change_state(10.5.100.152, Loading -> Full): scheduling new router-LSA origination
2008/11/18 14:39:22 OSPF: DR-Election[1st]: Backup 192.168.0.49
2008/11/18 14:39:22 OSPF: DR-Election[1st]: DR     192.168.0.49
2008/11/18 14:39:22 OSPF: DR-Election[2nd]: Backup 0.0.0.0
2008/11/18 14:39:22 OSPF: DR-Election[2nd]: DR     192.168.0.49
2008/11/18 14:39:22 OSPF: ospfTrapIfStateChange trap sent: 192.168.0.49 now DR
2008/11/18 14:39:22 OSPF: interface 192.168.0.49 [7] join AllDRouters Multicast group.
#2

Don’t these routing daemons require certain ports to be open to communicate with each other? So don’t you have to make those ports open in the firewall rules, if you have one running?

#3

There is no firewall between the two boxes – they have direct access to each other via their interfaces on the 10.5.0.0/16 network.

ETA: note that they are aware of each other as neighbors, but simply aren’t advertising their respective 192.168.0.X networks to each other. I would think if I had connectivity issues between them (e.g. firewall), they wouldn’t even know of each other as neighbors.

#4

Sounds like an OSPF config issue and nothing SUSE specific. Have you looked in the Quagga forums for similar problems and their solution?

#5

Figured it out. I needed to describe the shared 10.5.0.0/16 network as area 0. Apparently, this area ID holds some special significance – I had described it using 10.5.0.0 for convenience’ sake. Everything works now.