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

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


  • To: xen-users@xxxxxxxxxxxxx
  • From: Alexandre Kouznetsov <alk@xxxxxxxxxx>
  • Date: Mon, 08 Apr 2013 12:23:16 -0500
  • Delivery-date: Mon, 08 Apr 2013 17:24:21 +0000
  • List-id: Xen user discussion <xen-users.lists.xen.org>

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


 


Rackspace

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