Disponemos de varias máquinas que están conectadas a una red tanto de alta como de baja velocidad; otras máquinas están sólo en la red de baja velocidad. Estoy investigando implementar OSPF para que cada conexión pueda elegir automáticamente la ruta más rápida. Sin embargo, no quiero que las máquinas se conviertan accidentalmente en enrutadores, así que estoy usando la opción max-metric router-lsa administrativeen /etc/quagga/ospfd.conf.
Desafortunadamente, además de establecer los costos del enlace saliente en ∞ para fines publicitarios, también parece utilizar ∞ (bueno, 65535) como costo del enlace al calcular los costos de ruta en el host. El resultado es que en lugar de preferir rutas que utilizan el enlace de alta velocidad, las trata como rutas de igual costo. Si elimino la max-metricconfiguración, calcula correctamente que se prefiere el enlace de alta velocidad.
Nota: por el momento solo estoy experimentando con el uso de máquinas virtuales y redes virtuales, por lo que los enlaces son realmente equivalentes y estoy especificando los costos manualmente. Tres máquinas están conectadas a una red, con direcciones 192.168.50.2-4, dos están conectadas a otra red con direcciones 192.168.51.2-3 y cada máquina también tiene una dirección de bucle invertido 192.168.100.x, que es como se dirigirán a cada una. otro. Aquí está mi archivo /etc/quagga/ospfd.conf en una de las máquinas:
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
y aquí está la tabla de enrutamiento:
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 =============
Como puede ver, el acceso a 192.168.100.2 ha costado 65535 y se enrutará a través de cualquiera de las interfaces.
¿Hay alguna forma de lograr que el host utilice los costos del enlace para su propio cálculo de la ruta más corta y, al mismo tiempo, evitar que el host se utilice como enrutador de tránsito?
Respuesta1
No logré que Quagga hiciera lo que quería (también lo intenté con FRR, el mismo problema), pero descubrí que Bird con OSPF v3 funcionó bien. OSPF v3 tiene una función incorporada para enrutadores auxiliares en lugar de depender de establecer los costos de enlace al infinito. Quagga/FRR no es compatible con RFC 5838, por lo que no pude probar OSPF v3 con ellos.