Hi:
We are experiencing problems when running OSPF as daemon, in fact, OSPF
routes are not propagated to Kernel routing table. Let me explain the
environment:
-. We have 2 Zebra routers connectd with 2 ethernet interfaces per node (2
links) and behind them there are 2 IP subnets to propagate
+----------+ +------+ link1 +------+ +----------+
| | | |-------| | | |
| subnet 1 |-----| node1| | node2|------| subnet 2 |
| | | |-------| | | |
+----------+ +------+ link2 +------+ +----------+
-. We have configure OSPF using both links as balanced ("equalized" as
specified in OSPF terminology), I mean, we need 2 routes to next hop using
both links
-. If we run OSPFD daemon from rc.local file (without login in system,
invoking first "zebra -dl" and after "ospfd -d"), when checking routes using
"show ip ospf route" 2 routes with same cost using each link to next hop
appear in every node, but if we check them using "ip route list" (kernel ip
routes) only appears one of them. So traffic balancing does not run. See
example below:
OSPF
[root@PEPE root]# ip route list
192.168.101.24/29 dev eth0 proto kernel scope link src 192.168.101.30
192.168.101.32/29 dev eth1 proto kernel scope link src 192.168.101.38
10.0.0.0/24 dev eth2 proto kernel scope link src 10.0.0.1
10.0.1.0/24 dev eth0 proto kernel scope link src 192.168.101.25
127.0.0.0/8 dev lo scope link
[root@PEPE root]#
-. If we manually run OSPFD from console (login previously as root in
system) and we execute the commands above commented, both ip route tables
(ospf and kernel are correct and show 2 routes as configured and needed. See
example below:
OSPF
[root@PEPE root]# ip route list
192.168.101.24/29 dev eth0 proto kernel scope link src 192.168.101.30
192.168.101.32/29 dev eth1 proto kernel scope link src 192.168.101.38
10.0.0.0/24 dev eth2 proto kernel scope link src 10.0.0.1
10.0.1.0/24 proto zebra metric 30 equalize
nexthop via 192.168.101.25 dev eth0 weight 1
nexthop via 192.168.101.33 dev eth1 weight 1
127.0.0.0/8 dev lo scope link
[root@PEPE root]#
We have reviewed permissions, Zebra compilation (with "enable-multipath=0"),
kernel, etc. and we suspect there is a bug in daemon or any hidden feature
that can solve the problem. Of course, manual executing is not a solution
due to the equipment will be installed as unattended.
We have LINUX Red Hat 7.3 and I `m using quagga-0.96.4.
Best regards,
Santiago
We are experiencing problems when running OSPF as daemon, in fact, OSPF
routes are not propagated to Kernel routing table. Let me explain the
environment:
-. We have 2 Zebra routers connectd with 2 ethernet interfaces per node (2
links) and behind them there are 2 IP subnets to propagate
+----------+ +------+ link1 +------+ +----------+
| | | |-------| | | |
| subnet 1 |-----| node1| | node2|------| subnet 2 |
| | | |-------| | | |
+----------+ +------+ link2 +------+ +----------+
-. We have configure OSPF using both links as balanced ("equalized" as
specified in OSPF terminology), I mean, we need 2 routes to next hop using
both links
-. If we run OSPFD daemon from rc.local file (without login in system,
invoking first "zebra -dl" and after "ospfd -d"), when checking routes using
"show ip ospf route" 2 routes with same cost using each link to next hop
appear in every node, but if we check them using "ip route list" (kernel ip
routes) only appears one of them. So traffic balancing does not run. See
example below:
OSPF
[root@PEPE root]# ip route list
192.168.101.24/29 dev eth0 proto kernel scope link src 192.168.101.30
192.168.101.32/29 dev eth1 proto kernel scope link src 192.168.101.38
10.0.0.0/24 dev eth2 proto kernel scope link src 10.0.0.1
10.0.1.0/24 dev eth0 proto kernel scope link src 192.168.101.25
127.0.0.0/8 dev lo scope link
[root@PEPE root]#
-. If we manually run OSPFD from console (login previously as root in
system) and we execute the commands above commented, both ip route tables
(ospf and kernel are correct and show 2 routes as configured and needed. See
example below:
OSPF
[root@PEPE root]# ip route list
192.168.101.24/29 dev eth0 proto kernel scope link src 192.168.101.30
192.168.101.32/29 dev eth1 proto kernel scope link src 192.168.101.38
10.0.0.0/24 dev eth2 proto kernel scope link src 10.0.0.1
10.0.1.0/24 proto zebra metric 30 equalize
nexthop via 192.168.101.25 dev eth0 weight 1
nexthop via 192.168.101.33 dev eth1 weight 1
127.0.0.0/8 dev lo scope link
[root@PEPE root]#
We have reviewed permissions, Zebra compilation (with "enable-multipath=0"),
kernel, etc. and we suspect there is a bug in daemon or any hidden feature
that can solve the problem. Of course, manual executing is not a solution
due to the equipment will be installed as unattended.
We have LINUX Red Hat 7.3 and I `m using quagga-0.96.4.
Best regards,
Santiago