networking oddities, present status ? changeset: 7145:71466686d026

networking oddities, present status ? changeset: 7145:71466686d026

[Ted Kaczmarek]

What is the present status of networking? Also will assigning unique mac
addresses to individual bridges on a domO be supported?


Seeing all kings of weird behavior when testing multiple nics.

changeset:   7145:71466686d026

nics=3

vif = ['mac=AA:00:00:11:11:12','bridge=xen-br1']


With the above I actually get eth0 and eth1 working on the domU, the
wild part is eth0 get the mac address AA:00:00:11:11:12 and shows up on
xen-br0.

Any other bridge setting for vif and weird stuff happens, broadcast
pings fail but unicast work, packet loss, total loss of connectivity,
packets from domU's get dropped at egress on domO, and domU kernel crash
have been observed.


vif = ['mac=AA:00:00:11:11:11' , 'bridge=xen-br0' , 'bridge=xen-br1' ,
'bridge=xen-br2']

Process swapper (pid: 1, threadinfo=c00b1000 task=c00b2a80)
Stack: 00000610 00000000 c17d1000 c0106685 00000001 00000000 c17cb240
c02294c3
       c17cb240 0000000b 00000000 00000006 00000000 0000000b 00000000
00000000
       00000000 00000000 c17b3740 c17cb246 c17b3752 00000000 c0229756
c04b8b60
Call Trace:
 [<c0106685>] gnttab_grant_foreign_access+0x15/0x60
 [<c02294c3>] setup_device+0x293/0x2c0
 [<c0229756>] talk_to_backend+0x136/0x390
 [<c0229a2f>] netfront_probe+0x7f/0x100
 [<c02250ed>] xenbus_dev_probe+0x4d/0x60
 [<c020b3ff>] driver_probe_device+0x2f/0x80
 [<c020b579>] driver_attach+0x59/0x90
 [<c020bacd>] bus_add_driver+0xad/0xf0
 [<c022517a>] xenbus_register_driver+0x5a/0x70
 [<c02251a7>] xenbus_register_device+0x17/0x20
 [<c033fd9f>] init_net_xenbus+0xf/0x20
 [<c033fdf0>] netif_init+0x40/0x50
 [<c032da72>] do_initcalls+0x32/0xf0
 [<c01040fa>] init+0x8a/0x1c0
 [<c0104070>] init+0x0/0x1c0
 [<c010748d>] kernel_thread_helper+0x5/0x18
Code: e9 60 55 08 00 f3 c3 8d b4 26 00 00 00 00 8d bc 27 00 00 00 00 56
53 83 ec 14 8b 74 24 20 8b 54 24 24 8b 5e 08 8b 86 f4 0c 00 00 <89> 83
90 00 00 00 0f b7 86 f8 0c 00 00 66 89 83 94 00 00 00 89


Regards,
Ted

Re: networking oddities, present status ? changeset: 7145:71466686d026

[Andrew Theurer]

On Friday 30 September 2005 13:10, Ted Kaczmarek wrote:
> What is the present status of networking? Also will assigning unique mac
> addresses to individual bridges on a domO be supported?
>
>
> Seeing all kings of weird behavior when testing multiple nics.
>
> changeset:   7145:71466686d026
>
> nics=3
>
> vif = ['mac=AA:00:00:11:11:12','bridge=xen-br1']
>
>
> With the above I actually get eth0 and eth1 working on the domU, the
> wild part is eth0 get the mac address AA:00:00:11:11:12 and shows up on
> xen-br0.
>
> Any other bridge setting for vif and weird stuff happens, broadcast
> pings fail but unicast work, packet loss, total loss of connectivity,
> packets from domU's get dropped at egress on domO, and domU kernel crash
> have been observed.

I have been experiencing some oddities as well.  Xen/bridge networking works 
on some switches, but not on others.  Also if I have one host with a domU 
communicating to another host, an unrelated host (with xen) will sometimes 
get "peth0: received packet with  own address as source address" error 
messages.  I have to wonder if all these bridges on the xen equipped hosts 
need unique MAC addresses (they all have fe:ff:ff:ff:ff:ff)

