12/30/2019 Why do I see "martian source" logs in the messages file ?

- Red Hat Customer Portal

C U S T O M E R (https://access.redhat.com/)
P O R TA L


Why do I see "martian source" logs in the messages

file ?
$ SOLUTION VERIFIED - Updated March 21 2018 at 5:53 AM - English ()

Environment
Red Hat Enterprise Linux (RHEL) all versions
IPv4 networking

Issue
Why do I see martian source in the /var/log/messages file?
Why does the kernel log martian source messages?

kernel: martian source 192.168.0.1 from 192.168.0.255, on dev eth0

kernel: ll header: ff:ff:ff:ff:ff:ff:00:12:34:00:ab:cd:08:00

Resolution
Meaning
A "martian" is a packet received in a network interface, where the packet's source and/or destination
IP address does not make sense.

Some examples of martian packets are:

Source IP is already an address on the system receiving the packet

Source IP is the broadcast address 255.255.255.255
Source IP is the local subnet broadcast address
Source IP is a multicast address
Source IP not a unicast address
Source or destination IP is zero 0.0.0.0

https://access.redhat.com/solutions/25157 1/8
12/30/2019 Why do I see "martian source" logs in the messages file ? - Red Hat Customer Portal

Source or destination IP is a loopback address 127.0.0.0/8 but was not received on the
C U S T O M E R (https://access.redhat.com/)
loopback interfaceP O R TA L 
Source IP received in an unexpected interface

Martian source messages may indicate an issue with the network environment. You may wish to
investigate:

There are no layer 2 loops in the network: if the host sends a packet and then receives a copy
of this packet back from the network, it will be logged as a martian
There are no hosts transmitting traffic with a source IP which should not be used such as a
multicast or broadcast IP
The network addressing on all systems in the subnet is applied correctly and is valid, all hosts
should have a valid IP address and the correct subnet mask (aka network prefix)

Reading Messages
A martian source message is laid out as follows:

kernel: martian source <destination IP> from <source IP>, on dev <interface packet arrived on>
kernel: ll header: <destination MAC address>:<source MAC address>:<ethertype> (for ethernet)

For example, given the message:

kernel: martian source 192.168.0.1 from 192.168.0.255, on dev eth0

kernel: ll header: ff:ff:ff:ff:ff:ff:00:12:34:00:ab:cd:08:00

Destination IP: 192.168.0.1

Source IP: 192.168.0.255
Incoming interface: eth0
Destination MAC: ff:ff:ff:ff:ff:ff
Source MAC: 00:12:34:00:ab:cd
Ethertype: 0x0800 (IPv4)

In the above example, the packet is a martian because the network address of the receiver is
192.168.0.1/24 . Given this local address, the address 192.168.0.255 is the subnet broadcast
address and should never used as the source IP address of a packet.

In this situation, it is possible some other host has a larger subnet configured such as
192.168.0.255/23 which is a valid IP address in that larger /23 subnet, or the host has some
process which is sending with an invalid source IP. You could find the source MAC address
00:12:34:00:ab:cd via the network infrastructure and investigate the system with that source MAC.

https://access.redhat.com/solutions/25157 2/8
12/30/2019 Why do I see "martian source" logs in the messages file ? - Red Hat Customer Portal

Configuration C U S T O M E R (https://access.redhat.com/)
P O R TA L

The logging of martians can be controlled with the log_martians parameter as described at:

What is the kernel parameter ipv4.conf.all.log_martians for?

(https://access.redhat.com/solutions/27840)

Root Cause
RFC1812 - Requirements for IP Version 4 Routers, section 5.3.7 Martian Address Filtering
(https://tools.ietf.org/html/rfc1812#section-5.3.7)
Martian packet - Wikipedia (https://en.wikipedia.org/wiki/Martian_packet)

Diagnostic Steps
RHEL 7 kernel source:

net/ipv4/route.c

static void ip_handle_martian_source(struct net_device *dev,

struct in_device *in_dev,
struct sk_buff *skb,
__be32 daddr,
__be32 saddr)
{
RT_CACHE_STAT_INC(in_martian_src);
#ifdef CONFIG_IP_ROUTE_VERBOSE
if (IN_DEV_LOG_MARTIANS(in_dev) && net_ratelimit()) {
/*
* RFC1812 recommendation, if source is martian,
* the only hint is MAC header.
*/
pr_warn("martian source %pI4 from %pI4, on dev %s\n",
&daddr, &saddr, dev->name);
if (dev->hard_header_len && skb_mac_header_was_set(skb)) {
print_hex_dump(KERN_WARNING, "ll header: ",
DUMP_PREFIX_OFFSET, 16, 1,
skb_mac_header(skb),
dev->hard_header_len, true);
}
}
#endif
}

RHEL 6 kernel source:


https://access.redhat.com/solutions/25157 3/8
12/30/2019 Why do I see "martian source" logs in the messages file ? - Red Hat Customer Portal

net/ipv4/route.c C U S T O M E R (https://access.redhat.com/)
P O R TA L

static void ip_handle_martian_source(struct net_device *dev,
struct in_device *in_dev,
struct sk_buff *skb,
__be32 daddr,
__be32 saddr)
{
RT_CACHE_STAT_INC(in_martian_src);
#ifdef CONFIG_IP_ROUTE_VERBOSE
if (IN_DEV_LOG_MARTIANS(in_dev) && net_ratelimit()) {
/*
* RFC1812 recommendation, if source is martian,
* the only hint is MAC header.
*/
printk(KERN_WARNING "martian source %pI4 from %pI4, on dev %s\n",
&daddr, &saddr, dev->name);
if (dev->hard_header_len && skb_mac_header_was_set(skb)) {
int i;
const unsigned char *p = skb_mac_header(skb);
printk(KERN_WARNING "ll header: ");
for (i = 0; i < dev->hard_header_len; i++, p++) {
printk("%02x", *p);
if (i < (dev->hard_header_len - 1))
printk(":");
}
printk("\n");
}
}
#endif
}

RHEL 5 kernel source:


https://access.redhat.com/solutions/25157 4/8
12/30/2019 Why do I see "martian source" logs in the messages file ? - Red Hat Customer Portal

net/ipv4/route.c C U S T O M E R (https://access.redhat.com/)
P O R TA L

static void ip_handle_martian_source(struct net_device *dev,
struct in_device *in_dev,
struct sk_buff *skb,
u32 daddr,
u32 saddr)
{
RT_CACHE_STAT_INC(in_martian_src);
#ifdef CONFIG_IP_ROUTE_VERBOSE
if (IN_DEV_LOG_MARTIANS(in_dev) && net_ratelimit()) {
/*
* RFC1812 recommendation, if source is martian,
* the only hint is MAC header.
*/
printk(KERN_WARNING "martian source %u.%u.%u.%u from "
"%u.%u.%u.%u, on dev %s\n",
NIPQUAD(daddr), NIPQUAD(saddr), dev->name);
if (dev->hard_header_len && skb->mac.raw) {
int i;
unsigned char *p = skb->mac.raw;
printk(KERN_WARNING "ll header: ");
for (i = 0; i < dev->hard_header_len; i++, p++) {
printk("%02x", *p);
if (i < (dev->hard_header_len - 1))
printk(":");
}
printk("\n");
}
}
#endif
}

Product(s) Red Hat Enterprise Linux (/taxonomy/products/red-hat-enterprise-linux)

Component kernel (/components/kernel) Category Learn more (/category/learn-more)

Tags network (/tags/network) networking (/tags/networking) network_stack (/tags/network_stack)

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions
that Red Hat engineers have created while supporting our customers. To give you the knowledge
you need the instant it becomes available, these articles may be presented in a raw and unedited
form.


https://access.redhat.com/solutions/25157 5/8
12/30/2019 Why do I see "martian source" logs in the messages file ? - Red Hat Customer Portal

People who viewed this solution also viewed

(https://access.redhat.com/)
C U STO M E R
P O R TA L

martian source messages caused by F5 network devices with "Unicast Solicit" on

Solution - Apr 8, 2014

How can the system be enabled to accept packets with local source addresses?

Solution - Mar 18, 2014

Martian packages are logged on compute nodes

Solution - Nov 23, 2019

4 Comments
20 March 2018 2:45 PM (https://access.redhat.com/solutions/25157#comment-1285951)
CW Chad Wilson (/user/14917291)
(/user/14917291)
What about the exact the source and destination are swapped? I am getting spams of
COMMUNITY messages like:
MEMBER

25 Points
martian source 1.2.3.255 from 1.2.3.5, on dev eth1
ll header: ff:ff:ff:ff:ff:ff:00:aa:bb:cc:dd:ee:08:00

Wouldn't this imply that the source is some host on the network, and the destination is
broadcast? When can the broadcast address be used, as src or dst?

≤ Reply (/Ajax_comments/Reply/25157/1285951)

21 March 2018 1:51 AM (https://access.redhat.com/solutions/25157#comment-1286201) 

https://access.redhat.com/solutions/25157 6/8
12/30/2019 Why do I see "martian source" logs in the messages file ? - Red Hat Customer Portal

Jamie Bainbridge (/user/13243)

C U S T O M E R (https://access.redhat.com/)
Hi Chad, I've
P Orestructured
R TA L

this solution to show more detail and explanations, including
(/user/13243)code references.
RED HAT

GURU
The ll header is just a dump of the L2 Ethernet header octets directly, and as you can
8387 see (https://en.wikipedia.org/wiki/Ethernet_frame) the destination MAC comes first.
Points
In that message you show, the destination MAC of the broadcast address
ff:ff:ff:ff:ff:ff is valid, that instructs the network switch "send to all hosts in this
broadcast domain".

The problem will likely be the IP address. If your local system is 1.2.3.x/24 then
destination 1.2.3.255 is the broadcast IP which is a valid destination. That doesn't
cause martian source messages for me. You're welcome to open a support case to
review the configuration if you'd like us to investigate further.

≤ Reply (/Ajax_comments/Reply/25157/1286201)

21 March 2018 1:40 PM (https://access.redhat.com/solutions/25157#comment-1286291)

CW Chad Wilson (/user/14917291)
(/user/14917291)
On this server, there are two interfaces (eth0 and eth1) assigned to the same
COMMUNITY subnet/vlan. Could that be the reason for the messages? Is it possible that, even
MEMBER
though IP forwarding isn't enabled, traffic bound for one interface was being routed out
25 Points
the other? (EDIT: actually traffic was not being forwarded, it was simply not
responding)

A strange thing was happening where TCP handshakes were not happening on one of
the two interfaces on that network. It would receive SYN but never respond with
SYN/ACK. I ended up moving the IP to a virtual interface on eth0 and the
communications were restored.

The only thing that was odd about the server was the spamming of martain source
messages. This system had been working for years.

EDIT: The pasted source is good for clarifying the odd syntax of the kern msg (soruce
and dest being reversed). It would be interesting to me to see what triggered the event.
I guess I could crawl through the source myself. I imagine it would be a fairly complex
decision.

≤ Reply (/Ajax_comments/Reply/25157/1286291)

https://access.redhat.com/solutions/25157 7/8
12/30/2019 Why do I see "martian source" logs in the messages file ? - Red Hat Customer Portal

21 March 2018 10:53 PM (https://access.redhat.com/solutions/25157#comment-1286401)

C U S T O M E R (https://access.redhat.com/)
Jamie Bainbridge
P O R TA L(/user/13243)

(/user/13243)Yes, that could be a possible reason. We generally suggest to avoid configuring two IPs
RED HAT
in the same subnet on separate interfaces. There are some extra tunables and config
GURU
required to use each interface if that's being done
8387
(https://access.redhat.com/solutions/30564
Points
(https://access.redhat.com/solutions/30564)). Right now you'll probably find all traffic
is leaving via one interface regardless of where it comes in. If you have Reverse Path
Filtering (https://access.redhat.com/site/solutions/53031) enabled you could be
dropping traffic in the wrong interface too.

I would just do what you said, move all the IPs onto a single interface. Much simpler,
which means easier and cheaper to administer and support. If more than one physical
interface is needed for load balancing and redundancy, then use bonding.

≤ Reply (/Ajax_comments/Reply/25157/1286401)

All systems operational (https://status.redhat.com)

Privacy Statement (http://www.redhat.com/en/about/privacy-

policy)
Customer Portal Terms of Use
(https://access.redhat.com/help/terms/)
All Policies and Guidelines
(http://www.redhat.com/en/about/all-policies-guidelines)
Copyright © 2019 Red Hat, Inc.


https://access.redhat.com/solutions/25157 8/8