Re: [Xen-users] newbie in trouble with CentOS Xen

[Alexandre Kouznetsov <alk@xxxxxxxxxx>]

El 05/04/13 20:02, Dave Stevens escribió:
> I started apache in dom0 and from outside wa getting the default apache
> page, have now replaced it with something slightly more meaningful.
While testing low level connectivity (layer 2 and 3), a ping (aka ICMP 
echo) is usually enough. A high level service, such as Apache, would 
also work, but may introduce false positives and false negatives if not 
used properly.

> So I
> think the xenbr1 connection to vif4.1 must not be working properly in
> sending packets to domU's eth1
>
> in dom0:
>
> peth1     Link encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF
>            inet6 addr: fe80::fcff:ffff:feff:ffff/64 Scope:Link
>            UP BROADCAST RUNNING NOARP  MTU:1500  Metric:1
>            RX packets:118842 errors:0 dropped:0 overruns:0 frame:0
>            TX packets:181148 errors:0 dropped:0 overruns:0 carrier:0
>            collisions:0 txqueuelen:1000
>            RX bytes:24736385 (23.5 MiB)  TX bytes:17074473 (16.2 MiB)
>            Interrupt:251 Base address:0xe000
> so lots of traffic there and then:
>
> xenbr1    Link encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF
>            UP BROADCAST RUNNING NOARP  MTU:1500  Metric:1
>            RX packets:143222 errors:0 dropped:0 overruns:0 frame:0
>            TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>            collisions:0 txqueuelen:0
>            RX bytes:21810836 (20.8 MiB)  TX bytes:0 (0.0 b)
>
> so why no TX bytes?
That is not normal. There is always feedback traffic, even if the 
outgoing packets are routed to other interface.
> and vif4.1 is:
> vif4.1    Link encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF
>            inet6 addr: fe80::fcff:ffff:feff:ffff/64 Scope:Link
>            UP BROADCAST RUNNING NOARP  MTU:1500  Metric:1
>            RX packets:40649 errors:0 dropped:0 overruns:0 frame:0
>            TX packets:23529 errors:0 dropped:0 overruns:0 carrier:0
>            collisions:0 txqueuelen:500
>            RX bytes:1138388 (1.0 MiB)  TX bytes:8233545 (7.8 MiB)
>
> and domU's eth1 is:
>
> eth1      Link encap:Ethernet  HWaddr 00:16:3E:52:61:CE
>            inet addr:204.174.35.215  Bcast:204.174.35.255
> Mask:255.255.255.0
>            inet6 addr: fe80::216:3eff:fe52:61ce/64 Scope:Link
>            UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>            RX packets:23474 errors:0 dropped:0 overruns:0 frame:0
>            TX packets:40601 errors:0 dropped:0 overruns:0 carrier:0
>            collisions:0 txqueuelen:1000
>            RX bytes:8214830 (7.8 MiB)  TX bytes:1705458 (1.6 MiB)
>
> domU is lower thandom0 because I rebooted the VM
>
> Does any of this suggest anything to you?
I guess, peth1 is still within the bridge xenbr1.

In a case like this, I would get a tcpdump and take a look on vif4.1, 
xenbr1 and peth1.
Consider using -e key, to log MAC address of the devices.
If you ping your DomU from outside, in "normal working" case, you should 
see a echo-request on peth1, xenbr1 and vif4.1, followed by a echo-replay.
The request should have the MAC address of your router (or host within 
the same broadcast domain) as source, and the MAC address of your DomU 
(as defined in it's config and shown by ifconfig) as destination. The 
replay should have the same addresses inverted.
If you don't see echo-request on peth1, I would troubleshoot the switch.
If you don't see echo-request on xenbr1 or vif4.1, something is wrong 
with how they are participating in the bridge (try add and remove with 
brctl? see dmesg errors).
If you don't see echo-request on eth1 in DomU, while they are visible on 
vif4.1, it must be Xen's fault somehow.
If you see echo-request passing through but not echo-replay, or wrong 
MAC in it, commonly it has to do with routing errors.
Greetings.

--
Alexandre Kouznetsov


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