-Andrew
>
>
> vif = ['mac=AA:00:00:11:11:11' , 'bridge=xen-br0' , 'bridge=xen-br1' ,
> 'bridge=xen-br2']
>
> Process swapper (pid: 1, threadinfo=c00b1000 task=c00b2a80)
> Stack: 00000610 00000000 c17d1000 c0106685 00000001 00000000 c17cb240
> c02294c3
>        c17cb240 0000000b 00000000 00000006 00000000 0000000b 00000000
> 00000000
>        00000000 00000000 c17b3740 c17cb246 c17b3752 00000000 c0229756
> c04b8b60
> Call Trace:
>  [<c0106685>] gnttab_grant_foreign_access+0x15/0x60
>  [<c02294c3>] setup_device+0x293/0x2c0
>  [<c0229756>] talk_to_backend+0x136/0x390
>  [<c0229a2f>] netfront_probe+0x7f/0x100
>  [<c02250ed>] xenbus_dev_probe+0x4d/0x60
>  [<c020b3ff>] driver_probe_device+0x2f/0x80
>  [<c020b579>] driver_attach+0x59/0x90
>  [<c020bacd>] bus_add_driver+0xad/0xf0
>  [<c022517a>] xenbus_register_driver+0x5a/0x70
>  [<c02251a7>] xenbus_register_device+0x17/0x20
>  [<c033fd9f>] init_net_xenbus+0xf/0x20
>  [<c033fdf0>] netif_init+0x40/0x50
>  [<c032da72>] do_initcalls+0x32/0xf0
>  [<c01040fa>] init+0x8a/0x1c0
>  [<c0104070>] init+0x0/0x1c0
>  [<c010748d>] kernel_thread_helper+0x5/0x18
> Code: e9 60 55 08 00 f3 c3 8d b4 26 00 00 00 00 8d bc 27 00 00 00 00 56
> 53 83 ec 14 8b 74 24 20 8b 54 24 24 8b 5e 08 8b 86 f4 0c 00 00 <89> 83
> 90 00 00 00 0f b7 86 f8 0c 00 00 66 89 83 94 00 00 00 89
>
>
> Regards,
> Ted
>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: networking oddities, present status ? changeset: 7145:71466686d026

[Nivedita Singhvi]

Andrew Theurer wrote:
> On Friday 30 September 2005 13:10, Ted Kaczmarek wrote:
> 
>>What is the present status of networking? Also will assigning unique mac
>>addresses to individual bridges on a domO be supported?

I didn't see the parent post on this, and was working on exactly
the same question. Think there are still a few bugs out there,
especially with differing kernel configs (complex bridging,
some filtering, ipsec, tcp options, v6 support, etc). We'd like to beef
up some network test cases and then grind it out through all
the test frameworks. Yes on the latter question.

thanks,
Nivedita

> I have been experiencing some oddities as well.  Xen/bridge networking works 
> on some switches, but not on others.  Also if I have one host with a domU 

Which switches doesn't it work on, do you know?

> communicating to another host, an unrelated host (with xen) will sometimes 
> get "peth0: received packet with  own address as source address" error 
> messages.  I have to wonder if all these bridges on the xen equipped hosts 
> need unique MAC addresses (they all have fe:ff:ff:ff:ff:ff)

Re: networking oddities, present status ? changeset: 7145:71466686d026

[Ted Kaczmarek]

> .
> 
> I have been experiencing some oddities as well.  Xen/bridge networking works 
> on some switches, but not on others.  Also if I have one host with a domU 
> communicating to another host, an unrelated host (with xen) will sometimes 
> get "peth0: received packet with  own address as source address" error 
> messages.  I have to wonder if all these bridges on the xen equipped hosts 
> need unique MAC addresses (they all have fe:ff:ff:ff:ff:ff)
> 
> -Andrew

Only the bridge that xend brings up automatically is getting that mac in
my setup. The other two bridges I have use the mac address of the
ethernet they are a slave to. I am using FC4 domO.

