thr3ads.net - Xen devel - [Xen-devel] bridge + arp [Sep 2008]

If this information is useful, please help other people find it:
Share via:

Moritz Möller

2008-Sep-19 18:58 UTC

[Xen-devel] bridge + arp

Hi,

this is propably bridge related and not really a xen problem, but it
might help someone:

Some of our domUs are not able to arp. Arp -n show (incomplete), and
doing a tcpdump shows, that on the dom0''s eth0 the arp request goes
out,
the response comes in, but on the vifX.0 interface the arp response is
gone. 

dom0# tcpdump -ni eth0
arp who-has 10.32.2.51 tell 10.32.7.70
arp reply 10.32.2.51 is-at 00:30:48:34:44:6c

dom0# tcpdump -ni br0
arp who-has 10.32.2.51 tell 10.32.7.70
arp reply 10.32.2.51 is-at 00:30:48:34:44:6c

dom0# tcpdump -ni vif3.0
arp who-has 10.32.2.51 tell 10.32.7.70

Does someone know why the dom0 br0 or vif eats the arp response?

Thanks a lot,

Moritz


ip a l
1: lo: <LOOPBACK,UP,10000> mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen
1000
    link/ether 00:30:48:34:13:dc brd ff:ff:ff:ff:ff:ff
    inet6 fe80::230:48ff:fe34:13dc/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
    link/ether 00:30:48:34:13:dd brd ff:ff:ff:ff:ff:ff
4: br0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc noqueue qlen 20000
    link/ether 00:30:48:34:13:dc brd ff:ff:ff:ff:ff:ff
    inet 10.32.2.50/14 brd 10.35.255.255 scope global br0
    inet6 fe80::230:48ff:fe34:13dc/64 scope link
       valid_lft forever preferred_lft forever
5: vif1.0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen
32
    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fcff:ffff:feff:ffff/64 scope link
       valid_lft forever preferred_lft forever
6: vif2.0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen
32
    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fcff:ffff:feff:ffff/64 scope link
       valid_lft forever preferred_lft forever
7: vif3.0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen
32
    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fcff:ffff:feff:ffff/64 scope link
       valid_lft forever preferred_lft forever


brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.0030483413dc       no              eth0
                                                        vif1.0
                                                        vif2.0
                                                        vif3.0



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Shaun R.

2008-Sep-19 19:35 UTC

head link

[Xen-devel] Re: bridge + arp

I''m not positive but i''m pretty sure this is the problem that
i see too...
read my post about this, is this the problem you see happen too?

http://lists.xensource.com/archives/html/xen-devel/2008-07/msg01020.html

~Shaun 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Moritz Möller

2008-Sep-19 20:26 UTC

head link

RE: [Xen-devel] Re: bridge + arp

Sound a bit similar, yes. I guess I have not solved it yet?

-----Original Message-----
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Shaun R.
Sent: Friday, September 19, 2008 9:35 PM
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Re: bridge + arp

I''m not positive but i''m pretty sure this is the problem that
i see
too... 
read my post about this, is this the problem you see happen too?

http://lists.xensource.com/archives/html/xen-devel/2008-07/msg01020.html

~Shaun 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Moritz Möller

2008-Sep-19 20:27 UTC

head link

RE: [Xen-devel] bridge + arp

By the way - We''re not using the netloop driver, i.e. we only have
eth0,
br0 and the vifN with N>=1.

What is the reason behind the vethN<->vif0.N thing?


-----Original Message-----
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Moritz
Möller
Sent: Friday, September 19, 2008 8:59 PM
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] bridge + arp

Hi,

this is propably bridge related and not really a xen problem, but it
might help someone:

Some of our domUs are not able to arp. Arp -n show (incomplete), and
doing a tcpdump shows, that on the dom0''s eth0 the arp request goes
out,
the response comes in, but on the vifX.0 interface the arp response is
gone. 

dom0# tcpdump -ni eth0
arp who-has 10.32.2.51 tell 10.32.7.70
arp reply 10.32.2.51 is-at 00:30:48:34:44:6c

