Hi there,
I just tried to use veth in combination with a bridge and found some
strange behavior, incl. NAT not working, etc. See below.
First, let me describe the test setup in detail:
kernel version: 2.6.25.4
ip utility: iproute2-ss080417
bridge-utils: 1.2
client <- Ethernet -> (eth1) router (eth2) <- Ethernet -> "Internet"
where the routers "internals" looks like this:
br0
+++++++++++++++
+ eth1 veth0 + veth1 eth2
+++++++++++++++
no IP 10.8.3.18 192.168.0.189
ip link add type veth
ifconfig veth1 10.8.3.18 netmask 255.255.255.252
router-test:~# brctl show
bridge name bridge id STP enabled interfaces
br0 8000.000c29ce5b41 no eth1
veth0
On the router, I set up a basic NAT:
iptables -A POSTROUTING -o eth2 -j MASQUERADE -t nat
The client has the ip 10.8.3.17/30 and it's default route points to IP
10.8.3.18 on the router.
The first test setup was implemented with physical machines; the router
was a HP ProLiant DL360 G3 with 4 network interfaces (2x NetXtreme
BCM5703X and 2x Intel e1000). In this setup, I saw that all packets from
the client weren't masqueraded, but just routed instead.
To eliminate hardware problems I reimplemented the same setup inside of
VMware. The masquerading problem described above was _not_ reproduceable,
but other interesting problems arise:
1) Easy to reproduce: just ping the router from the client. What happens
is that some icmp packages arrive, but then the router starts to do new
arp requests for the ip of the client, which takes some time and I got
package loss.
2) Really weird problem with masquerading (again): On the outgoing
interface everything looks fine like it should be. E.g. a dns lookup
(already masqueraded) dumped on eth2:
<snip>
06:40:51.089839 IP 192.168.0.189.1064 > 10.10.110.1.53: 4573+ A?
google.at. (27)
06:40:51.090937 IP 10.10.110.1.53 > 192.168.0.189.1064: 4573 3/0/0 A
216.239.59.104,[|domain]
</snip>
but on the client it looks like this:
<snip>
06:42:43.863969 IP 10.8.3.17.1064 > 10.10.110.1.53: 4576+ A? google.at.
(27)
06:42:43.872409 IP 10.10.110.1.1 > 10.8.3.17.1064: UDP, length 75
06:42:43.872659 IP 10.8.3.17 > 10.10.110.1: ICMP 10.8.3.17 udp port 1064
unreachable, length 111
</snip>
The request is fine. But the answer port is *1*, which is obviously
wrong. So the client ends up sending an icmp unreachable message.
Further test showed that this happens for udp and tcp. The remote port
is "always" translated back to 1, even if multiple connections are
established.
I also tried the whole setup without using veth; the IP directly bound
to br0, as well as without the bridge at all. No problems with that.
So there might be some problems with veth?
Sorry for the long mail, but I hope someone can give me a hint to fix
these problems.
Thanks,
best regards
Bernhard
--
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
