Ok now I got the point...
When it fails to connect, can you still ping the domain-0 or is it
really nothing then?
The domain-0 should be always at least reachable with your setup and
should then show up in ip neigh on the dom-1 (and if the dom-1 doesn't
reach anything else, it will be the only valid entry).
I think there should be some "FAILED" entries when a machine cannot
connect to the network, that's why I asked explicitly again.
If there are even no FAILED entries I think it even did not ask, which
means that some routes or address settings must be wrong.
Regards,
Felix
Am 21.12.2010 02:58, schrieb Philippe Combes:
> I am a bit confused now. What did I explained so badly ? Do I
> understand you well ?
> I said I ran ip neigh from both machines, as requested. And from dom1
> the output is similar to the output I dumped, but only when the
> connection succeeds. Because, once again, dom1 and dom0 are never
> "connected" at the same time, that is the issue. When dom0 (resp.
> dom1) fails to connect to the network, then 'ip neigh' shows nothing.
>
> Regards,
> Philippe
>
> Felix Kuperjans wrote:
>> 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
>
> _______________________________________________
> 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