dom0# tcpdump -ni br0
arp who-has 10.32.2.51 tell 10.32.7.70
arp reply 10.32.2.51 is-at 00:30:48:34:44:6c

dom0# tcpdump -ni vif3.0
arp who-has 10.32.2.51 tell 10.32.7.70

Does someone know why the dom0 br0 or vif eats the arp response?

Thanks a lot,

Moritz


ip a l
1: lo: <LOOPBACK,UP,10000> mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen
1000
    link/ether 00:30:48:34:13:dc brd ff:ff:ff:ff:ff:ff
    inet6 fe80::230:48ff:fe34:13dc/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
    link/ether 00:30:48:34:13:dd brd ff:ff:ff:ff:ff:ff
4: br0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc noqueue qlen 20000
    link/ether 00:30:48:34:13:dc brd ff:ff:ff:ff:ff:ff
    inet 10.32.2.50/14 brd 10.35.255.255 scope global br0
    inet6 fe80::230:48ff:fe34:13dc/64 scope link
       valid_lft forever preferred_lft forever
5: vif1.0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen
32
    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fcff:ffff:feff:ffff/64 scope link
       valid_lft forever preferred_lft forever
6: vif2.0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen
32
    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fcff:ffff:feff:ffff/64 scope link
       valid_lft forever preferred_lft forever
7: vif3.0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen
32
    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fcff:ffff:feff:ffff/64 scope link
       valid_lft forever preferred_lft forever


brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.0030483413dc       no              eth0
                                                        vif1.0
                                                        vif2.0
                                                        vif3.0



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Phil Winterfield (winterfi)

2008-Sep-19 20:37 UTC

head link

RE: [Xen-devel] bridge + arp

Moritz,

I am seeing something very similar - see
http://lists.xensource.com/archives/html/xen-devel/2008-09/msg00686.html

It looks as though the responses to arp requests are being dropped by the
bridge, causing a halt in packet forwarding. Interestingly, the packet drop
occurs even if I manually fill in the arp table with the entry. I am running
with xen-unstable c/s 18242.

Phil
> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> bounces@lists.xensource.com] On Behalf Of Moritz Möller
> Sent: Friday, September 19, 2008 11:59 AM
> To: xen-devel@lists.xensource.com
> Subject: [Xen-devel] bridge + arp
> 
> Hi,
> 
> this is propably bridge related and not really a xen problem, but it
> might help someone:
> 
> Some of our domUs are not able to arp. Arp -n show (incomplete), and
> doing a tcpdump shows, that on the dom0''s eth0 the arp request
goes out,
> the response comes in, but on the vifX.0 interface the arp response is
> gone.
> 
> dom0# tcpdump -ni eth0
> arp who-has 10.32.2.51 tell 10.32.7.70
> arp reply 10.32.2.51 is-at 00:30:48:34:44:6c
> 
> dom0# tcpdump -ni br0
> arp who-has 10.32.2.51 tell 10.32.7.70
> arp reply 10.32.2.51 is-at 00:30:48:34:44:6c
> 
> dom0# tcpdump -ni vif3.0
> arp who-has 10.32.2.51 tell 10.32.7.70
> 
> Does someone know why the dom0 br0 or vif eats the arp response?
> 
> Thanks a lot,
> 
> Moritz
> 
> 
> ip a l
> 1: lo: <LOOPBACK,UP,10000> mtu 16436 qdisc noqueue
>     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>     inet 127.0.0.1/8 scope host lo
>     inet6 ::1/128 scope host
>        valid_lft forever preferred_lft forever
> 2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast
qlen
> 1000
>     link/ether 00:30:48:34:13:dc brd ff:ff:ff:ff:ff:ff
>     inet6 fe80::230:48ff:fe34:13dc/64 scope link
>        valid_lft forever preferred_lft forever
> 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
>     link/ether 00:30:48:34:13:dd brd ff:ff:ff:ff:ff:ff
> 4: br0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc noqueue qlen
20000
>     link/ether 00:30:48:34:13:dc brd ff:ff:ff:ff:ff:ff
>     inet 10.32.2.50/14 brd 10.35.255.255 scope global br0
>     inet6 fe80::230:48ff:fe34:13dc/64 scope link
>        valid_lft forever preferred_lft forever
> 5: vif1.0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast
qlen
> 32
>     link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
>     inet6 fe80::fcff:ffff:feff:ffff/64 scope link
>        valid_lft forever preferred_lft forever
> 6: vif2.0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast
qlen
> 32
>     link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
>     inet6 fe80::fcff:ffff:feff:ffff/64 scope link
>        valid_lft forever preferred_lft forever
> 7: vif3.0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast
qlen
> 32
>     link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
>     inet6 fe80::fcff:ffff:feff:ffff/64 scope link
>        valid_lft forever preferred_lft forever
> 
> 
> brctl show
> bridge name     bridge id               STP enabled     interfaces
> br0             8000.0030483413dc       no              eth0
>                                                         vif1.0
>                                                         vif2.0
>                                                         vif3.0
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Moritz Möller

