I'm still with the same problem, but I know better what is not working.
It is not just arp packets, but all incoming ethernet traffic to eth0 en
dom0.
If I enforce arp to bind the mac addr to the ip addr, dom0 sends the
ping, the external host replies to the ping, but the reply is never seen
at dom0.
*this is what I see from the external host with tshark when dom0 pings it*
9895.649694 172.30.1.16 -> 172.30.1.11 ICMP Echo (ping) request
9895.649754 172.30.1.11 -> 172.30.1.16 ICMP Echo (ping) reply
*this is how I have enforced arp, and how ping is sent and echo received
from domU 172.30.1.81, *
*but not from the external host 172.30.1.11*
blade06:~/debug# arp -n
blade06:~/debug# tshark -i eth0 ether host 00:14:5e:da:3a:a2 &
[1] 3944
blade06:~/debug# Capturing on eth0
blade06:~/debug# ping -c 1 172.30.1.11
PING 172.30.1.11 (172.30.1.11) 56(84) bytes of data.
0.000000 Ibm_da:3a:a2 -> Broadcast ARP Who has 172.30.1.11? Tell
172.30.1.16
1.000062 Ibm_da:3a:a2 -> Broadcast ARP Who has 172.30.1.11? Tell
172.30.1.16
2.000121 Ibm_da:3a:a2 -> Broadcast ARP Who has 172.30.1.11? Tell
172.30.1.16
From 172.30.1.16 icmp_seq=1 Destination Host Unreachable
--- 172.30.1.11 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
blade06:~/debug# arp -n
blade06:~/debug# ping -c 1 172.30.1.81
PING 172.30.1.81 (172.30.1.81) 56(84) bytes of data.
26.529660 Ibm_da:3a:a2 -> Broadcast ARP Who has 172.30.1.81? Tell
172.30.1.16
64 bytes from 172.30.1.81: icmp_seq=1 ttl=64 time=0.568 ms
--- 172.30.1.81 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.568/0.568/0.568/0.000 ms
26.529773 Xensourc_a4:65:f2 -> Ibm_da:3a:a2 ARP 172.30.1.81 is at
00:16:3e:a4:65:f2
26.529785 172.30.1.16 -> 172.30.1.81 ICMP Echo (ping) request
26.529868 172.30.1.81 -> 172.30.1.16 ICMP Echo (ping) reply
blade06:~/debug# 31.528379 Xensourc_a4:65:f2 -> Ibm_da:3a:a2 ARP Who
has 172.30.1.16? Tell 172.30.1.81
31.528389 Ibm_da:3a:a2 -> Xensourc_a4:65:f2 ARP 172.30.1.16 is at
00:14:5e:da:3a:a2
blade06:~/debug# arp -n
Address HWtype HWaddress Flags
Mask Iface
172.30.1.81 ether 00:16:3E:A4:65:F2
C eth0
blade06:~/debug# arp --set 172.30.1.11 00:09:6b:b5:0d:90
blade06:~/debug# arp -n
Address HWtype HWaddress Flags
Mask Iface
172.30.1.81 ether 00:16:3E:A4:65:F2
C eth0
172.30.1.11 ether 00:09:6B:B5:0D:90
CM eth0
blade06:~/debug# ping -c 1 172.30.1.11
PING 172.30.1.11 (172.30.1.11) 56(84) bytes of data.
188.243727 172.30.1.16 -> 172.30.1.11 ICMP Echo (ping) request
--- 172.30.1.11 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
blade06:~/debug#
Javier Merino escribió:
You are right Anna(except that my external machine is 172.30.1.11):
arp tables in dom0 has not binding for the external machine
(172.30.1.11) while it has for domU (172.30.1.81).
But my external machine 'can see' the arp packets sent from dom0 and
is replying to them. So arp-request packets are going out the bridge,
but arp-response packets seems not to be going back from the bridge
xenbr0. I'm not sure about this.
Thank you both.
NOTES:
Dustin: the other set up I have with xen 3.0 has the same brctl
configuration. I suppose it is the 3.0 conf as Anna said.
I have not setup an interface for 'default router' 172.30.1.1 at my
router, but I think this should not interfere.
*dom0 172.30.1.16*
blade06:~# ping 172.30.1.81
PING 172.30.1.81 (172.30.1.81) 56(84) bytes of data.
64 bytes from 172.30.1.81: icmp_seq=1 ttl=64 time=0.898 ms
...
blade06:~# ping 172.30.1.11
PING 172.30.1.11 (172.30.1.11) 56(84) bytes of data.
From 172.30.1.16 icmp_seq=1 Destination Host Unreachable
...
blade06:~# arp -n
Address HWtype HWaddress Flags
Mask Iface
172.30.1.1
(incomplete) eth0
172.30.1.11
(incomplete) eth0
172.30.1.81 ether 00:16:3E:A4:65:F2
C eth0
*domU 172.30.1.81*
test:~# ping 172.30.1.11
PING 172.30.1.11 (172.30.1.11) 56(84) bytes of data.
64 bytes from 172.30.1.11: icmp_seq=1 ttl=64 time=0.603 ms
...
test:~# ping 172.30.1.16
PING 172.30.1.16 (172.30.1.16) 56(84) bytes of data.
64 bytes from 172.30.1.16: icmp_seq=1 ttl=64 time=0.424 ms
...
test:~# arp -n
Address HWtype HWaddress Flags
Mask Iface
172.30.1.11 ether 00:09:6B:B5:0D:90
C eth0
172.30.1.16 ether 00:14:5E:DA:3A:A2
C eth0
*external machine 172.30.1.11*
* - 1st while pinging domU from dom0 (at 0.000000)
* - 2nd while pinging ext mach from dom0 (at 41.160119 and after)
blade01:~# tshark -i peth0 ether host 00:14:5e:da:3a:a2
Capturing on peth0
0.000000 Ibm_da:3a:a2 -> Broadcast ARP Who has 172.30.1.81? Tell
172.30.1.16
41.160119 Ibm_da:3a:a2 -> Broadcast ARP Who has 172.30.1.11? Tell
172.30.1.16
41.160153 Ibm_b5:0d:90 -> Ibm_da:3a:a2 ARP 172.30.1.11 is at
00:09:6b:b5:0d:90
42.160092 Ibm_da:3a:a2 -> Broadcast ARP Who has 172.30.1.11? Tell
172.30.1.16
42.160114 Ibm_b5:0d:90 -> Ibm_da:3a:a2 ARP 172.30.1.11 is at
00:09:6b:b5:0d:90
43.160099 Ibm_da:3a:a2 -> Broadcast ARP Who has 172.30.1.11? Tell
172.30.1.16
43.160120 Ibm_b5:0d:90 -> Ibm_da:3a:a2 ARP 172.30.1.11 is at
00:09:6b:b5:0d:90
44.167066 Ibm_da:3a:a2 -> Broadcast ARP Who has 172.30.1.11? Tell
172.30.1.16
44.167089 Ibm_b5:0d:90 -> Ibm_da:3a:a2 ARP 172.30.1.11 is at
00:09:6b:b5:0d:90
45.164106 Ibm_da:3a:a2 -> Broadcast ARP Who has 172.30.1.11? Tell
172.30.1.16
45.164130 Ibm_b5:0d:90 -> Ibm_da:3a:a2 ARP 172.30.1.11 is at
00:09:6b:b5:0d:90
46.164119 Ibm_da:3a:a2 -> Broadcast ARP Who has 172.30.1.11? Tell
172.30.1.16
46.164141 Ibm_b5:0d:90 -> Ibm_da:3a:a2 ARP 172.30.1.11 is at
00:09:6b:b5:0d:90
49.240145 Ibm_da:3a:a2 -> Broadcast ARP Who has 172.30.1.1? Tell
172.30.1.16
50.240151 Ibm_da:3a:a2 -> Broadcast ARP Who has 172.30.1.1? Tell
172.30.1.16
51.240156 Ibm_da:3a:a2 -> Broadcast ARP Who has 172.30.1.1? Tell
172.30.1.16
Fischer, Anna escribió:
No I think that is correct because Javier is using an old Xen version
(3.0.3). What does your ARP table on Dom0 show? Does it have a
binding for 172.30.1.81 (your external machine)? It looks as if your
ARP requests from Dom0 do not reach the network, and so the ping
request does not go out.
-----Original Message-----
From: xen-users-bounces@xxxxxxxxxxxxxxxxxxx [mailto:xen-users-
bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Dustin Henning
Sent: 03 September 2008 17:48
To: 'Javier Merino'; xen-users@xxxxxxxxxxxxxxxxxxx
Subject: RE: [Xen-users] eth0 on dom0 not working on a bridged conf
I think eth0 should be included under interfaces here:
bridge name bridge id STP enabled interfaces
xenbr0 8000.feffffffffff no vif0.0
peth0
vif3.0
The appropriate brctl command will add it to the bridge (not at a Linux
machine to get you that command). This is because peth0 is the
physical
connection to the network and eth0 is where your address is assigned.
This
is the normal setup for older versions of xen, except eth0 should have
been
automatically added to the bridge during startup. On newer versions,
xenbr0
is deprecated and eth0 is the bridge (which has the address assigned to
itself).
Dustin
-----Original Message-----
From: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
[mailto:xen-users-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Javier
Merino
Sent: Wednesday, September 03, 2008 12:20
To: xen-users@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-users] eth0 on dom0 not working on a bridged conf
Hi,
I've installed xen 3.0.3 from packages (xen-linux-system) on a debian
etch, and i've configured it with network-bridge script in the default
way (netdev=eth0, bridge=xenbr0, etc...) which is ok for me.
the problem I have:
I cannot ping any outer machine from dom0 (nor any outer machine can
ping me). It gives me a "Destination Host Unreachable" message that
makes me think there is no arp response.
other symptoms:
I can ping from dom0 any domU's I create...
... and from those domU's I can ping dom0 and also the outer
machines that I was unable to ping from dom0. => so, xenbr0 if working
properly with peth0, vifX.0 (and eth0 on domU's)
Configuration looks fine in comparation with other xen 3.0 machines I
have working. Here is a "/etc/xen/scripts/network-bridge status":
============================================================
6: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc noqueue
link/ether 00:14:5e:da:3a:a2 brd ff:ff:ff:ff:ff:ff
inet 172.30.1.16/24 brd 172.30.1.255 scope global eth0
inet6 fe80::214:5eff:feda:3aa2/64 scope link
valid_lft forever preferred_lft forever
13: xenbr0: <BROADCAST,NOARP,UP,10000> mtu 1500 qdisc noqueue
link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
inet6 fe80::200:ff:fe00:0/64 scope link
valid_lft forever preferred_lft forever
bridge name bridge id STP enabled interfaces
xenbr0 8000.feffffffffff no vif0.0
peth0
vif3.0
172.30.1.0/24 dev eth0 proto kernel scope link src 172.30.1.16
default via 172.30.1.1 dev eth0
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
172.30.1.0 0.0.0.0 255.255.255.0 U 0 0 0
eth0
0.0.0.0 172.30.1.1 0.0.0.0 UG 0 0 0
eth0
============================================================
If I manually "/etc/xen/scripts/network-bridge stop", eth0 begins
working correctly with the exterior (I can ping, ssh, outer machines
and
viceversa).
dmesg, xend.log and xen-debug.log looks fine for me, but I may missed
up something .
I've installed tshark to test the communications when network-bridge
is up, but my knowledge is not enough to understand what's happening.
I'll send the output of whatever you ask me.
Thanks if anyone can help. I am lost after trying almost my best.
_______________________________________________
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
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home