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

Re: [Xen-users] Question regarding xen networking (bonding, xen-bridging)



Am 18.02.2013 13:33, schrieb Simon Hobson:
Jonas Meurer wrote:

 On the dom0 LAN connection works as expected. Gateway responds,
connection to the internet works. Dom0 and domU see each other.

But from domU, everything beyond the dom0 is unreachable, e.g. the
gateway doesn't respond. MAC address from the domU is propagated to
switches and gateway, I can see it in the arp table. In other words, the packets from domU find their way out, but the responding packets don't find their way back. A quick look at the iptables rules on dom0 give me the impression, that dom0 doesn't know how to handle packets for domU:

# iptables -L FORWARD
Chain FORWARD (policy ACCEPT)
target   prot opt source     destination
ACCEPT   all  --  anywhere   anywhere   PHYSDEV match --physdev-out
vif1.0 --physdev-is-bridged
ACCEPT   udp  --  anywhere   anywhere   PHYSDEV match --physdev-in
vif1.0 --physdev-is-bridged udp spt:bootpc dpt:bootps
ACCEPT   all  --  anywhere   anywhere   PHYSDEV match --physdev-out
vif1.0 --physdev-is-bridged
ACCEPT   all  --  <DOMU-IP>  anywhere   PHYSDEV match --physdev-in
vif1.0 --physdev-is-bridged


The last rule seems to accept packets with domU-IP as source, but I
cannot find a rule which handles incoming packets for domU. In other
words, the dom0 doesn't know what to do with packets for the domU. Is my
assumption correct? If yes, why is this the case? Is it related to
interface bonding?

I think you've answered your own question there. For testing
purposes, clear iptables and see if everything starts working.

There is something in the standard scripts that is supposed to
manipulate iptables rules when guest domains are started/stopped
(there is the option of specifying "ip-a.b.c.d" in the VIF
declaration), but I've never looked into it.

Hello Simon,

Thanks for the quick response. For some unknown reason, suddenly the setup started to work. Maybe I didn't wait long enough for the switches to accept the new domU as devices. Whatever, below is the dom0 interface setup that works for me (as reference for the future):

/etc/network/interfaces:

--8-<----8-<----8-<----8-<----8-<----8-<----8-<--
auto bond0
iface bond0 inet manual
        slaves eth0 eth1
        bond_mode balance-xor
        bond_miimon 100
        bond_downdelay 200
        bond_updelay 200

auto xenbr0
iface xenbr0 inet static
        bridge_ports bond0
        bridge_maxwait 0
        bridge_stp off
        bridge_fd 0
        address <IP-ADDRESS>
        netmask <IP-NETMASK>
        network <IP-NETWORK>
        broadcast <IP-BROADCAST>
        gateway <IP-GATEWAY>
-->-8---->-8---->-8---->-8---->-8---->-8---->-8--

I didn't modify the iptables rules created by xen helper scripts:

# iptables-save

--8-<----8-<----8-<----8-<----8-<----8-<----8-<--
-A FORWARD -m physdev --physdev-out vif2.0 --physdev-is-bridged -j ACCEPT -A FORWARD -p udp -m physdev --physdev-in vif2.0 --physdev-is-bridged -m udp --sport 68 --dport 67 -j ACCEPT -A FORWARD -m physdev --physdev-out vif2.0 --physdev-is-bridged -j ACCEPT -A FORWARD -s <DOMU-IP>/32 -m physdev --physdev-in vif2.0 --physdev-is-bridged -j ACCEPT
-->-8---->-8---->-8---->-8---->-8---->-8---->-8--

Kind regards,
 jonas


_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.