[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] peth1: received packet with own address as source address



On Mon, 2005-10-17 at 18:52 -0400, Ted Kaczmarek wrote:
> On Mon, 2005-10-17 at 16:54 -0500, Jerone Young wrote:
> > On Mon, 2005-10-17 at 16:04 -0500, Andrew Theurer wrote:
> > > Arnd Schmitter wrote:
> > > 
> > > > David F Barrera wrote:
> > > >
> > > >> On Mon, 2005-10-17 at 20:50 +0200, Arnd Schmitter wrote:
> > > >>  
> > > >>
> > > >>> David F Barrera wrote:
> > > >>>    
> > > >>>
> > > >>>> peth1: received packet with  own address as source address
> > > >>>>
> > > >>>> Is this something that I should care about? I don't see an obvious
> > > >>>> impact to the machine.          
> > > >>>
> > > >>> This means normaly two things: Packets you send out are returning or 
> > > >>> there is another PC with the same address.
> > > >>> The Linuxkernel drops this packets as he think its a knd of address 
> > > >>> spoofing.
> > > >>> If all networking is working fine you will only have a minimal 
> > > >>> impact on performance. But it could indicate that something with 
> > > >>> your network configuration is wrong
> > > >>>     
> > > >>
> > > >> Arnd, thanks for your response. My network configuration appears to be
> > > >> OK; it is simple, one NIC and its IP address, and everything seems to 
> > > >> be
> > > >> working well. Also, there are no two machines with the same address. 
> > > >> So,
> > > >> I am wondering if this is a problem with Xen. I have opened up a
> > > >> bugzilla report, as I would like to have a definitive answer as to
> > > >> whether this is a bug or a network configuration issue.
> > > >>
> > > >> http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=339
> > > >>   
> > > >
> > > >
> > > > Only one NIC and peth1 ??
> > > >
> > > > Take a look at your ifconfig output. Maybe there are two 
> > > > Virtual-Interfaces witch the same MAC.
> > > 
> > > Unless the network-bridge script has changed the generated mac for eth0 
> > > (which gets renamed to peth0), all systems probably have the same mac 
> > > for peth0 & xen-br0: fe:ff:ff:ff:ff:ff.  I have tried using unique macs 
> > > (for just peth0, vif0.0, and xen-br0, other vifs still have fe:ff...), 
> > > and these messages disappear.  So, why would the mac for a veth0 or 
> > > xen-br0 get sent to another system?  Not sure, since they should not 
> > > have an ip address, and should not respond to an arp request.  I do 
> > > notice that peth0 has 'noarp' but xen-br0 does not.  Perhaps adding 
> > > noarp to xen-br0 will fix this.
> > 
> > This might just be it. We are no longer seeing it if we start xend with
> > #export netdev=eth1
> > #xend start
> > #ifconfig xen-br0 -arp
> > 
> > on an IBM HS20 blade that showed the error earlier. Could anyone else
> > seeing this try this to confirm this amongst more setups.
> > 
> > 
> > > 
> 
> I never see this when I use a setup like this.
> 
> 
> dom0 #1
> dom0 eth0 1.1.1.1/24
> dom0 eth0:1 1.1.2.1/24
> all domU's 1.1.1.2-127/24
> 
> dom0 #2
> dom0 eth0 1.1.1.2/24
> dom0 eth0:1 1.1.2.1/24
> all domU's 1.1.1.127-254/24
> 
> 
> But like this
> 
> dom0 eth0 1.1.1.1/24
> dom0 eth1 1.1.2.1/24
> all domU's 1.1.1.2-127/24
> 
> dom0 #2
> dom0 eth0 1.1.1.2/24
> dom0 eth1 1.1.2.1/24
> all domU's 1.1.1.127-254/24
> 
> It happens consistently.
> 
> The no arp issue may be masking something else, you really want the
> bridge to respond for arps for nodes behind it, otherwise all ports must
> get flooded.
> 
> 
 My bad, mixing up arp snooping here, the arps must always be flooded.
Been mulling this, peth0 is the bridge id, but without spanning tree
running should not be doing anything. Ian also stated this when I first
brought this up.

Has anyone captured this packet/frame yet? 

That would likely explain a lot.

Regards,
Ted



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.