new install eth0: received packet with own address as source

S

skrawcke

New Member
Apr 11, 2012
6
0
1
I just installed a new instance of proxmox.
it worked for a bit now I am getting a flood of

Code: 
proxmox kernel: eth0: received packet with own address as source


in the syslog, making the server unusable. I can no longer SSH,ping or use the web interface on the box.
I replaced the network card thinking that was the issue, reinstall and after a bit I get the same thing.
rebooted the switch/gareway/router and still get the same issue.


copy of the ifconfig.

Code: 
root@proxmox:~# ifconfig 
eth0      Link encap:Ethernet  HWaddr 68:05:ca:03:05:ef  
          inet6 addr: fe80::6a05:caff:fe03:5ef/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1424 errors:0 dropped:0 overruns:0 frame:0
          TX packets:419 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:117380 (114.6 KiB)  TX bytes:37921 (37.0 KiB)
          Interrupt:16 Memory:dfc60000-dfc80000 


lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:178 errors:0 dropped:0 overruns:0 frame:0
          TX packets:178 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:18191 (17.7 KiB)  TX bytes:18191 (17.7 KiB)


venet0    Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet6 addr: fe80::1/128 Scope:Link
          UP BROADCAST POINTOPOINT RUNNING NOARP  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:3 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)


vmbr0     Link encap:Ethernet  HWaddr 68:05:ca:03:05:ef  
          inet addr:10.73.10.21  Bcast:10.73.255.255  Mask:255.255.0.0
          inet6 addr: fe80::6a05:caff:fe03:5ef/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1500 errors:0 dropped:0 overruns:0 frame:0
          TX packets:278 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:105864 (103.3 KiB)  TX bytes:18805 (18.3 KiB)

I have reinstalled twice and am trying one more time.. is there any thing I am missing?
 
Don't know, but why your eth0 has an IP? What interfaces belong to vmbr0?
Normallly eth0 has no ip, vmbr0 has eth0 (so vmbr0 takes the mac address of eth0, that is not your case) and you assign an IP to vmbr0 just to be able to ssh and webadmin proxmox.
Other vmbr (i.e. vmbr1) usually (there are exceptions) don't even have an IP, you should think about them like a "hub" (the old dumb switches).
What is the content of your /etc/netsork/interfaces ?
 
eth0 doesn't have an IP.
When I get bac to work I will check /etc/network/interface, I also am going to try another box to see if it that is the cause.
 
I installed onto another box and after a bit I got the same issue..
I changed the IP and still have the same issue.
reset the router, firewall and switches and still got the same issue..
turned off IPV6 rebooted and still get
Code: 
proxmox kernel: eth0: received packet with own address as source

contents of /etc/network/interfaces

Code: 
auto lo
iface lo inet loopback

auto vmbr0 
iface vmbr0 inet static
    address        10.73.10.21
    netmask       255.255.0.0
    gateway       10.73.0.1
    bridge-ports  eth0
    bridge_stp    off
    bridge_fd     0

any thing else I can look at?
 
Last edited:
This is not what standard config should be, you are doing something wrong when configuring from web interface OMHO.
Correct lines are:
Code: 
# network interface settings
auto lo
iface lo inet loopback

iface eth0 inet manual

auto vmbr0
iface vmbr0 inet static
        address  192.168.1.9
        netmask  255.255.255.0
        gateway  192.168.1.253
        bridge_ports eth0
        bridge_stp off
        bridge_fd 0
You can directly modify the /etc/network/interfaces and will see the related configuration in web interface (I think after a restart), so you then have an idea about how set correctly from web interface too.
Please check and report back.
 
I never saw such errors in PVE, yet I got those when I played with manually creating bridge interfaces on my home PC. For me that happened because I had two physical interfaces with the same MAC, running in the same broadcast domain (i.e. eth0 and eth1 have the same MAC and are connected to the same switch)

Ensure that you do not have a device with the same MAC in your network (happens pretty often with cheapo chinese adapters where whole batches have the same MAC)
 
I looked through the arp on the switches and couldn't find a duplicate.
I got this on 2 computers and 3 separate NICs.. something must be up on my network, I have it unplugged, I'll have to isolate it more on Monday.
 
you can also look into what's being sent/received using tcpdump as someone advised above.

This can give you more clues on the real cause of the problem.
 
It is my understanding that the bridge will assume the lowest MAC of all the interfaces attached to it.
So when a VM is started that has a MAC lower than your eth0, vmbr0 could change its mac.
There is a good article explaining this here: http://backreference.org/2010/07/28/linux-bridge-mac-addresses-and-dynamic-ports/

I also found this article http://blog.tinola.com/?e=4 that discusses the MAC address changing on the bridge and how it can cause the sort of problems you are complaining of. From the article:
"
Getting back to those troublesome new machines - they differ in that they have a broadcom chipset, not intel, so their MAC addresses look like this; 84:2b:2b:16:7a:f9 (broadcom), as opposed to 00:1B:21:6F:8D:00 (intel).

So, the bridge takes the MAC address 84:2b:2b:16:7a:f9. As you add virtual machines, you've now got a 50:50 chance that the randomly generated MAC address of the vif will be less than that of the primary physical interface - as 84: is just over half way from 00: to FF: and the MAC addresses for these broadcom chips all start 84:."

I noticed your MAC starts with 68, you have an issue.
My servers have MACs that start with 20 or 00, I do not have this problem.


Maybe the bridge using lowest MAC behaviour is causing your issue?

I wonder if we should explicitly set the MAC on the bridge interface to ensure it does not change when a VM is started/stopped to ensure this problem does not happen.
 
Interesting point!

I've made a test and it looks that the bridge interface honors the hwaddress ehter 00:11:22:33:44:55:66 parameter in /etc/network/interfaces!

Some really low MAC address number can be set there and hopefully it will not allow the bridge to change its MAC.

PS: after setting a different MAC the network stopped working on the PVE host :( good thing I'm running it in a VM!
 
Last edited by a moderator:
I have tried to simply change the mac on the interface by issuing ifconfig eth0 hw ether 00:01:23:45:67:89 - that changed the MAC on both the physical interface and the bridge. However network connectivity was lost. I can arping the PVE IP from the gateway and get responses from the newly sent MAC. The rest just does not work.
Maybe it is related to the fact that PVE is running inside of virtualbox.
 
Hello. I have the same error occurs. I have a complex configuration of the bond / bridge / vlan. Now I get the error after rebooting the node "kernel: vlan301: received packet with own address as source address"
 
it was defiantly something on my network, I had a massive power outage this weekend, and when I got everything back up and running the errors went away, for now..
I am going to keep an eye on it to see if it happens again. And isolate it from there.
 
turns out it was a bad switch on my network.. I isolated the issue to that one switch and even when I disable all the ports I was still getting the issue. I disable the switch and the issue went away.. I have now replaced the switch..

Now that was something I have never expected the issue to be.
 
You must log in or register to reply here.
Top Bottom