[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#760525: marked as done (linux-image-3.14-2-amd64: routing fails)

Your message dated Wed, 28 Apr 2021 18:41:06 +0200
with message-id <E1lbnF2-001LT4-Hn@hullmann.westfalen.local>
and subject line Closing this bug
has caused the Debian Bug report #760525,
regarding linux-image-3.14-2-amd64: routing fails
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
760525: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760525
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: linux-image-3.14-2-amd64
Version: 3.14.15-2
Severity: important
Routing fails when there are macvtaps attached and SNAT/DNAT is used for routing with a tap device. (The routing being talked about concerns between eth0's public IP address and tap0 which is not a macvtap device on eth0.) 

The first test of routing is simple
'Forwarding' is set on eth0, and on a tap device(which was created with ip tuntap) 

echo 1 >
/proc/sys/net/ipv4/conf/eth0/forwarding
(or sysctl -w net.ipv4.conf.eth0.forwarding=1)

echo 1 >
/proc/sys/net/ipv4/conf/tap0/forwarding
On the far end of tap0 (a VM), a station's IP address is being SNAT/DNATted on this hypervisor's eth0
Here's the thing, I know it's a kernel issue because it never fails when I do 

echo 1 > /proc/sys/net/ipv4/conf/all/forwarding
echo 0 > /proc/sys/net/ipv4/conf/all/forwarding
echo 1 > /proc/sys/net/ipv4/conf/eth0/forwarding
echo 1 > /proc/sys/net/ipv4/conf/tap0/forwarding

right away after on clean boot (and having started the VM)

Don't be distracted by the VM and other things in the way.

Here is the condition why this fails,
-> Macvtap devices on eth0(there's about 3 or 4). When there are no macvtap devices on eth0, routing doesn't need to be fixed using these four commands..
Routing from the tap0 device which later gets natted with eth0 always works but only after I issue these four commands. 

I believe this is more an upstream issue so I'll be cloning this bugreport.

thanks

-Scott

--- End Message ---
--- Begin Message --- 
This bug was filed for a very old kernel. If you can reproduce it with
- the current version in unstable/testing
- the latest kernel from buster.backports
please reopen the bug, see https://www.debian.org/Bugs/server-control

--- End Message ---
Reply to: