7/25/2016

DocumentDisplay

HowtointerpretLinuxmartiansourcemessages(DocID2155365.1)
InthisDocument
Goal
Solution

Example1Howtointerpretthemartiansourcemessage

Example2Invalidbroadcast

Example3ReversePathFiltering

References

APPLIESTO:
LinuxOSVersionOracleLinux6.0andlater
Informationinthisdocumentappliestoanyplatform.

GOAL
DocID1496139.1explainedwhatismartiansource.
Inthisarticlewewillillustratehowtointerpretmartiansourcemessageswithsomerealworldexamples.

SOLUTION
Example1Howtointerpretthemartiansourcemessage
Let'susetheexampleinDocID1496139.1:
Aug2211:08:21serverkernel:martiansource192.168.12.197from192.168.12.198,ondevbondib0

Aug2211:08:21serverkernel:llheader:
08:00:00:00:45:00:01:00:00:00:40:00:40:11:9f:11:c0:a8:0c:c6:c0:a8:0c:c5

Itmeansthattheserverreceiveapacketontheinterfacebondib0,thesourceofthepacket(sender)was192.168.12.198,and
thedestinationofthepacket(recipient)was192.168.12.197.
Howeverwithoutadditionalinformation,wedonotknowwhythepacketwasreportedasmartianpacket.

Example2Invalidbroadcast
May2203:40:37example2kernel:IPv4:martiansource255.255.255.255from10.140.249.4,ondeveth1

May2203:40:37example2kernel:llheader:00000000:ffffffffffff005056ad59090800
.......PV.Y...

Hereeth1receivedabroadcastpacketfromthesender10.140.249.4,andtherecipient255.255.255.255isalimited
broadcast,
thetargetaudienceareallhostsin'localnetwork'(hereisthe10.140.249.4segmentwithunknownnetmask),andthetraffic
shouldneverbeforwardedbyarouter.
Howeverinthiscasetheeth1havetheIPaddress10.168.252.8/16,itwasnotthesamenetworkasthesender10.140.249.4.
Soit'snotexpectedtoreceivesuchbroadcastpacketfromthissender,andthepacketwasrejectedasmartiansource.
Suchissuecanbecausedbyamisconfiguredrouter.

Example3ReversePathFiltering
https://support.oracle.com/epmos/faces/SearchDocDisplay?_adf.ctrlstate=xnntxpj0b_9#aref_section23

1/2

7/25/2016

DocumentDisplay

May2516:46:04example3kernel:martiansource10.255.16.101from10.255.1.140,ondeveth0

May2516:46:04example3kernel:llheader:00:10:e0:3b:1b:8a:00:1f:27:3f:34:00:08:00

Hereonexample3,eth0receivedapacketfrom10.255.1.140,andtherecipientis10.255.16.101.
Tounderstandwhyitwasrejected,wemustinspectthenetworkconfigurationofthe2hosts,asillustratedbelow:

Theserverexample3have2interfaceeth0(10.255.16.101),andbond0(10.255.1.101),theywereconnectedtoL3Switchand
L2Switch,separately.
TheL3swtichconnectedto2networksegments:10.255.16.0/24,and10.255.1.0/24.
TheSenderwasdirectlyconnectedtotheL2Switch,andtheL2switchwasconnectedwithL3Switch.
Herethesendertotriedtoreachtheeth0onexample3,thepacketwillgothroughtheL2SwitchandL3Switchandreachthe
destination10.255.16.101.
Thiswouldbeallowednormally.However,modernLinuxusuallyhaveReversePathFilteringenabled:
#sysctla|grepeth0.rp_filter
net.ipv4.conf.eth0.rp_filter=1

Inrestrictmode,kerneltesttheincomingpacketswithRFC3704,iftheinterfaceisnotthebestreversepaththepacketcheck
willfail.
Inthiscase,thesendershouldhavebeenabletoreachtheserverexample3viabond0sincetheywereinthesamesegment.
Thecheckfailedandthepacketwasrejected.
Theeasiestsolutionistoconnectbond0(10.255.1.101)instead.
Ifthatthat'snotfeasibleduetosomespecialreason,eitherdisabletheReservePathfiltering,oruseloosemodeoneth0.
Moredetailsin(DocID1286796.1)

REFERENCES
NOTE:1496139.1WhyDoes"/var/log/messages"ReportMartianPackets
NOTE:1286796.1rp_filterformultipleprivateinterconnectsandLinuxKernel2.6.32+
Didn'tfindwhatyouarelookingfor?

https://support.oracle.com/epmos/faces/SearchDocDisplay?_adf.ctrlstate=xnntxpj0b_9#aref_section23

2/2