6.4 Martian Routes and Route Acceptance
Key Takeaways
Martian controls concern destination routes; they are not an automatic firewall for every packet with a suspicious source address.
Inspect show route martians and the correct routing table before diagnosing a missing route as a peer-policy failure.
A routing-options martians prefix and qualifier can change route acceptance; allow is an explicit exception, not creation of a route.
Private IPv4 address space is legitimate inside enterprise networks; Internet-edge filtering depends on routing context.
What Makes a Route Martian?
A martian route has a destination prefix that the routing system treats as invalid or inappropriate for ordinary routing. The term concerns route acceptance, rather than an extraterrestrial host or a special tunneling protocol. Junos has default martian ranges and permits administrator configuration for the relevant RIB. The important operational question is whether the exact prefix and mask in an advertisement are excluded in that table.
Do not memorize every special-purpose address as “always unroutable everywhere.” Loopback, multicast, unspecified and reserved ranges have distinct purposes, and exceptions can be relevant in special designs. Likewise, RFC 1918 private space is ordinary routed enterprise addressing. A route for 10.40.0.0/16 is not inherently a martian merely because it is not public Internet space. An Internet-edge policy may reject private destinations for a different reason from the local RIB’s default martian controls.
Keep Three Decisions Separate
A missing route can result from several independent stages:
| Stage | Question to ask |
|---|---|
| Protocol receipt | Did the peer actually advertise the intended prefix and mask? |
| Route acceptance | Did martian rules or import policy reject it? |
| Route selection and resolution | Is it usable, and did it beat another route for the same prefix? |
| Packet forwarding | Is the active route installed, its next hop resolved and the packet permitted? |
A martian exception addresses the acceptance stage. It does not make a next hop reachable, raise Local Preference, attach a firewall permit or force a route to become active. Conversely, an input packet filter can drop data even when every route is legitimate and active. Diagnose the stage before editing configuration.
Inspect the Existing Rules First
Start with show route martians and the applicable instance/table context. Compare the advertised destination against the rule’s prefix and qualifier. A match on exact includes only that prefix length, whereas orlonger also includes contained more-specific routes. A broad range and a narrow exception must be read together; looking only at the address portion can produce the wrong conclusion.
Inspect the actual route with show route <prefix> exact detail and, when relevant, the hidden-route view. Compare a BGP received-route view with the local RIB. The absence of an active route is not enough to infer martian rejection: a policy reject, unresolved next hop or competing static route can have a similar visible symptom. The diagnostic explanation should identify the rule or hidden reason supporting the conclusion.
Narrowly Scoped Configuration
Junos places the controls under routing-options martians, with corresponding per-instance and per-RIB contexts. The documented allow action permits a subset of a disallowed address range. The following syntax illustrates an exception shape; the placeholder is not a suggested destination to deploy:
[edit]
set routing-options martians <destination-prefix> exact allow
Substitute only a destination justified by the network design and verified against existing rules. A bare prefix/qualifier without allow identifies a disallowed destination set. There is no need to invent a then accept routing-policy term inside this hierarchy. Commit validation confirms supported syntax, while the route view confirms the operational effect.
An allow entry does not originate the destination. If the peer withdraws the route, adding an exception cannot restore the advertisement. If the route is accepted but hidden because its next hop is unresolved, repair resolution. If it loses to a lower-preference route for the same prefix, inspect route preference. These are separate remedies even when the user-facing symptom is “destination unreachable.”
Worked Troubleshooting Scenarios
An engineer adds an explicit exception to the default table, but the peer belongs to a virtual-router instance named LAB. The engineer then inspects only inet.0 and concludes the exception failed. The first correction is to inspect LAB.inet.0, the instance’s routing options and the peer’s actual RIB context. A change in the default instance does not establish the intended per-instance policy.
In a second case, an accepted laboratory destination is still blocked on a WAN input filter. Repeating the martian exception will not fix this. Walk a packet through the input filter, selected RIB, next-hop resolution and egress behavior. If the requirement is to block spoofed source packets, use supported interface source validation or packet filtering as appropriate; destination-route martian controls do not provide that source enforcement automatically.
A final common mistake is changing an exact exception to orlonger merely to make one more-specific route work. That broadens the permitted destination set. Read the actual mask requirement and use the narrowest justified exception, then verify both the intended route and a nearby route that should remain excluded. This comparison demonstrates understanding of prefix scope rather than success by removing every restriction.
Official references checked 2026-10-18: martians syntax and supported contexts and protocol-independent routing documentation.
An administrator adds a martian allow exception but no route to that destination exists. What does the exception do?
Creates a static route with preference 5
Allows the destination past the applicable martian check if a route is learned or configured
Installs a packet-source permit on every interface
Forces every more-specific prefix into BGP export
Sections you finish are checked off in the contents.