2008-Sep-19 20:45 UTC

head link

RE: [Xen-devel] bridge + arp

I have tried it with the network-bridge script now (netloop, renaming
eth0 to peth0 and using eth0 via netloop, adding it to the bridge) and
the result is the same - plus that I get a lot of "peth0: received
packet with own address as source address" kernel messages..

A strange thing is - after I do a brctl delif br0 vif1.0 && brctl addif
br0 vif1.0 the network works for a while.


-----Original Message-----
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Moritz
Möller
Sent: Friday, September 19, 2008 8:59 PM
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] bridge + arp

Hi,

this is propably bridge related and not really a xen problem, but it
might help someone:

Some of our domUs are not able to arp. Arp -n show (incomplete), and
doing a tcpdump shows, that on the dom0''s eth0 the arp request goes
out,
the response comes in, but on the vifX.0 interface the arp response is
gone. 

dom0# tcpdump -ni eth0
arp who-has 10.32.2.51 tell 10.32.7.70
arp reply 10.32.2.51 is-at 00:30:48:34:44:6c

dom0# tcpdump -ni br0
arp who-has 10.32.2.51 tell 10.32.7.70
arp reply 10.32.2.51 is-at 00:30:48:34:44:6c

dom0# tcpdump -ni vif3.0
arp who-has 10.32.2.51 tell 10.32.7.70

Does someone know why the dom0 br0 or vif eats the arp response?

Thanks a lot,

Moritz


ip a l
1: lo: <LOOPBACK,UP,10000> mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen
1000
    link/ether 00:30:48:34:13:dc brd ff:ff:ff:ff:ff:ff
    inet6 fe80::230:48ff:fe34:13dc/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
    link/ether 00:30:48:34:13:dd brd ff:ff:ff:ff:ff:ff
4: br0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc noqueue qlen 20000
    link/ether 00:30:48:34:13:dc brd ff:ff:ff:ff:ff:ff
    inet 10.32.2.50/14 brd 10.35.255.255 scope global br0
    inet6 fe80::230:48ff:fe34:13dc/64 scope link
       valid_lft forever preferred_lft forever
5: vif1.0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen
32
    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fcff:ffff:feff:ffff/64 scope link
       valid_lft forever preferred_lft forever
6: vif2.0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen
32
    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fcff:ffff:feff:ffff/64 scope link
       valid_lft forever preferred_lft forever
7: vif3.0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen
32
    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fcff:ffff:feff:ffff/64 scope link
       valid_lft forever preferred_lft forever


brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.0030483413dc       no              eth0
                                                        vif1.0
                                                        vif2.0
                                                        vif3.0



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Keir Fraser

2008-Sep-20 08:10 UTC

head link

Re: [Xen-devel] bridge + arp

