0

We have a number of machines which are connected to both a high-speed and a low-speed network; other machines are only on the low-speed network. I'm investigating deploying OSPF so that each connection can automatically choose the fastest route. However, I don't want the machines to accidentally become routers themselves, so I'm using the option max-metric router-lsa administrative in /etc/quagga/ospfd.conf.

Unfortunately, in addition to setting the outgoing link costs to ∞ for the purposes of advertising, it also seems to use ∞ (well, 65535) as the link cost when computing route costs on the host. The result is that instead of preferring paths that use the high-speed link, it treats them as equal-cost paths. If I remoe the max-metric setting then it correctly computes that the high-speed link is preferred.

Note: at the moment I'm just experimenting using VMs and virtual networking, so the links are actually equivalent, and I'm manually specifying costs. Three machines are connected to one network, with addresses 192.168.50.2-4, two are connected to another network with addresses 192.168.51.2-3, and each machine also has a loopback address 192.168.100.x which is how they will address each other. Here's my /etc/quagga/ospfd.conf file on one of the machines:

hostname ospf
password zebra
enable password zebra

interface eth1
  ip ospf area 0
  ip ospf cost 1000
  ip ospf hello-interval 1
  ip ospf dead-interval 5

interface eth2
  ip ospf area 0
  ip ospf cost 100
  ip ospf hello-interval 1
  ip ospf dead-interval 5

interface lo
  ip ospf area 0 192.168.100.1
  ip ospf cost 100

router ospf
  log-adjacency-changes
  passive-interface lo
  max-metric router-lsa administrative
  auto-cost reference-bandwidth 1000

log stdout

and here's the routing table:

node1# show ip ospf route
============ OSPF network routing table ============
N    192.168.50.0/24       [65535] area: 0.0.0.0
                           directly attached to eth1
N    192.168.51.0/24       [65535] area: 0.0.0.0
                           directly attached to eth2
N    192.168.100.1/32      [0] area: 0.0.0.0
                           directly attached to lo
N    192.168.100.2/32      [65535] area: 0.0.0.0
                           via 192.168.50.3, eth1
                           via 192.168.51.3, eth2
N    192.168.100.3/32      [65535] area: 0.0.0.0
                           via 192.168.50.4, eth1

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

As you can see, for access to 192.168.100.2, it has cost 65535, and will route through either interface.

Is there some way to get the host to use the link costs for its own shortest-path calculation, while still preventing the host from being used as a transit router?

1 Answers1

0

I didn't manage to get Quagga to do what I wanted (also tried with FRR, same problem), but I found that Bird with OSPF v3 worked nicely. OSPF v3 has a built-in feature for stub routers rather than relying on setting link costs to infinity. Quagga/FRR don't support RFC 5838 so I wasn't able to try OSPF v3 with them.