I have successfully configured OSPF on all of our HP ProCurve 7102 routers, and most of our internal Linux routers. Routes get advertised, and all is peachy.
Except for the routes into the subnets handled by various OpenVPN services and other VPN connections around the company. Please consider the picture below, which shows a part of the company network:
The red arrows are VPN connections. The blue area at the bottom depicts OSPF area 0 (the backbone), which comprises routers in all other offices. The pink area depicts OSPF area 177 for one of our offices. The orange rectangle is the OpenVPN network in question, hosted on the Linux router indicated by the blue icon with the arrows.
The 10.177.0.0/16 subnet is properly advertised to all other OSPF areas. However, despite the fact that network 10.180.1.0/24 is included in the OSPF configuration, and interface tun0 is included in area 177(as a passive interface), this subnet does not get advertised.
Is that because this is actually an external route? If so, how would I tell the OSPF daemon to advertise that route?
The first thought that comes to mind is that you need to redistribute the kernel routes in addition to the connected routes in Quagga/Zebra OSPF. Because OpenVPN adds the routes itself, Zebra will not redistribute them if you only have 'redistribute static' in your configuration.
I am using OpenVPN in OSPF environments too, and everything redistributes just fine.
Note: you may need to add some redistribution list filters to prevent redistribution of other kernel routes that shouldn't be advertisted.
Another option is to add a static route in Zebra for the 10.180.1.0/24 going to null or the loopback device.
I found myself with a similar problem after a "get rid of kernel and static routes" orgy.
The solution for my case is to put the OpenVPN network in a different OSPF area and then use the neat trick of substituting the /32 prefix associated with the server's endpoint address to a /24 subnet prefix. e.g.
192.168.22.0/24 is the OpenvVPN subnet on my FreeBSD 10.3-PRERELEASE OpenVPN server.
In openvpn.conf:
When OpenVPN is started tun0 interface comes up with the following configuration:
In ospfd.conf:
OSPF then advertises 192.168.22.0/24 instead of 192.168.22.1/32
N.B. This only works across an area boundary.