On 19/9/08 21:27, "Moritz Möller" <m.moeller@bigpoint.net>
wrote:
> By the way - We''re not using the netloop driver, i.e. we only have
eth0,
> br0 and the vifN with N>=1.
> 
> What is the reason behind the vethN<->vif0.N thing?
netloop isn''t usually required any more. The problem it solved has been
addressed by other means.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Moritz Möller

2008-Sep-20 23:04 UTC

head link

RE: [Xen-devel] bridge + arp

Tried the xen packages from ubuntu (xen 3.3, kernel 2.6.24-19-xen),
using the supplied network-bridge script, still no success and still the
messages "peth0: received packet with  own address as source address"
in
dmesg.

I tested if the problem is that the bridge only forwards broadcasts (arp
request is broadcast, the response is unicast), but non-arp unicast is
forwarded correctly and brctl showmacs shows a matching entry for the
xen domU.

-----Original Message-----
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Moritz
Möller
Sent: Friday, September 19, 2008 10:45 PM
To: xen-devel@lists.xensource.com
Subject: RE: [Xen-devel] bridge + arp

I have tried it with the network-bridge script now (netloop, renaming
eth0 to peth0 and using eth0 via netloop, adding it to the bridge) and
the result is the same - plus that I get a lot of "peth0: received
packet with own address as source address" kernel messages..

A strange thing is - after I do a brctl delif br0 vif1.0 && brctl addif
br0 vif1.0 the network works for a while.


-----Original Message-----
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Moritz
Möller
Sent: Friday, September 19, 2008 8:59 PM
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] bridge + arp

Hi,

this is propably bridge related and not really a xen problem, but it
might help someone:

Some of our domUs are not able to arp. Arp -n show (incomplete), and
doing a tcpdump shows, that on the dom0''s eth0 the arp request goes
out,
the response comes in, but on the vifX.0 interface the arp response is
gone. 

dom0# tcpdump -ni eth0
arp who-has 10.32.2.51 tell 10.32.7.70
arp reply 10.32.2.51 is-at 00:30:48:34:44:6c

dom0# tcpdump -ni br0
arp who-has 10.32.2.51 tell 10.32.7.70
arp reply 10.32.2.51 is-at 00:30:48:34:44:6c

dom0# tcpdump -ni vif3.0
arp who-has 10.32.2.51 tell 10.32.7.70

Does someone know why the dom0 br0 or vif eats the arp response?

Thanks a lot,

Moritz


ip a l
1: lo: <LOOPBACK,UP,10000> mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen
1000
    link/ether 00:30:48:34:13:dc brd ff:ff:ff:ff:ff:ff
    inet6 fe80::230:48ff:fe34:13dc/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
    link/ether 00:30:48:34:13:dd brd ff:ff:ff:ff:ff:ff
4: br0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc noqueue qlen 20000
    link/ether 00:30:48:34:13:dc brd ff:ff:ff:ff:ff:ff
    inet 10.32.2.50/14 brd 10.35.255.255 scope global br0
    inet6 fe80::230:48ff:fe34:13dc/64 scope link
       valid_lft forever preferred_lft forever
5: vif1.0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen
32
    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fcff:ffff:feff:ffff/64 scope link
       valid_lft forever preferred_lft forever
6: vif2.0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen
32
    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fcff:ffff:feff:ffff/64 scope link
       valid_lft forever preferred_lft forever
7: vif3.0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen
32
    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fcff:ffff:feff:ffff/64 scope link
       valid_lft forever preferred_lft forever


brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.0030483413dc       no              eth0
                                                        vif1.0
                                                        vif2.0
                                                        vif3.0



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Moritz Möller

2008-Sep-22 11:44 UTC

head link

RE: [Xen-devel] bridge + arp [SOLVED]

The cause of this was that we bridged two VLANs in our router, and so an
outgoing arp broadcast did come back vlan encapsulated on eth0, causing
the FDB of the bridge module to change the port of the mac of the xen
machine from vif1.0 to eth0.

So if you do stuff like bridging two VLANs (we''re moving...), first
check if all switches (including the xen hosts) are capable of that.

