Simon Hobson wrote:
We can see ARP requests going out via peth1, but they don't arrive at
the other device - so they are either not being transmitted, or the
switch is blocking them.
I'd still suggest changing nothing except to connect the machine direct*
to something (eg a laptop) and try again - just to completely eliminate
any potential switch problem. Having said that, it's not a problem I've
personally come across.
* Or use a known "dumb" switch so you can have the rest of the network
connected (so you get DHCP) and then unplug it from the rest of the
network for testing.
OK. I still think that it has nothing to do with the switches of
192.168.24.0, because when I set the description of dom1 to have its
FIRST interface on that network, that FIRST interface works great (and
eth1 on dom0 as well), while the SECOND interface, now on the routed
network that used to work great, goes ill.
So OK, I will run the test with the laptop, so that anybody here (inc.
me) are convinced that it does not come from the switches. But
unfortunately, I will get no physical access to the machine before the
beginning of next year.
Well I've no idea what's wrong here. The line that's failing reads :
Append a rule to the FORWARD table, match (-m) using the physdev module,
macthing in put port (--physdev-in) vif1.1, and jump (-j) to the ACCEPT
rule.
In other words - for any packets entering via bridge port vif1.1,
forward them.
Now, I've just checked on one of my work servers, and it does indeed
have rules like these.
# iptables -L -vn
...
Chain FORWARD (policy ACCEPT 180M packets, 36G bytes)
pkts bytes target prot opt in out source
destination
46M 50G ACCEPT all -- * * xx.xx.xx.xx
0.0.0.0/0 PHYSDEV match --physdev-in xxxxx
0 0 ACCEPT udp -- * * 0.0.0.0/0
0.0.0.0/0 PHYSDEV match --physdev-in xxxxx udp spt:68 dpt:67
While I see from an earlier message that your iptables is empty.
However, It shouldn't matter since the default policy on your FORWARD
chain is accept - ie anything not expressly blocked should be passed.
Is it possible that you don't have physdev matching available in your
Dom0 installation ?
I don't think this is anything to do with your problem, but could
account for the error message.
Hmmm. I hacked the vif-common.sh file to get more information on this
(and retrieve the error message from iptables). I could get two kinds
of errors:
"iptables: Resource temporarily unavailable"
or
"iptables: Bad rule (does a matching rule exist in that chain?)"
But it occurs only at the first creation of a dom1 with two vifs, one
on every NIC, after dom0 has just booted, and only for the second vif
in the declaration. In ANY other case (single vif on whatever NIC,
subsequent domU creation, etc.), no error.
As an aside, I can now see one thing that setting the guest IP address
does - it includes the IP address in the iptables rules added for the
guest when it starts.
Whether I specify ip=192.168.24.81 in the description of dom1 or not
does not change anything to the problem. Only the iptables on dom0 are
more specific with the IP.
Regards,
Philippe
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home