I am not sure. If you don't see any packets it is always worth checking if
iptables is dropping packets. How does your "iptables -L" look like?
I think there have been many issue with networking on several distributions
with the older Xen version. Maybe it'd be worth a try to upgrade to a newer Xen
version?
> -----Original Message-----
> From: Javier Merino [mailto:jmerino@xxxxxxxxxx]
> Sent: 04 September 2008 12:32
> To: Fischer, Anna
> Cc: Dustin.Henning@xxxxxxxxxxx; xen-users@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-users] eth0 on dom0 not working on a bridged conf
>
> 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