Introduction
Martian log messages seen in AW+ switches log files and show tech files have caused many customer's inquires to the Allied Telesis TAC on "What do these messages mean?" or "What is wrong with my network?". The goal of this document is to help the reader understand what a martian packet/log is along with how to correctly read the log messages associated with the presents of martian packets.
What is a Martian Log/Packet
A Martian packet is an IP packet seen on the network that contains a source or destination address that is reserved for special-use by IANA (Internet Assigned Number Authority). On the network, such a packet either has a spoofed source address and it cannot actually originate as claimed, or the packet cannot be delivered.
Source addresses that are illegal include any address within the following ranges:
- 0.0.0.0/8 (Except 0.0.0.0/32 as a Source Address) — Addresses in this block refer to source hosts on this network.
- 127.0.0.0/8 — Used as the Internet host loopback address.
- 192.0.2.0/24 — Used as the TEST-NET in documentation and example codes.
- 224.0.0.0/4 (As a Source IP Address) — Used in IPv4 Multicast address assignments, and This formerly known as Class D Address Space.
- 240.0.0.0/4 (Except 255.255.255.255/32 as a Destination Address) — Reserved address range, and is formerly known as Class E Address Space.
Martian Logs Source and Destination meaning in AW+ logs:
- A packet has a “Martian source” when the source address is an IP or MAC address that should not be possible (i.e. illegal) on the interface where it is received.
- Meanwhile a “Martian Destination” would be a packet with either a destination IP or MAC address that again should not be possible on the interface where it is sent.
Overall, Any martian packet notice should be investigated as these martian packets:
- Are frequently used in hacking intrusion.
- May be a symptom of a misconfigured server elsewhere on the network
- May indicate a network infrastructure issue
Interpreting Martian Log Messages
When a martian packet is received, a message is logged containing the source and destination IP and MAC addresses. The format is a little cryptic and is explained in more detail below.
2019 Dec 4 14:49:16 kern.warning awplus kernel:martian source 160.166.96.144 from 160.166.96.5, on dev vlan13
2019 Dec 4 14:49:16 kern.warning awplus kernel:ll header: ff:ff:ff:ff:ff:ff:00:0e:6a:9c:a5:26:08:06
Two log messages are logged. The first is the IP Header containing IP Destination, Source, and Received VLAN. The second log is the layer 2 Header, containing the MAC Destination address, MAC Source Address, and ethertype code.
Despite the way it reads, the first address is the destination! Below is a key to help understand the correct way to read these type log messages:
Destination IP and MAC address
Source IP and MAC address
Interface where the packet was received
Ethertype of received packet - 0x8100 = 802.1Q Tagged packet, 0x806 = Arp packet
Example Scenarios that would Generate Martian Logs
Below are three sample scenarios that would generate martian logs on AW+ switches.
- Host in VLAN 1 with same IP address as switch interface
- Host in VLAN 1 with same IP address as switch interface on VLAN 2
- Host sending packets to invalid address
Host in VLAN 1 with same IP address as switch interface
Setup: (Switch)----VLAN1-------Host
Switch VLAN1 IP address - 192.168.1.1
As soon as the Host is configured with the same IP as the switch, the messages below are seen in the logs.
03:47:57 awplus kernel: martian source 192.168.1.255 from 192.168.1.1, on dev vlan1
03:47:57 awplus kernel: ll header: ff:ff:ff:ff:ff:ff:28:d2:44:33:c4:2f:08:00
So from these log messages, we can see the host is sending a broadcast packet and the switch sees the source address of 192.168.1.1 is the same as it's own IP address.
Host in VLAN 1 with same IP address as switch interface on VLAN 2
Setup:(Switch)----VLAN1----HOST
Switch VLAN1 IP address - 192.168.1.1
Switch VLAN2 IP address - 192.168.2.1
So now we can see the host is still connected to the switch on VLAN 1, but the host's IP address was changed to the same IP address as the switch's VLAN2 interface from the log below:
03:54:49 awplus kernel: martian source 255.255.255.255 from 192.168.2.1, on dev vlan1
03:54:49 awplus kernel: ll header: ff:ff:ff:ff:ff:ff:28:d2:44:33:c4:2f:08:00
So this example shows that regardless of the interface the packet is received on, if the host or the source IP address in the packet is the same as an interface on the switch, a Martian will be generated.
Hosts Sending Packets to an Invalid Address
Below is a example from a show tech with a host sending packets to an invalid address.
2020 Mar 19 12:18:33 kern.warning awplus kernel: martian destination 0.0.0.0 from 192.168.121.71, dev vlan20
2020 Mar 19 12:18:39 kern.warning awplus kernel: martian destination 0.0.0.0 from 192.168.121.71, dev vlan80
2020 Mar 19 12:18:46 kern.warning awplus kernel: martian destination 0.0.0.0 from 192.168.121.41, dev vlan20
2020 Mar 19 12:18:46 kern.warning awplus kernel: martian destination 0.0.0.0 from 192.168.121.41, dev vlan80
You can take these logs a step further using TCPdump on the switch to see more information about these packets.
12:50:21.468456 00:22:80:00:63:0c (oui Unknown) > Broadcast, ethertype IPv4 (0x0800), length 90: (tos 0x0, ttl 255, id 48639, offset 0, flags [none], proto UDP (17), length 76)
192.168.121.41.4097 > 0.0.0.0.ntp: [udp sum ok] NTPv4, length 48
Client, Leap indicator: (0), Stratum 0 (unspecified), poll 0 (1s), precision 0
Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
Reference Timestamp: 0.000000000
Originator Timestamp: 0.000000000
Receive Timestamp: 0.000000000
Transmit Timestamp: 0.000000000
Originator - Receive Timestamp: 0.000000000
Originator - Transmit Timestamp: 0.000000000
This additional information show the source of this martian logs MAC address (A2B Electronics AB device). If you was troubleshooting this issue, you would investigate to stop this device from sending these bogus NTP messages which is filling up the logs on the switch.
For this case, this device has NTP enabled with no other information. Disabling NTP on this device addressed this issue.