Hi, I have done tests with masquerade, using new model.

First, I would like to say that I have reproduce my corosync cluster hang 
(kernel 3.10 and kernel 2.6.32), with this setup

pm0.94--->pm0-->vmbr0<---eth0

host ip is on pm0.94.

All is working fine, until

#modprobe nf_conntrack_ipv4

Then, something bad happen, I some corosync packets don't go from pm0.94->pm0.
I suspect from fragmentation problem and vlan tags

#lsmod|grep nf
nf_conntrack_ipv4      14862  2 
nf_defrag_ipv4         12729  1 nf_conntrack_ipv4

I have tried to disable offloading (tso,gro,gso) on pm0 and pm0.94, but it 
doesn't help

I have done some tests with corosync inside guest vms. (I'm using it with 
pacemaker, for some web server ha-cluster services).
and I can also reproduce the problem

So, I think that vlan tagging on veth is broken somewhere for now.

I think it's better to keep the current vmbrXvY model for 3.10 kernel too

eth0------->vmbr0
eth0.94---->vmbr0v94<-----tapXiY (non firewalled tap)
                    <--linkXiY----->linkXiYp--->fwbrXiY---->tapXiY (firewalled 
tap)




Now, about masquerade, we don't need pm0 interface anymore

a simple:
iptables -t raw -A PREROUTING -i fwbr110i0 -j CT --zone 1 (kernel 3.10 only of 
course)

is enough, to enable nat on a firewalled tap

(user just need to define like before "iptables -t nat -A POSTROUTING -s 
X.X.X.X/24 -o vmbr0 -j MASQUERADE", like before)


I think it seem to be the best setup, don't break current model for non 
firewall vms,
and just add a new fwbr bridge for firewalled taps

What do you think about it ?







_______________________________________________
pve-devel mailing list
[email protected]
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

Reply via email to