WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-users

Re: [Xen-users] Yet another question about multiple NICs

Le dimanche 19 décembre 2010 à 16:16 +0100, Philippe Combes a écrit :
> Hello Simon,
> 
> Thanks for your help.
> 
> Simon Hobson wrote :
> > I think the next thing I'd be doing is firing up wireshark (or rather 
> > it's text-only brother tshark).
> > 
> > On Dom0, get the network working and ping another machine on the lan.
> > Fire up tshark on peth<n> and watch the traffic - you should see both 
> > the ping request and reply.
> > Fire up a DomU, and do the same ping - which I gather doesn't work. Keep 
> > the ping going from Dom0.
> > Keep watching the packet trace in Dom0 - of interest here are things like :
> 
> I am afraid we are about to reach the (short) limits of my competences
> in networking. I tried nevertheless, and looking at the trace below, I
> think I can answer your questions, if I really executed what you meant.
> 
> > Did DomU send an ARP request for the remote device ?
> Yes.
> 
> > Did the remote device reply ?
> > Are the ping requests going out ?
> > Are the replies coming back ? To the right MAC ?
> No, No, No.
> 
> $ ping 192.168.24.125 & tshark -i peth1
> [1] 21099
> PING 192.168.24.125 (192.168.24.125) 56(84) bytes of data.
> Running as user "root" and group "root". This could be dangerous.
> Capturing on peth1
>    0.000000 SunMicro_40:ca:75 -> Broadcast    ARP Who has
> 192.168.24.125?  Tell 192.168.24.123
> 64 bytes from 192.168.24.125: icmp_seq=1 ttl=64 time=2004 ms
> 64 bytes from 192.168.24.125: icmp_seq=2 ttl=64 time=1004 ms
> 64 bytes from 192.168.24.125: icmp_seq=3 ttl=64 time=4.48 ms
>    1.000061 SunMicro_40:ca:75 -> Broadcast    ARP Who has
> 192.168.24.125?  Tell 192.168.24.123
>    1.000280 QuantaCo_e0:81:2c -> SunMicro_40:ca:75 ARP 192.168.24.125
> is at 00:16:36:e0:81:2c
>    1.000293 192.168.24.123 -> 192.168.24.125 ICMP Echo (ping) request
>    1.000296 192.168.24.123 -> 192.168.24.125 ICMP Echo (ping) request
>    1.000299 192.168.24.123 -> 192.168.24.125 ICMP Echo (ping) request
>    1.000522 192.168.24.125 -> 192.168.24.123 ICMP Echo (ping) reply
>    1.000541 192.168.24.125 -> 192.168.24.123 ICMP Echo (ping) reply
>    1.000545 192.168.24.125 -> 192.168.24.123 ICMP Echo (ping) reply
> 64 bytes from 192.168.24.125: icmp_seq=4 ttl=64 time=0.137 ms
>    2.000149 192.168.24.123 -> 192.168.24.125 ICMP Echo (ping) request
>    2.000276 192.168.24.125 -> 192.168.24.123 ICMP Echo (ping) reply
>    2.208653 Cisco_c8:90:30 -> Cisco_c8:90:30 LOOP Reply
> 64 bytes from 192.168.24.125: icmp_seq=5 ttl=64 time=0.298 ms
>    3.000210 192.168.24.123 -> 192.168.24.125 ICMP Echo (ping) request
>    3.000501 192.168.24.125 -> 192.168.24.123 ICMP Echo (ping) reply
>    3.034484 Cisco_c8:90:30 -> CDP/VTP/DTP/PAgP/UDLD CDP Device ID:
> sw_admin-3.gridmip.cict.fr  Port ID: FastEthernet0/48
> 64 bytes from 192.168.24.125: icmp_seq=6 ttl=64 time=0.213 ms
>    4.000290 192.168.24.123 -> 192.168.24.125 ICMP Echo (ping) request
>    4.000496 192.168.24.125 -> 192.168.24.123 ICMP Echo (ping) reply
> 64 bytes from 192.168.24.125: icmp_seq=7 ttl=64 time=0.128 ms
>    5.000360 192.168.24.123 -> 192.168.24.125 ICMP Echo (ping) request
>    5.000476 192.168.24.125 -> 192.168.24.123 ICMP Echo (ping) reply
> 64 bytes from 192.168.24.125: icmp_seq=8 ttl=64 time=0.291 ms
>    6.000424 192.168.24.123 -> 192.168.24.125 ICMP Echo (ping) request
>    6.000458 QuantaCo_e0:81:2c -> SunMicro_40:ca:75 ARP Who has
> 192.168.24.123?  Tell 192.168.24.125
>    6.000467 SunMicro_40:ca:75 -> QuantaCo_e0:81:2c ARP 192.168.24.123
> is at 00:14:4f:40:ca:75
>    6.000708 192.168.24.125 -> 192.168.24.123 ICMP Echo (ping) reply
> 64 bytes from 192.168.24.125: icmp_seq=9 ttl=64 time=0.204 ms
>    7.000496 192.168.24.123 -> 192.168.24.125 ICMP Echo (ping) request
>    7.000693 192.168.24.125 -> 192.168.24.123 ICMP Echo (ping) reply
> 64 bytes from 192.168.24.125: icmp_seq=10 ttl=64 time=0.366 ms
> -------------->>> Launching the ping from dom1
>    7.497007 Xensourc_55:af:c3 -> Broadcast    ARP Who has
> 192.168.24.125?  Tell 192.168.24.81
>    8.000575 192.168.24.123 -> 192.168.24.125 ICMP Echo (ping) request
>    8.000932 192.168.24.125 -> 192.168.24.123 ICMP Echo (ping) reply
> 64 bytes from 192.168.24.125: icmp_seq=11 ttl=64 time=0.276 ms
>    8.497069 Xensourc_55:af:c3 -> Broadcast    ARP Who has
> 192.168.24.125?  Tell 192.168.24.81
>    9.000660 192.168.24.123 -> 192.168.24.125 ICMP Echo (ping) request
>    9.000928 192.168.24.125 -> 192.168.24.123 ICMP Echo (ping) reply
> 64 bytes from 192.168.24.125: icmp_seq=12 ttl=64 time=0.189 ms
>    9.497141 Xensourc_55:af:c3 -> Broadcast    ARP Who has
> 192.168.24.125?  Tell 192.168.24.81
>   10.000729 192.168.24.123 -> 192.168.24.125 ICMP Echo (ping) request
>   10.000912 192.168.24.125 -> 192.168.24.123 ICMP Echo (ping) reply
> 64 bytes from 192.168.24.125: icmp_seq=13 ttl=64 time=0.355 ms
>   10.517213 Xensourc_55:af:c3 -> Broadcast    ARP Who has
> 192.168.24.125?  Tell 192.168.24.81
>   11.000792 192.168.24.123 -> 192.168.24.125 ICMP Echo (ping) request
>   11.001140 192.168.24.125 -> 192.168.24.123 ICMP Echo (ping) reply
> 64 bytes from 192.168.24.125: icmp_seq=14 ttl=64 time=0.273 ms
>   11.517283 Xensourc_55:af:c3 -> Broadcast    ARP Who has
> 192.168.24.125?  Tell 192.168.24.81
>   12.000869 192.168.24.123 -> 192.168.24.125 ICMP Echo (ping) request
>   12.001136 192.168.24.125 -> 192.168.24.123 ICMP Echo (ping) reply
>   12.211749 Cisco_c8:90:30 -> Cisco_c8:90:30 LOOP Reply
> 64 bytes from 192.168.24.125: icmp_seq=15 ttl=64 time=0.174 ms
>   12.517356 Xensourc_55:af:c3 -> Broadcast    ARP Who has
> 192.168.24.125?  Tell 192.168.24.81
>   13.000938 192.168.24.123 -> 192.168.24.125 ICMP Echo (ping) request
>   13.001106 192.168.24.125 -> 192.168.24.123 ICMP Echo (ping) reply
> -------------->>> Stopping the ping from dom1
> 64 bytes from 192.168.24.125: icmp_seq=16 ttl=64 time=0.348 ms
>   14.000996 192.168.24.123 -> 192.168.24.125 ICMP Echo (ping) request
>   14.001338 192.168.24.125 -> 192.168.24.123 ICMP Echo (ping) reply
> 64 bytes from 192.168.24.125: icmp_seq=17 ttl=64 time=0.262 ms
>   15.001079 192.168.24.123 -> 192.168.24.125 ICMP Echo (ping) request
>   15.001335 192.168.24.125 -> 192.168.24.123 ICMP Echo (ping) reply
> 64 bytes from 192.168.24.125: icmp_seq=18 ttl=64 time=0.176 ms
>   16.001153 192.168.24.123 -> 192.168.24.125 ICMP Echo (ping) request
>   16.001322 192.168.24.125 -> 192.168.24.123 ICMP Echo (ping) reply
> 64 bytes from 192.168.24.125: icmp_seq=19 ttl=64 time=0.338 ms
>   17.001222 192.168.24.123 -> 192.168.24.125 ICMP Echo (ping) request
>   17.001554 192.168.24.125 -> 192.168.24.123 ICMP Echo (ping) reply
> 64 bytes from 192.168.24.125: icmp_seq=20 ttl=64 time=0.255 ms
>   18.001291 192.168.24.123 -> 192.168.24.125 ICMP Echo (ping) request
>   18.001539 192.168.24.125 -> 192.168.24.123 ICMP Echo (ping) reply
> 64 bytes from 192.168.24.125: icmp_seq=21 ttl=64 time=0.166 ms
> ^C 19.001359 192.168.24.123 -> 192.168.24.125 ICMP Echo (ping) request
>   19.001519 192.168.24.125 -> 192.168.24.123 ICMP Echo (ping) reply
> 56 packets captured
> 
> 
> 
> > If you see requests going out, but no reply, try firing up a packet 
> > sniffer on the remote machine and see if the requests are reaching it.
> 
> I used tshark on the target too. No packet reaches it.
> 
> > Also, apart from the initial messages* when you fire up the DomU, are 
> > there any other bridge related messages in the logs ?
> > * From memory, it should log :
> > Interface added
> > Interface going into learning mode
> > Interface going into active mode
> > 
> 
> I found no such message in my logs, but I remember I saw them on
> the console, once when I had an access to it.
> But looking those messages, I found something I never saw before,
> because it was in /var/log/syslog, and I only looked in /var/log/xen/* 
> so far:
> ----
> logger: /etc/xen/scripts/vif-bridge: Successful vif-bridge online for
> vif1.0, bridge eth0
> .
> logger: /etc/xen/scripts/block: Writing
> backend/vbd/1/51713/hotplug-status connected to x
> enstore.
> logger: /etc/xen/scripts/vif-bridge: Writing
> backend/vif/1/0/hotplug-status connected to
> xenstore.
> logger: /etc/xen/scripts/vif-bridge: iptables -A FORWARD -m physdev
> --physdev-in vif1.1
> -j ACCEPT failed.#012If you are using iptables, this may affect
> networking for guest domains.
> logger: /etc/xen/scripts/vif-bridge: Successful vif-bridge online for
> vif1.1, bridge eth1
> .
> logger: /etc/xen/scripts/vif-bridge: Writing
> backend/vif/1/1/hotplug-status connected to
> xenstore.
> ----
> 
> When I invert the vifs in the dom1 description, I get the same error
> about iptables for the second vif.
> Have anyone any idea how I could follow down this new track ? iptables 
> -nvL seems ok. Anything else to check for ?
> 
> Regards and thanks,
> Philippe

Hello,

Udev rules are mandatory on Debian systems with XEN, I use it always and
in /etc/network/interfaces :
auto br0
iface br0 inet static
      address 192.168.1.8
      netmask 255.255.255.0
      network 192.168.1.0
      broadcast 192.168.1.255
      mtu 1500
      txqueuelen 4096
      gateway 192.168.1.11
      bridge_ports eth0
      bridge_maxwait    1

Regards

JP P

> 
> _______________________________________________
> 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