... | ... | @@ -83,10 +83,8 @@ configuration of IP ranges. |
|
|
There are several ways how to fix it:
|
|
|
|
|
|
* Use tap mode instead of tun mode, it behaves like one L2 network
|
|
|
|
|
|
* Use IPIP or GRE tunnels inside OpenVPN between clients and server and route
|
|
|
network traffic through these tunnels
|
|
|
|
|
|
* Use different VPN tool than OpenVPN
|
|
|
|
|
|
Perhaps there are some options unknown to us to make OpenVPN work transparently
|
... | ... | @@ -132,18 +130,15 @@ disrupt working configs, the problem manifests by routes that are imported as |
|
|
unreachable routes. There are several ways to solve that:
|
|
|
|
|
|
* The old behavior can be activated by _gateway direct_ option.
|
|
|
|
|
|
* If flat topology is used (one L2 network with attached border BGP routers,
|
|
|
IBGP sessions are to direct neighbors - not multihop), it is possible to just
|
|
|
add device routes using direct protocol, in that case it is also usually
|
|
|
needed to add _next hop self_ option to IBGP protocols on BGP border routers
|
|
|
(not to the route server), because without that NEXT_HOP contains IP address
|
|
|
of the border router of neighbor AS, which is usually one hop away.
|
|
|
|
|
|
* If OSPF is used for the internal network, it should work just fine, but note
|
|
|
that there should be in IGP table not only internal networks, but also the
|
|
|
border networks connecting local and neighbor's border routers.
|
|
|
|
|
|
* Trivial but manual workaround is just to add a /32 static route for each
|
|
|
address in NEXT_HOP attributes of IBGP routes.
|
|
|
|
... | ... | |