LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: [lvs-users] DR-TUN Issues: Packets become martians on real server

To: Julian Anastasov <ja@xxxxxx>
Subject: Re: [lvs-users] DR-TUN Issues: Packets become martians on real server
Cc: "lvs-users@xxxxxxxxxxxxxxxxxxxxxx" <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
From: "Timothy R. Weiand" <timothy.weiand@xxxxxxxxx>
Date: Thu, 10 Aug 2017 17:08:31 +0000
Julian:

Good news and bad news: this guidance helped me get LVS-TUN working with a
3.10.0 kernel. But, I am not able to use the same configuration to get
4.4.x,4.8.x or 4.12.x working. We are working on doing further analysis to
ensure it is kernel dependent and not distribution dependent. I hope to
find the kernel version that this configuration stops working.

Note on 4.x machines: If we do not have the correct ip assigned to the
tunnel interface we can see traffic on that interface. But, if we use the
correct VIP then we no longer see the traffic.

I will keep you updated as I find information out.

Thanks!
-Timothy

On Tue, Jul 25, 2017 at 4:25 PM Julian Anastasov <ja@xxxxxx> wrote:

>
>         Hello,
>
> On Fri, 14 Jul 2017, Timothy R. Weiand wrote:
>
> > I am building a DR-TUN configuration to load balance DNS traffic. My
> issue
> > is with the real servers: the ipip packet get unwrapped and appears on
> the
> > tunnel interface and becomes a martian. Also, I have not been able to
> > determine how to bind to the tunnel interface to capture these packets. I
> > have verified details with tcpdump/dmesg. All my configuration is
> scripted
> > to ensure reproducibility. tcpdumps below do not show real DNS traffic;
> > using netcat to send text.
> >
> > Much more detail can be supplied, please request it.
> >
> > Configuration:
> >
> > ==============
> >
> > - All machines are currently Debian 9 (4.9.30-2+deb9u2)
> >
> > - Client: 192.168.200.10
> >
> > - Director: 192.168.200.11
> >
> > - Real Server: 192.168.200.12
> >
> > - No VIP: I am using the IP address for my director interface -
> > 192.168.200.11
> >
> >
> > Director Configuration:
> >
> > ==================
> >
> > vagrant@debian-9-lb:~$ sudo ipvsadm -Ln
> >
> > IP Virtual Server version 1.2.1 (size=4096)
> >
> > Prot LocalAddress:Port Scheduler Flags
> >
> >   -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
> >
> > UDP  192.168.200.11:53 rr
> >
> >   -> 192.168.200.12:53            Tunnel  1      0          0
> >
> >
> >
> > Real Server:
> >
> > ============
> >
> > # modprobe ipip
> >
> > # echo 1 > /proc/sys/net/ipv4/ip_forward
> >
> > # ip tunnel add tunl1 mode ipip ttl 32 local 192.168.200.12 remote
> > 192.168.200.11
> >
> > # ip link set tunl1 up arp off
> >
> > # echo 2 > /proc/sys/net/ipv4/conf/all/rp_filter
> >
> > # echo 2 > /proc/sys/net/ipv4/conf/default/rp_filter
> >
> > # echo 2 > /proc/sys/net/ipv4/conf/tunl0/rp_filter
> >
> > # echo 2 > /proc/sys/net/ipv4/conf/tunl1/rp_filter
>
>         tunl1/rp_filter=2 is ignored if there are no
> IPv4 addresses configured on tunl1, you can see
> __fib_validate_source() for reference:
>
>         if (no_addr)
>                 goto last_resort;
>
>         As result, packets are dropped as martians due to rpf=2.
>
>         To check if packets are dropped by routing try:
>
> ip route get from 192.168.200.10 to 192.168.200.11 iif tunl1
>
>         Here is small howto for TUN (outdated):
>
> http://ja.ssi.bg/TUN-HOWTO.txt
>
> > vagrant@debian-9-dns:~$ sudo tcpdump -e -n -s 0 -i tunl1 -vv
> >
> > tcpdump: listening on tunl1, link-type RAW (Raw IP), capture size 262144
> > bytes
> >
> > 10:16:13.919646 ip: (tos 0x0, ttl 64, id 63545, offset 0, flags [DF],
> proto
> > UDP (17), length 40)
> >
> >     192.168.200.10.51149 > 192.168.200.11.53: [udp sum ok] 26226
> updateMA+
> > [b2&3=0x6f6d] [27753a] [11619q] [25966n] [29706au][|domain]
> >
> >
> >
> > If I add an IP address to the interface the packet never reaches tunl1
> >
> > # ip addr add 192.168.200.11/24 brd 192.168.200.11 dev tunl1
>
>         Try with (note mask /32):
>
> ip addr add 192.168.200.11/32 dev tunl1
>
>         as shown in LVS HOWTO (8.3):
>
> http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.LVS-Tun.html
>
> > Notes:
> >
> > ======
> >
> >
> >
> > LVS-DR was not an option because the real servers will be in different
> > subnets (I was able to get LVS-DR working though).
> >
> >
> >
> > I am looking for advice on how to better understand or resolve this
> issue.
> > Or, who would be better to answer this question.
> >
> >
> >
> > I have groked as many articles on how to setup this configuration as I
> can.
> > And, I have read a good deal of the archives of this mailing list.
> >
> >
> >
> > Linux distributions I have tried are Debian, Ubuntu and Amazon linux.
> This
> > is been tested on both AWS and VMware fusion.
> >
> >
> >
> > ------
> >
> >
> >
> > I have a feeling I am missing something simple...
> >
> >
> >
> > Thanks!
> >
> > -Timothy
>
> Regards
>
> --
> Julian Anastasov <ja@xxxxxx>
>
_______________________________________________
Please read the documentation before posting - it's available at:
http://www.linuxvirtualserver.org/

LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
or go to http://lists.graemef.net/mailman/listinfo/lvs-users

<Prev in Thread] Current Thread [Next in Thread>