Martian sources errors showing in messages log

This document (3923798) is provided subject to the disclaimer at the end of this document.

Environment

SUSE Linux Enterprise Server 15
SUSE Linux Enterprise Server 12

SUSE Linux Enterprise Server 11

SUSE Linux Enterprise Server 10

SUSE Linux Enterprise Server 9

SUSE Linux Enterprise Server 8 Support Pack 4

Situation

Kernel messages such as

Sep  6 21:30:58 suse kernel: martian source 192.168.1.255 from 192.168.1.251, on dev eth3
Sep  6 21:30:58 suse kernel: ll header: ff:ff:ff:ff:ff:ff:00:18:f8:0e:81:93:08:00
Sep  6 21:31:31 suse kernel: martian source 192.168.1.10 from 192.168.1.251, on dev eth3
Sep  6 21:31:31 suse kernel: ll header: ff:ff:ff:ff:ff:ff:00:18:f8:0e:81:93:08:06
Sep  6 21:36:42 suse kernel: martian source 192.168.1.10 from 192.168.1.50, on dev eth3
Sep  6 21:36:42 suse kernel: ll header: ff:ff:ff:ff:ff:ff:00:08:02:8c:aa:47:08:06
Sep  6 21:36:44 suse kernel: martian source 192.168.1.255 from 192.168.1.50, on dev eth3
Sep  6 21:36:44 suse kernel: ll header: ff:ff:ff:ff:ff:ff:00:08:02:8c:aa:47:08:00

appear in /var/log/messages.

Resolution

A martian header source is usually a IP address that should not be routable. For example, a 127.0.0.0/8 IP address coming through a router, would be labeled as being martian. Other sources of martian sources would be a computer that is trying to use a class E address. Other causes may include network topology.

As Defined by RFC 1812

RFC 1812defines what a martian source would be. From the RFC:

"An IP source address is invalid if it is a special IP address, as defined in 4.2.2.11 or 5.3.7, or is not a unicast address.

"An IP destination address is invalid if it is among those defined as illegal destinations in 4.2.3.1, or is a Class E address (except 255.255.255.255).

"A router SHOULD NOT forward any packet that has an invalid IP source address or a source address on network 0. A router SHOULD NOT forward, except over a loop-back interface, any packet that has a source address on network 127. A router MAY have a switch that allows the network manager to disable these checks. If such a switch is provided, it MUST default to performing the checks.

"A router SHOULD NOT forward any packet that has an invalid IP destination address or a destination address on network 0. A router SHOULD NOT forward, except over a loop-back interface, any packet that has a destination address on network 127. A router MAY have a switch that allows the network manager to disable these checks. If such a switch is provided, it MUST default to performing the checks.

"If a router discards a packet because of these rules, it SHOULD log at least the IP source address, the IP destination address, and, if the problem was with the source address, the physical interface onwhich the packet was received and the link Layer address of the hostor router from which the packet was received."

Another Consideration: Network Topography

Much of the problems experienced with martian source is caused by network topography considerations. The following may need to be addressed:

Router: The router may be routing through illegal addresses; make sure that the router is configured correctly.
Multiple NICS: If a computer has multiple NIC cards plugged in to the same switch, then it martian sources may be shown (this is the most common cause).
Firewall: Is there a firewall allowing inappropriate traffic in?
IP addresses: Are you using multicast or Class E network addresses?
Other computers: Are other servers or workstations MAC addresses responsible?

Potential Solutions

Multiple NICs on the same subnet:Multiple NICs on the same subnet is the most common cause. If you must have multiple NICs on the same subnet, use a managed switch. This can be tested by off-lining all but one NIC cards; if the messages go away, then you can assume that the multiple NICs are the cause. Another solution would be to bond the NICs together. Generally speaking a properly configured network should not require multiple NICs to be on the same subnet, except in the case of bonding.

Turn off logging to the kernel:If you are able to determine that the martian sources are not related to a security issue, then you may turn off martian source logging. Please note, you must make sure that you are sure that the network is secure and that the source of these messages are not from the router.

In /etc/sysconfig/sysctl add "net.ipv4.conf..log_martians=0"
Make sure that "sysctl" is set to run on boot by "chkconfig boot.sysctl on"

Redirect Martian Logging: Another solution is to move the logging from /var/log/messages. This can be done in the syslog.

Add "filter f_martian { match('^martian source'); };" to /etc/syslog-ng/sysconfig.conf
In the filter destinations, find "filter f_console" and add"and not filter(f_martian)" For example:
filter f_console { level(warn) and facility(kern) and not filter(f_iptables)
or level(err) and not facility(authpriv) and not filter(f_martian); };
Add the following: destination martian { file("/var/log/martian"); };
log { source(src); filter (f_martian); destination(martian); };
Run "SuSEconfigure --module syslog-ng"
Restart syslog, "rcsyslog restart"

Disclaimer

This Support Knowledgebase provides a valuable tool for SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented "AS IS" WITHOUT WARRANTY OF ANY KIND.