I would think the bridge should always grab the mac address of the
ethernet is is a slave too, the dom0 than gets treated just like any
other managed bridge device, clean and simple. 

I suspect their may be a good reason for this, just beyond my scope of
knowledge.


Regards,
Ted

RE: networking oddities, present status ? changeset: 7145:71466686d026

[Ian Pratt]

> I have been experiencing some oddities as well.  Xen/bridge 
> networking works on some switches, but not on others.  Also 
> if I have one host with a domU communicating to another host, 
> an unrelated host (with xen) will sometimes get "peth0: 
> received packet with  own address as source address" error 
> messages.  I have to wonder if all these bridges on the xen 
> equipped hosts need unique MAC addresses (they all have 
> fe:ff:ff:ff:ff:ff)

Interesting. Perhaps run a "tcpdump ether host fe:ff:ff:ff:ff:ff" and
see if any other host is sending packets with that as a src address. I
wander if one of the hosts on the network has STP turned on?

Ian

Re: networking oddities, present status ? changeset: 7145:71466686d026

[Andrew Theurer]

Ian Pratt wrote:

>>I have been experiencing some oddities as well.  Xen/bridge 
>>networking works on some switches, but not on others.  Also 
>>if I have one host with a domU communicating to another host, 
>>an unrelated host (with xen) will sometimes get "peth0: 
>>received packet with  own address as source address" error 
>>messages.  I have to wonder if all these bridges on the xen 
>>equipped hosts need unique MAC addresses (they all have 
>>fe:ff:ff:ff:ff:ff)
>>    
>>
>
>Interesting. Perhaps run a "tcpdump ether host fe:ff:ff:ff:ff:ff" and
>see if any other host is sending packets with that as a src address. I
>wander if one of the hosts on the network has STP turned on?
>  
>

I give that a shot.  I have a feeling at least one of the three switches 
I have in my network may have STP on, and I guess I should check the xen 
hosts as well (they really should all be using the same network-bridge 
script).  If STP is off everywhere, is there any reason to not use 
fe:ff:ff:ff:ff:ff on all xen-br0 devices?

-Andrew

RE: networking oddities, present status ? changeset: 7145:71466686d026

[Ian Pratt]

 
> I give that a shot.  I have a feeling at least one of the 
> three switches I have in my network may have STP on, and I 
> guess I should check the xen hosts as well (they really 
> should all be using the same network-bridge script).  If STP 
> is off everywhere, is there any reason to not use 
> fe:ff:ff:ff:ff:ff on all xen-br0 devices?

I don't believe so.

However, I just ran tcpdump on my network and saw an occasional packet
with that src address come out from a non-Xen host (to the UDP discard
port -- no idea what this is), which causes all the Xen hosts to grumble
about someone else using their addr.

I'm not entirely sure why we started using the broadcast mac addr for
these. Although they don't need to be different, I wander if we should
be using an a more normal looking address.

Ian

Re: networking oddities, present status ? changeset: 7145:71466686d026

[Andrew Theurer]

On Saturday 01 October 2005 05:17, Ian Pratt wrote:
> > I give that a shot.  I have a feeling at least one of the
> > three switches I have in my network may have STP on, and I
> > guess I should check the xen hosts as well (they really
> > should all be using the same network-bridge script).  If STP
> > is off everywhere, is there any reason to not use
> > fe:ff:ff:ff:ff:ff on all xen-br0 devices?
>
> I don't believe so.
>
> However, I just ran tcpdump on my network and saw an occasional packet
> with that src address come out from a non-Xen host (to the UDP discard
> port -- no idea what this is), which causes all the Xen hosts to grumble
> about someone else using their addr.
>
> I'm not entirely sure why we started using the broadcast mac addr for
> these. Although they don't need to be different, I wander if we should
> be using an a more normal looking address.

I went ahead and tried giving unique mac addresses to each machine and that 
has stopped all grumblings.  New mac address are simply 
fe:ff:ff:ff:ff-$netdev_ip_third_octet:ff-$netdev_ip_fourth_octet.  Not sure 
if this is the best way, but so far it works.

-Andrew