Hi, On Wed, Apr 29, 2020 at 12:45:26PM +0200, Gert Doering wrote: > On Wed, Apr 29, 2020 at 12:25:02PM +0200, Jan Just Keijser wrote: > > in other words, OSPF is not UDP or TCP based and hence will not easily > > work over routed tunnels - which makes sense, as OSPF is a rout*ING > > *protocol, not a rout*ED* protocol. > > Naaah.
To word this a bit more explitly :-)
OpenVPN in p2p mode will transport everything that is running on top
of IPv4 or IPv6. So, no "UDP or TCP based" (otherwise "ping" wouldn't
work). It will transport OSPF / OSPFv3 packets just fine.
It might or might not transport non-IP stuff, like IPX or ISO (which
would be needed for IS-IS routing). Theoretically it should, but I
would assume some checks for v4/v6 and subsequent packet explosion.
Now, p2mp mode. In p2mp mode, the server needs to understand what to
do with the packet (server-internal routing table, "iroute" stuff).
OSPF does multicast, which is somewhat half-implemented into OpenVPN -
namely, multicast packets get treated as broadcasted. Which is what
is needed here: make sure OSPF packets get to all tun clients
(drawback: also to those that are not running OSPF, so don't mix).
This should also work "just fine", because the server's routing is
also not based on "UDP or TCP based", just on IPv4/IPv6 target address
inside the tunnel.
Next, OSPF exchanges IPv4/IPv6 routing info, and this is programmed into
the kernel routing table left and right. *This* is where OSPF breaks
in p2mp mode, because this kernel routing info is not propagating into
the OpenVPN server iroute table.
In *TAP* mode, just for completeness, OpenVPN does not care at all
for protocol numbers or IPv4/IPv6 routing. All it does is "I am an
ethernet switch, and I will send out packets based on MAC address",
so routing (which will install a next-hop to something identifiable
by ARP and then given to OpenVPN with a known destination MAC address)
will work nicely. IS-IS, IPX, ISO networking might also "just work",
because it's "just ethernet frames".
The reason why (Jonathan pointed this out) the OpenVPN devs usually
recommend away from TAP mode is that TAP brings more overhead (extra
ethernet header inside each VPN packet, extra ARP packets, ...) and
has no benefits for a "normal" L3 routed setup. Worded differently, if
what you want can be done inside OpenVPN routing, tun mode is what
you want, because it is more efficient.
If you need stuff like "bridge together two networks so that Netbios
broadcasting works", TAP mode is it for you, or use a WINS or AD server
instead :-)
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
signature.asc
Description: PGP signature
_______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
