Martian Source / Martian Packets

One typical side effect is creation of so called "martial packets". A martian packet is an IP packet which specifies a source or destination address that is either reserved for special-use by Internet Assigned Numbers Authority (IANA) or does not belong to the subnet on which this interface exists, and that makes no sense. [RFC 1812]. For example two interfaces are connected to two subnets of 10 network, default router is configured for eth0 and the packet got to eth1

A martian header source is usually a IP address that should not be routable or came from a wrong subnet. For example, a 127.0.0.0/8 IP address coming through a router, would be labeled as being martian. RFC 1812 defines the term a martian source. 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 on which the packet was received and the link Layer address of the hostor router from which the packet was received."

Martian source is network traffic from the wrong subnet appearing on an interface. For example if:

eth0 has IP 192.168.0.1 on subnet 255.255.255.0 
eth1 has IP 192.168.1.1 on subnet 255.255.255.0

This means that eth0 should only see IP traffic from IP addresses from its subnet (192.168.0.x) and eth1 should only see traffic from its subnet (192.168.1.x)

If an IP on the network (say a forgotten printer or something) is still configured with a previous network address (202.167.2.34) and is seen on eth1 it will be seen as martian source.

If one of the machines on the network 192.168.0.x is plugged into the wrong switch and is effectively on the same network segment (physical) as eth1, then you will see martian source from that IP address (or you have multiple networks that the Linux box is not aware of)

Martian source is not a major thing, but it is making you aware of the fact that something in your network setup is either setup incorrectly, or not configured optimally.

We observed strange change of behavior between kernel 2.6.16.60-0.54.5-smp and 2.6.16.60-0.68.1-smp (64-bit):

Previously on old kernel (SLES 10 SP3 2.6.16.60-0.54.5-smp) our eth1 interface (backup segment) was reachable from our workstations. With newer kernel (for example 2.6.16.60-0.68.1-smp on SLES 10 SP3) it is not and "martian source" warnings can be found in the log. For example:

Mar 30 16:19:23 nti247 kernel: printk: 2 messages suppressed. 
Mar 30 16:19:23 nti247 kernel: martian source 10.201.29.247 from 10.194.154.73, on dev eth1
Mar 30 16:19:23 nti247 kernel: ll header: 00:18:8b:30:cd:2f:00:0c:f8:9b:82:0a:08:00

Only SLES server are behaving this way starting from approximately kernel 2.6.16.60-0.68.1-smp on SLES 10 SP3 Red Hat and Solaris servers on the same segment behave "permissively". This behavior is controlled by pretty obscure setting in /etc/sysctl.conf

# Controls source route verification
net.ipv4.conf.default.rp_filter = 1

You can disable it changing the value to zero (please don't forget to run sysctl -p command to make those settings current). 

# Controls source route verification
net.ipv4.conf.default.rp_filter = 0

As of April 2012 this fix works for (patched) SLES 10 SP3, SLES 10 SP4 and SLES 11 SP1. Does not work for SLES 11 SP2.

The reasoning behind the strict ingress filtering that is enabled by net.ipv4.conf.default.rp_filter = 1 setting is protection from spoofing of source address (typical for UDP Distributed Denial of Service Attacks).