I meant to do ip neigh within dom1 - you wrote your output was from dom0.
Is the dom0 able to reach machines on the networks?
Regards,
Felix
Am 20.12.2010 04:12, schrieb Philippe Combes:
>
>
> Felix Kuperjans wrote :
>> Answers within quotes:
>>>
>>>> - It's interesting that dom1's firewall output shows that no packages
>>>> were processed, so maybe you didn't ping anything since the last
>>>> reboot
>>>> from dom1 or the firewall was loaded by reading it's statistics...
>>> You requested for the outputs "when <my> system has just started".
>>> Hence no packet, I guess. But shouldn't there be at least those
>>> exchanged
>>> for the ssh connection to the dom1 ?
>>> Anyway, after one minute or so, I get on the dom1:
>>> # iptables -nvL
>>> Chain INPUT (policy ACCEPT 23 packets, 884 bytes)
>>> pkts bytes target prot opt in out source
>>> destination
>>>
>>> Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
>>> pkts bytes target prot opt in out source
>>> destination
>>>
>>> Chain OUTPUT (policy ACCEPT 4 packets, 816 bytes)
>>> pkts bytes target prot opt in out source
>>> destination
>> That looks better.
>>>
>>>> Still no reasons why you can't ping local machines from the dom1 (and
>>>> sometimes even not from dom0). Have you tried pinging each other, so
>>>> dom0 -> dom1 and vice versa?
>>> Yes I tried, and it has always worked while dom0's eth1 was up.
>> So it's only impossible to ping the domU from other machines on the
>> network (and vice versa)?
>> I think Fajar is probably right with his guess that your physical
>> switches are managed. That means they do traffic filtering on their
>> ports based on the mac addresses.
>> Which switch models do you use on your two networks?
>
> I already answered Fajar in this thread: when the FIRST vif of dom1 is
> connected to dom0's eth1, then the behaviour on that switched LAN is
> normal, while the traffic on the routed LAN of dom0's eth0 issues the
> bug.
> So my issue is definetely related to the instanciation of the SECOND
> interface of dom1, whatever network it is connected to. Or there is
> some kind of black magic underneath...
>
>
>>>> The only remaining thing that denies communication would be ARP, so
>>>> the
>>>> output of:
>>>> # ip neigh show
>>>> on both machines *directly after* a ping would be nice (within a few
>>>> seconds - use && and a time-terminated ping).
>>> Nothing on a machine when not connected. But when connected (here the
>>> dom0):
>>> $ ip neigh show
>>> 192.168.24.125 dev eth1 lladdr 00:16:36:e0:81:2c REACHABLE
>>> 172.16.113.100 dev eth0 lladdr 00:16:38:4c:04:00 DELAY
>>> 172.16.113.123 dev eth0 lladdr 00:16:36:e0:81:2e STALE
>>> 172.16.113.124 dev eth0 lladdr 00:1b:24:3d:ca:95 REACHABLE
>>> 172.16.113.106 dev eth0 lladdr 00:16:38:28:b5:39 REACHABLE
>> ARP seems to work at least on the Domain-0 *if* one of those IP
>> addresses is the one of the domU...
>> Can you try doing this on the DomU when pinging a host in the network?
>
> I did ! As requested ! And as you know, dom0 and dom1 are
> alternatively connected. When dom0 is connected (172.16.113.121 on
> eth0 and 192.168.24.123 on eth1) I get the trace above, but nothing
> from dom1. When dom1 is connected, I get a similar trace from dom1,
> but nothing from dom0 (I mean nothing on network 192.168.24.0)
>
> Regards,
> Philippe
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-users
>
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home