Martian Source Messages - Guest OS

[kcs201110141]

Hi All,

I have deployed OVF ( CentOS VM image) on ESXi 4.1 server host but found the following martian source messages on CentOS guest OS console after booting completed.

Following messeges keep flooding on VM console and log files also:

..

Martian source 255.255.255.255 from <ip 1>, on dev eth0 II header ff:ff:ff:ff:ff:ff:00:1b:42:33:0a:08:00

Martian source 255.255.255.255 from <ip 2>, on dev eth0 ll header ff:ff:ff:ff:ff:ff:00:2b:35:43:0c:08:00

..

Additional info:

While booting up VM, found the following failed message on eth0.

               Determining IP information for eth0 ..... failed.

Appreciate for your help.

[DSTAVERT]

The  definition for martians is something like impossible addresses. You can supress the messages by adding the following to the /etc/sysctl.conf file and rebooting.

   net.ipv4.conf.default.log_martians = 0
   net.ipv4.conf.all.log_martians = 0

As for the dhcp message, do you have a dhcp server in your network? Check the settings for the appliance to see that the nic is connected to the correct network labeled connection.

Anything beyond this I would check with the creator of the appliance.

[kcs201110141]

I tried the following two options:

1. Resolved DHCP issue to get IP address to VM. I am not seeing 'martian source' messages on VM console/log
 files after IP address assigned to the VM through DHCP.
2. Without resolving DHCP issue and disabled martian logs and rebooted and after that i am not seeting all these 'martian source'
messages.  If these messages are informational and harmless then we can disable.
But what if the 'martian source' messages are suspicious(or spoofed)? 
   net.ipv4.conf.default.log_martians = 0
   net.ipv4.conf.all.log_martians = 0

Please let me know if i am missing any network configurations on host or guest os.
 

[AndreTheGiant]

It's a VM with several IP alias?

The martian source is a warning of possible spoofing or packet forging.

But in some case could be normal:

http://www.derkeiler.com/Mailing-Lists/securityfocus/focus-linux/2003-05/0002.html

About the second error, if you make ifconfig eth0 can you see any parameters?

Andre

[kcs201110141]

Following are the eth0 config details for guest OS(VM) : ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:50:12:AE:00:1E
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:343433 errors:0 dropped:0 overrunts:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carries:0
collisions:0 txqueuelen:1000
RX bytes: 43981187..
From the above output, the ip address is not assinged due to dhcp issue. In this case 'martian source' messages
keep flooding to console and log files.But after resolving dhcp issue, the ip address is assinged to VM 
and 'maritan source' messages stopped automatically.
I wanted to stop flooding 'martian' messages even if VM is not getting ip address from dhcp.Because I can assign
static ip address to VM if dynamic ip address is not assigned. 
Please let me know if I can provide more details

[AndreTheGiant]

To stop messages if you are not getting the IP you must work on /proc files in the guest.

Or shutdown the interface without the IP.

Andre

[ParasolTAMU]

This addresses the dhclient part of the question.

A similar problem on another virtualization platform (KVM) seems related to this. In particular, the dhclient dying: in my CentOS 6 based virtualization host, with multiple physical network interfaces, bridges are defined to provide direct (non-NAT ) connectivity from the VM instances to the external network.

It resulted that the server had NetworkManager installed, which is incompatible with network bridges. It kept overwriting the /etc/resolv.conf with is wrong generated version ("mydomain.com" being my actual domain):

[root@myhost]$ cat /etc/resolv.conf

# Generated by NetworkManager

search mydomain.com

  # No nameservers found; try putting DNS servers into your

# ifcfg files in /etc/sysconfig/network-scripts like so:

#

# DNS1=xxx.xxx.xxx.xxx

# DNS2=xxx.xxx.xxx.xxx

# DOMAIN=lab.foo.com bar.foo.com

This caused lot of trouble, although, remarkably, the server continued working well in the LAN, despite losing connectivity to any machine not listed in the hosts file - including the whole internet.

Disabling NetworkManager solved the issue. (a service network restart was needed). This is in fact, the recommended way to work - perform settings manually.

This seems to be unrelated to the martians issue, caused by a setting in the  /etc/sysctl.conf - although this is a recommended policy (to log the martians), they result too often in false positives, flooding the logs.