Novell is now a part of Micro Focus

My Favorites

Close

Please to see your favorites.

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 12
SUSE Linux Enterprise Server 11
SUSE Linux Enterprise Desktop 11
SUSE Linux Enterprise Desktop 10
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"

Internal Notes

made internal pending tid feedback review:

*Document ID#
   3923798

*Did this document resolve your technical question/issue to your satisfaction?
   Yes

Please enter any comments/feedback about this document.
   a couple of things may have changed along the way with the redirect instructions. 
   I tried to set up redirecting the Martions on an OES11.2/SLES11.3 system and spotted some things that didn't match in that section
   
   - there is no /etc/syslog-ng/sysconfig.conf, but there is a /etc/syslog-ng/syslog-ng.conf that matches the description
   - There is no "SuSEconfigure --module syslog-ng", thought there is a "SuSEconfig --module syslog-ng" that reports "Module syslog-ng does not exist. 
It appears this command isn't even needed
   - the exclude be appears to be best for f_messages, not f_console
   - there are a few typos in the filter, here is what I added beyond the exclude bit
   #
   # Martian Source warning collection point
   #
   filter f_martian {match ("martian source") or match ("ll header:"); };
   destination martian { file("/var/log/martian"); };
   log { source(src); filter(f_martian); destination(martian); };

Change Log

10 Jun 2016 sperrin added SLES 12

Disclaimer

This Support Knowledgebase provides a valuable tool for NetIQ/Novell/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.

  • Document ID:3923798
  • Creation Date:13-OCT-07
  • Modified Date:10-JUN-16
    • SUSESUSE Linux Enterprise Desktop
      SUSE Linux Enterprise Server

Did this document solve your problem? Provide Feedback