lkml.org 
[lkml]   [2022]   [Nov]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH net] ipv4: fix source address and gateway mismatch under multiple default gateways

Hello,

On Sat, 29 Oct 2022, Ziyang Xuan (William) wrote:

> > On Wed, 26 Oct 2022, Ziyang Xuan wrote:
> >
> >> We found a problem that source address doesn't match with selected gateway
> >> under multiple default gateways. The reproducer is as following:
> >>
> >> Setup in client as following:
> >>
> >> $ ip link add link eth2 dev eth2.71 type vlan id 71
> >> $ ip link add link eth2 dev eth2.72 type vlan id 72
> >> $ ip addr add 192.168.71.41/24 dev eth2.71
> >> $ ip addr add 192.168.72.41/24 dev eth2.72
> >> $ ip link set eth2.71 up
> >> $ ip link set eth2.72 up
> >> $ route add -net default gw 192.168.71.1 dev eth2.71
> >> $ route add -net default gw 192.168.72.1 dev eth2.72
> >
> > Second route goes to first position due to the
> > prepend operation for the route add command. That is
> > why 192.168.72.41 is selected.
> >
> >> Add a nameserver configuration in the following file:
> >> $ cat /etc/resolv.conf
> >> nameserver 8.8.8.8
> >>
> >> Setup in peer server as following:
> >>
> >> $ ip link add link eth2 dev eth2.71 type vlan id 71
> >> $ ip link add link eth2 dev eth2.72 type vlan id 72
> >> $ ip addr add 192.168.71.1/24 dev eth2.71
> >> $ ip addr add 192.168.72.1/24 dev eth2.72
> >> $ ip link set eth2.71 up
> >> $ ip link set eth2.72 up
> >>
> >> Use the following command trigger DNS packet in client:
> >> $ ping www.baidu.com
> >>
> >> Capture packets with tcpdump in client when ping:
> >> $ tcpdump -i eth2 -vne
> >> ...
> >> 20:30:22.996044 52:54:00:20:23:a9 > 52:54:00:d2:4f:e3, ethertype 802.1Q (0x8100), length 77: vlan 71, p 0, ethertype IPv4, (tos 0x0, ttl 64, id 25407, offset 0, flags [DF], proto UDP (17), length 59)
> >> 192.168.72.41.42666 > 8.8.8.8.domain: 58562+ A? www.baidu.com. (31)
> >> ...
> >>
> >> We get the problem that IPv4 saddr "192.168.72.41" do not match with
> >> selected VLAN device "eth2.71".
> >
> > The problem could be that source address is selected
> > once and later used as source address in following routing lookups.
> >
> > And your routing rules do not express the restriction that
> > both addresses can not be used for specific route. If you have
> > such restriction which is common, you should use source-specific routes:
>
> Hi Julian,
>
> Thank you for your quick reply.
>
> Can we make some work to make the restriction "both addresses can not be used for specific route" in code but in consciousness?

No good idea about this. Not sure if the new 'nexthop'
object is suitable for such policy.

Regards

--
Julian Anastasov <ja@ssi.bg>

\
 
 \ /
  Last update: 2022-11-13 21:03    [W:1.738 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site