[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