[Xorp-users] Problem routing to VPN subnets

Dirk dirk.schulz at kinzesberg.de
Sun Jan 18 01:33:09 PST 2015


Just in case someone runs into the same problem:

net.ipv4.conf.default.rp_filter = 2
in /etc/sysctl.conf solves this problem.

I did not expect that since most OSPF based routing handled by XORP 
works without it. But at least it works.

Cheers,

Dirk

Am 19.04.14 um 18:24 schrieb Dirk:
> Hi all,
>
> I have a routing problem I am stuck with.
>
> I have 2 routers, let's say router1 and router2. Both are using OSPFv2.
>
> Router1 and router2 are sharing 2 physical subnets forming the backbone
> area and a third physical subnet forming another area. Then there is a
> OpenVPN on each router, using a unique subnet and area that is connected
> to this router only (let's say VPN1 und router1 and VPN2 on router2).
>
> Now comes the weird part:
> - "ip route show" in Linux shows a completely sensible routing table on
> both routers.
> - "traceroute" used on each router for any possible destination shows
> the correct hops, also for VPN destinations to both VPNs.
> But:
> Packets destined for VPN1 coming from router2 are
> - correctly forwarded to the tun0 interface and into the VPN if they
> come from the first physical subnet of the backbone area
> - wrongly forwarded back to router2 if they come from the second
> physical subnet of the backbone area (and thus circling between router1
> and router2).
> Packets destined for VPN2 coming from router1 are
> - correctly forwarded to the tun0 interface and into the VPN if they
> come from the first physical subnet of the backbone area
> - wrongly forwarded back to router2 if they come from the second
> physical subnet of the backbone area (and thus circling between router1
> and router2).
> I found out the details of this behaviour using tcpdump on both routers
> and traceroute on hosts in both physical subnets. If necessary, I can
> show dumps of both commands.
>
> The physical subnets in the backbone area definition are identical:
>       area 0.0.0.0 {
>           area-type: "normal"
>           interface bond0 {
>               vif bond0 {
>                   address 93.94.81.251 {
>                       priority: 128
>                       hello-interval: 10
>                       router-dead-interval: 40
>                       interface-cost: 1
>                       retransmit-interval: 2
>                       transit-delay: 1
>                       disable: false
>                   }
>               }
>           }
>           interface bond1 {
>               vif bond1 {
>                   address 93.94.82.59 {
>                       priority: 128
>                       hello-interval: 10
>                       router-dead-interval: 40
>                       interface-cost: 1
>                       retransmit-interval: 2
>                       transit-delay: 1
>                       disable: false
>                   }
>               }
>           }
>       }
>
> And the interface definitions are identical also:
>
>       interface bond0 {
>           description: "allcust bonding interface"
>           disable: false
>           default-system-config
>       }
>
>       interface bond1 {
>           description: "own net bonding interface"
>           disable: false
>           default-system-config
>       }
>
> I do not see any config where this kind of "source based routing"
> behaviour can come from.
>
> Another funny aspect of this is: This same setup has worked perfectly on
> CentOS 5 with xorp 1.6.x. The problem exists on CentOS 6 with xorp 1.8.5.
>
> Any hint or help is appreciated.
>
> Dirk
>
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users



More information about the Xorp-users mailing list