-----Original Message-----
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Moritz
Möller
Sent: Sunday, September 21, 2008 1:04 AM
To: xen-devel@lists.xensource.com
Subject: RE: [Xen-devel] bridge + arp

Tried the xen packages from ubuntu (xen 3.3, kernel 2.6.24-19-xen),
using the supplied network-bridge script, still no success and still the
messages "peth0: received packet with  own address as source address"
in
dmesg.

I tested if the problem is that the bridge only forwards broadcasts (arp
request is broadcast, the response is unicast), but non-arp unicast is
forwarded correctly and brctl showmacs shows a matching entry for the
xen domU.

-----Original Message-----
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Moritz
Möller
Sent: Friday, September 19, 2008 10:45 PM
To: xen-devel@lists.xensource.com
Subject: RE: [Xen-devel] bridge + arp

I have tried it with the network-bridge script now (netloop, renaming
eth0 to peth0 and using eth0 via netloop, adding it to the bridge) and
the result is the same - plus that I get a lot of "peth0: received
packet with own address as source address" kernel messages..

A strange thing is - after I do a brctl delif br0 vif1.0 && brctl addif
br0 vif1.0 the network works for a while.


-----Original Message-----
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Moritz
Möller
Sent: Friday, September 19, 2008 8:59 PM
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] bridge + arp

Hi,

this is propably bridge related and not really a xen problem, but it
might help someone:

Some of our domUs are not able to arp. Arp -n show (incomplete), and
doing a tcpdump shows, that on the dom0''s eth0 the arp request goes
out,
the response comes in, but on the vifX.0 interface the arp response is
gone. 

dom0# tcpdump -ni eth0
arp who-has 10.32.2.51 tell 10.32.7.70
arp reply 10.32.2.51 is-at 00:30:48:34:44:6c

dom0# tcpdump -ni br0
arp who-has 10.32.2.51 tell 10.32.7.70
arp reply 10.32.2.51 is-at 00:30:48:34:44:6c

dom0# tcpdump -ni vif3.0
arp who-has 10.32.2.51 tell 10.32.7.70

Does someone know why the dom0 br0 or vif eats the arp response?

Thanks a lot,

Moritz


ip a l
1: lo: <LOOPBACK,UP,10000> mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen
1000
    link/ether 00:30:48:34:13:dc brd ff:ff:ff:ff:ff:ff
    inet6 fe80::230:48ff:fe34:13dc/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
    link/ether 00:30:48:34:13:dd brd ff:ff:ff:ff:ff:ff
4: br0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc noqueue qlen 20000
    link/ether 00:30:48:34:13:dc brd ff:ff:ff:ff:ff:ff
    inet 10.32.2.50/14 brd 10.35.255.255 scope global br0
    inet6 fe80::230:48ff:fe34:13dc/64 scope link
       valid_lft forever preferred_lft forever
5: vif1.0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen
32
    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fcff:ffff:feff:ffff/64 scope link
       valid_lft forever preferred_lft forever
6: vif2.0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen
32
    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fcff:ffff:feff:ffff/64 scope link
       valid_lft forever preferred_lft forever
7: vif3.0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen
32
    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fcff:ffff:feff:ffff/64 scope link
       valid_lft forever preferred_lft forever


brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.0030483413dc       no              eth0
                                                        vif1.0
                                                        vif2.0
                                                        vif3.0



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Apparently Analagous Threads

Search for more possibly parallel threads

Xen devel - Sep 2008 - bridge + arp

[Xen-devel] bridge + arp

[Xen-devel] Re: bridge + arp

RE: [Xen-devel] Re: bridge + arp

RE: [Xen-devel] bridge + arp

RE: [Xen-devel] bridge + arp

RE: [Xen-devel] bridge + arp

Re: [Xen-devel] bridge + arp

RE: [Xen-devel] bridge + arp

RE: [Xen-devel] bridge + arp [SOLVED]

Apparently Analagous Threads