Protocol-independent routing: static, aggregate and generated routes

What you will learn. You will learn how a Junos router decides which route to use, and how to create routes that do not depend on any routing protocol: static routes (with backup next hops), aggregate routes (summaries), and generated routes (conditional defaults). You will also learn the small amount of routing policy needed to advertise those routes into OSPF or BGP, and how to prove with the right show command what the router is really doing. These are objectives of JNCIS-ENT (JN0-351 and JN0-352), under protocol-independent routing.

Prerequisites. IP addressing and subnetting, basic Junos CLI (candidate configuration, commit, show route) from JNCIA, and a first idea of OSPF as a protocol that learns routes.

Analogy: a taxi dispatcher's address book

Imagine a taxi dispatcher with several address books. One was written by the manager (static routes), one is updated by drivers calling in (OSPF), and one comes from a partner company (BGP). When a customer asks for a route to a street, the dispatcher looks in all the books. If two books give an answer, the dispatcher trusts one source more than the other: that trust level is the route preference. The dispatcher also has a habit of using the most detailed address: "Rose Street 12" beats "Rose Street" and "Rose Street" beats "the old town". That is longest prefix match. And sometimes the manager writes "everything in the old town goes to the depot" (an aggregate) or "if the airport road is open, send all unknown addresses that way" (a generated route).

Why "protocol-independent"

OSPF and BGP are protocols: they discover and exchange routes automatically. Static, aggregate and generated routes exist purely in the local configuration of one router; no neighbour has to speak any protocol for them to exist. That is what protocol-independent means. They are the glue that holds many real networks together: a branch with one uplink, a default route to an ISP, a summary of a campus, a blackhole for unused address space.

The routers you will use

Lab	Devices	Skill
One summary for the whole campus	SRV, CORE, EDGE, ACC, PC1, PC2	Aggregate route and export policy
A default route that follows the ISP	PC1, R2, R1, ISP, SRV	Generated route, OSPF export, failure test
The branch that took the slow road	PC, BR1, HQ, SRV	Static and floating static, black hole

Module roadmap

1. Route preference and the two tables (chapter 2).
2. Static routes in depth (chapter 3).
3. Aggregate routes (chapter 4) and generated routes (chapter 5).
4. Routing policy to advertise them (chapter 6).
5. Verification commands (chapter 7), troubleshooting (chapter 8) and a final summary (chapter 9).

Two tables, two jobs. A Junos router keeps two tables for IPv4 unicast. The routing table (inet.0) lives on the Routing Engine and holds every route learned from every source, including routes that lose. The forwarding table lives on the Packet Forwarding Engine and holds only the single best next hop per prefix. The Routing Engine decides; the PFE obeys. When you troubleshoot, always ask first which of the two you are looking at.

How the router chooses

For a packet, two decisions happen in this order:

1. Longest prefix match. Among all prefixes that contain the destination, the one with the longest mask wins. A /24 always beats a /16 for an address in both, whatever their preference.
2. Route preference. If several routes exist for the same prefix, the lowest preference is chosen as the active route. If preferences tie, further tie-breakers (metric and protocol rules) apply.

Beginners often reverse these. Preference only chooses among routes to the exact same prefix and length.

Default preference values

Route source	Default preference	Shown as
Directly connected and local	0	Direct, Local
Static	5	Static
OSPF internal	10	OSPF
Aggregate and generated	130	Aggregate
OSPF external	150	OSPF
BGP	170	BGP

These are Junos defaults. Other vendors use different "administrative distance" numbers (for example static 1, OSPF 110), so never carry the numbers from one vendor to another. Directly connected networks always win because they are the most trustworthy source.

Reading a route entry

This real output comes from the branch lab after the primary static route was fixed. Both routes are for 172.30.0.0/16:

lab@BR1> show route 172.30.0.0/16 exact
inet.0: 8 destinations, 9 routes (8 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

172.30.0.0/16      *[Static/5] 00:00:00
                    >  to 10.60.1.2 via ge-0/0/0.0
                    [Static/20] 00:00:40
                    >  to 10.60.2.2 via ge-0/0/1.0

Read it left to right:

• The header says 8 destinations and 9 routes: one destination has two routes. "8 active" means eight are in use.
• * marks the active route. [Static/5] is the protocol and its preference. The time is the age of the route.
• > marks the selected next hop. to 10.60.1.2 via ge-0/0/0.0 is the next-hop address and the outgoing logical interface.
• The second line without a star is the inactive route. It is a ready backup.

Use show route summary to see how many routes each protocol contributes, and show route ... detail for next-hop type, state and age.

lab@BR1> show route summary
Autonomous system number: not configured
Router ID: 10.60.1.1
inet.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)
              Direct:         3 routes,      3 active
              Local:          3 routes,      3 active
              Static:         2 routes,      2 active

Changing preference

You can change preference per route, or for all routes of a source:

set routing-options static route 172.32.0.0/16 next-hop 10.60.1.2 preference 7
set routing-options static defaults preference 8      ! for static routes without their own value

Lowering a protocol's preference makes its routes more trusted. A common design uses a floating static route: a static with a preference higher than the dynamic protocol (for example 200) that becomes active only when the dynamic route disappears. Remember that static default preference 5 beats OSPF's 10, so a static route for the same prefix overrides OSPF unless you change it.

What a static route is. A static route is a line that you write yourself: "to reach this prefix, send packets to that neighbour." It does not change by itself, it is not exchanged with anyone, and it needs no protocol. It is perfect for small, predictable parts of the network: a branch with one uplink, a default route to an ISP, a server subnet behind a firewall. Its weakness is also its strength: it never reacts to failures unless you design the reaction (a backup route).

The basic statement

! under [edit routing-options static]
set routing-options static route 172.30.0.0/16 next-hop 10.60.1.2
set routing-options static route 0.0.0.0/0 next-hop 10.0.1.2          ! default route

The next hop is the IP address of the neighbour router. Junos requires that this address is reachable on a directly connected subnet. If there is no connected network that contains the next hop, the route cannot be made active. On a plain static route Junos does not look up the next hop in other routes (unless you add resolve, described below). In the branch lab the original config used 10.60.1.6 as the primary next hop although the link is 10.60.1.0/30 (hosts .1 and .2): 10.60.1.6 is not on any connected subnet, so the route never became active and traffic fell back to the backup.

Backup next hops

There are two ways to give one prefix more than one next hop.

set routing-options static route 172.30.0.0/16 next-hop 10.60.1.2
set routing-options static route 172.30.0.0/16 qualified-next-hop 10.60.2.2 preference 20

• Two plain next-hop values under the same route form equal-cost next hops: both are active (but see load balancing in the Instances module).
• A qualified-next-hop carries its own preference (and metric). With preference 20 it is a floating backup: inactive while the primary exists, active when it disappears.

The router decides based on whether the next hop is usable. If the primary link goes down, its connected route disappears, the next hop is unreachable, the primary static is withdrawn, and the qualified next hop becomes active. A static route does not know about a failure in the middle of the path; for that, add BFD or use a dynamic protocol.

discard and reject

set routing-options static route 10.99.0.0/16 discard
set routing-options static route 10.98.0.0/16 reject

Action	Packet	Sender gets
discard	silently dropped	nothing
reject	dropped	ICMP destination unreachable

These are null routes. They are useful to blackhole unused address space, to give an aggregate something to summarise, and as a defence in security designs. Real output:

lab@BR1> show route 10.99.1.1
10.99.0.0/16       *[Static/5] 00:00:00
                       Discard

lab@BR1> show route forwarding-table destination 10.99.1.1
Destination        Type RtRef Next hop           Type Index    NhRef Netif
10.99.0.0/16       user     0                    dscd    724     2

The forwarding table type dscd means discard; rjct means reject; ucst means unicast to a next hop.

resolve, metric and other options

• resolve: lets the next hop be found through other routes in the table (recursive lookup) instead of requiring a connected subnet. Needed for next hops reached through a dynamic protocol.
• preference and metric: tune the route against other sources and against other statics. Use static defaults to change them for all static routes.
• no-readvertise: prevents the route from being exported by a protocol policy that matches statics.
• install and retain control whether the route is kept in the forwarding table after a failure; use only when you know why.

Black holes caused by statics

The most common static-route fault is a more specific route that points to the wrong place. Longest prefix match always wins, regardless of preference. In the lab BR1 has 172.30.0.0/16 for HQ but also a forgotten 172.30.5.0/24 with reject:

lab@BR1> show route 172.30.5.10
172.30.5.0/24      *[Static/5] 00:00:40
                       Reject

Even though the /16 exists, packets to the HR server 172.30.5.10 are rejected because the /24 is more specific. Delete the /24 and the /16 handles the traffic again.

The idea. A city has hundreds of streets, but the postal service needs only one line to route mail to the city: "everything in this city goes to the central sorting office". An aggregate route does the same for IP prefixes. Instead of telling the whole network about 10.40.1.0/24, 10.40.2.0/24 and 10.40.255.0/30 separately, you create one summary 10.40.0.0/16. This is also called route summarisation. Fewer routes mean smaller tables, faster convergence and less churn: a change inside the summary does not need to be advertised outside.

How an aggregate behaves

• The more specific routes that fall inside the summary are the contributing routes.
• The aggregate is active only while at least one contributing route is active. If every contributor disappears, the aggregate disappears too. This prevents you from advertising a summary for a network that no longer exists.
• Its default route preference is 130.
• It never forwards packets by itself. The next hop is reject (default) or discard. Packets for a known more specific prefix still follow that more specific route, so the aggregate only catches addresses inside the summary that nobody owns.

Configuration

set routing-options aggregate route 10.40.0.0/16
set routing-options aggregate route 10.40.0.0/16 discard          ! drop silently instead of ICMP
set routing-options aggregate route 10.40.0.0/16 policy ONLY-LANS ! limit which routes may contribute

Verify with the detail view. This is real output from the campus lab (EDGE router):

lab@EDGE> show route 10.40.0.0/16 exact detail
10.40.0.0/16 (1 entry, 1 announced)
        *Aggregate Preference: 130
                Next hop type: Reject
                State: <Active Int Ext>
                Age: 0:00 	Metric: 0
                Contributing Routes (3):
                        10.40.1.0/24 proto Static
                        10.40.2.0/24 proto Static
                        10.40.255.0/30 proto Direct
                Task: RT

The line Contributing Routes (3) is the evidence that the summary is built from three prefixes. Notice that a Direct route also contributes: any active route inside the summary counts, not only statics.

lab@EDGE> show route protocol aggregate
10.40.0.0/16       *[Aggregate/130] 00:00:00, metric 0
                       Reject

After you add discard, the same prefix shows Discard and the forwarding table entry has type dscd:

lab@EDGE> show route forwarding-table destination 10.40.9.9
10.40.0.0/16       user     0                    dscd    500     2
lab@EDGE> show route forwarding-table destination 10.40.1.5
10.40.1.0/24       user     0 10.40.255.2        ucst    756     2 ge-0/0/1.0

10.40.9.9 does not belong to any campus LAN, so it falls into the aggregate and is dropped. 10.40.1.5 belongs to the more specific static route, so it is forwarded normally. This shows that the aggregate never overrides real routes.

Choosing reject or discard

Next hop	Effect for unowned addresses	When
reject (default)	dropped and ICMP unreachable returned	internal networks where fast failure feedback helps
discard	dropped silently	edge or security designs where you do not want to reveal anything

Advertising the aggregate

An aggregate is a local route. Neighbours will not learn it until a policy exports it. In the lab EDGE first exports every static route into OSPF; the core team wants only the summary. The export policy matches protocol aggregate:

set policy-options policy-statement AGG-OUT term 1 from protocol aggregate
set policy-options policy-statement AGG-OUT term 1 from route-filter 10.40.0.0/16 exact
set policy-options policy-statement AGG-OUT term 1 then accept
delete protocols ospf export                       ! remove the old STATICS-OUT export first
set protocols ospf export AGG-OUT
commit

lab@CORE> show route 10.40.0.0/16
10.40.0.0/16       *[OSPF/150] 00:00:25, metric 0
                    >  to 10.0.40.1 via ge-0/0/0.0

CORE learns the /16 as an OSPF external route (preference 150) and no longer sees 10.40.1.0/24 or 10.40.2.0/24. Traffic from the server SRV (172.20.0.10) still reaches the campus PCs: CORE follows the /16 to EDGE, and EDGE still has the more specific static routes toward ACC. Longest match does the rest.

The problem a static default cannot solve. Your Nagpur office router R1 has one link to an ISP. Internal router R2 gets its default route from R1. If you configure a plain static 0.0.0.0/0 on R1 and export it into OSPF, the default exists all the time, even when the ISP is down. R2 keeps sending Internet traffic to R1, and R1 black-holes it. What you want is a default route that exists only while the ISP is really there.

A generated route gives exactly that. It looks like an aggregate: same preference 130, same aggregate protocol name in policies, contributing routes, and it is active only while at least one contributor is active. The difference is that it forwards. It copies the next hop of its primary contributing route, the contributor the router elects as primary (lowest preference first, then the numerically smallest prefix). So if the contributor is a BGP route from the ISP, the generated route points at the ISP.

Aggregate versus generate

	aggregate	generate
Preference	130	130
Active when	one contributor is active	one contributor is active
Next hop	reject or discard	next hop of the primary contributor
Forwards traffic?	no, only catches unowned addresses	yes
Typical use	summarise your own prefixes	conditional default route

Building the conditional default

The policy that selects contributors must be precise. We want only the ISP's service network 203.0.113.0/24, learned by BGP, to count:

set policy-options policy-statement ISP-ALIVE term 1 from protocol bgp
set policy-options policy-statement ISP-ALIVE term 1 from route-filter 203.0.113.0/24 exact
set policy-options policy-statement ISP-ALIVE term 1 then accept
set policy-options policy-statement ISP-ALIVE term 2 then reject
set routing-options generate route 0.0.0.0/0 policy ISP-ALIVE
commit

Term 2 rejects everything else. This is important: without a policy, every more specific route in the table (your own LANs, the OSPF routes) would be a contributor, and the default would stay active even with the ISP down.

Verify with detail. Real output from R1:

lab@R1> show route 0.0.0.0/0 exact detail
0.0.0.0/0 (1 entry, 1 announced)
        *Aggregate Preference: 130
                Next hop type: Router
                Next hop: 100.64.10.2 via ge-0/0/0.0, selected
                State: <Active Int Ext>
                Age: 0:00 	Metric: 0
                Contributing Routes (1):
                        203.0.113.0/24 proto BGP
                Task: RT

Notice Next hop type: Router with the ISP's address 100.64.10.2. A normal aggregate would say Reject. This is the generated route's forwarding ability.

Exporting the default into OSPF

A generated route is local until you export it. It is protocol aggregate in policy:

set policy-options policy-statement DEFAULT-OUT term 1 from protocol aggregate
set policy-options policy-statement DEFAULT-OUT term 1 from route-filter 0.0.0.0/0 exact
set policy-options policy-statement DEFAULT-OUT term 1 then accept
set protocols ospf export DEFAULT-OUT
commit

lab@R2> show route 0.0.0.0/0 exact
0.0.0.0/0          *[OSPF/150] 00:00:25, metric 0
                    >  to 10.50.0.1 via ge-0/0/0.0

R2 learned the default as an OSPF external route. PC1 reaches the ISP server 203.0.113.10 through R2 and R1.

The failure test

Prove it. Deactivate BGP on R1 and commit with a comment, so the change is traceable:

deactivate protocols bgp
commit comment "isp-down-test"

lab@R1# show | compare rollback 1
[edit protocols]
-   bgp {
...
+   inactive: bgp {

lab@R1# run show system commit
0   2026-10-01 22:26:35 UTC by lab via cli
    isp-down-test

lab@R2> show route 0.0.0.0/0 exact
inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)

The BGP route to 203.0.113.0/24 is gone, so the generated route has no contributor and disappears. R1 withdraws the OSPF default and R2 now has zero routes to 0.0.0.0/0. R2 could now fail over to a second exit if there was one. After activate protocols bgp and a commit the session returns to Established and the default returns.

Why policy. Static, aggregate and generated routes exist only on one router. To share them you must tell a routing protocol: "advertise these routes." Junos does this with routing policy. A policy is a small program with a simple shape: for each route that passes by, test some conditions and then decide what to do. You already used one in the previous chapters; here you learn how to read and write them properly.

Analogy: a policy is a mail room filter. Every letter (route) goes past the clerk. The clerk has a list of rules ("letters from the finance department go to the CFO"; "anything else goes to the bin"). The first rule that fits wins. Import policies control what the post office receives into the table; export policies control what it sends out.

Structure of a policy-statement

set policy-options policy-statement NAME term T1 from ...        ! conditions (all must be true)
set policy-options policy-statement NAME term T1 then accept      ! action
set policy-options policy-statement NAME term T2 then reject

• A policy has one or more terms, evaluated in order. The first term whose from conditions are all true applies its then actions.
• A term with no from matches every route.
• accept and reject end the policy. If no term ends it (for example a term that only sets a metric), the router goes to the next term, then to the default policy of the protocol.
• For OSPF and BGP exports, the default policy for routes that match nothing is to reject (OSPF and BGP export only their own protocol's routes by default). That is why a policy that does not mention a route type exports nothing of it.

Match conditions

Condition	Meaning
from protocol aggregate | static | direct | bgp | ospf	the route's source
from route-filter PREFIX MATCH-TYPE	prefix and length test
from interface ge-0/0/1.0	interface the route comes from
from neighbor ADDRESS	the neighbour that advertised it

Route-filter match types

This is a favourite exam topic. For the prefix 10.40.0.0/16:

Type	Matches
exact	only 10.40.0.0/16
orlonger	10.40.0.0/16 and anything more specific inside it (/17, /24, /32 ...)
longer	more specific only, not the /16 itself
upto /24	the /16 down to /24 inclusive
prefix-length-range /20-/24	lengths from 20 to 24 inside the range

When you export an aggregate you nearly always want exact. If you used orlonger the policy would also match the more specific static routes, but only routes whose protocol is aggregate match anyway when you also write from protocol aggregate. Combining conditions narrows the match: all conditions of one term must be true.

Applying the policy

set protocols ospf export AGG-OUT
set protocols bgp group ISP export AGG-OUT         ! same idea for BGP
set protocols ospf export [ P1 P2 ]                ! chain: evaluated left to right

The set protocols ospf export statement adds a policy to the list if you set it again; it does not replace the old one. If an old export (like STATICS-OUT in the campus lab) is still there, both policies run. Use delete protocols ospf export first to start clean. Real output after the change:

lab@EDGE> show configuration policy-options
policy-statement AGG-OUT {
    term 1 {
        from {
            protocol aggregate;
            route-filter 10.40.0.0/16 exact;
        }
        then {
            accept;
        }
    }
}

lab@EDGE> show configuration protocols ospf
area 0.0.0.0 {
    interface ge-0/0/0.0;
    interface lo0.0 {
        passive;
    }
}
export AGG-OUT;

Seeing the result in the neighbour

A route exported into OSPF becomes an external route: an LSA of type 5 (AS external). Its preference on the receiving router is 150. In the campus lab:

lab@CORE> show ospf database external
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Extern   10.40.0.0        10.255.0.1       0x80000001    25  0x22 0x58a9  36

lab@CORE> show route 10.40.0.0/16 detail
10.40.0.0/16 (1 entry, 1 announced)
        *OSPF Preference: 150
                Next hop type: Router
                Next hop: 10.0.40.1 via ge-0/0/0.0, selected
                Task: OSPF

One LSA for the whole summary, advertised by router ID 10.255.0.1 (EDGE). Before the change CORE received one LSA for each campus static route.

Other useful tools: show route advertising-protocol bgp NEIGHBOR for BGP exports, show route protocol ospf for what a neighbour learned, and test policy NAME PREFIX to check which routes in the table a policy accepts. Read its result critically: it lists every route that matches the policy conditions, not just the one you expect.

Why a toolbox. Configuring a route takes one line; proving what the router really does takes the right command. The golden rule of routing troubleshooting is to look at three layers in order: (1) what is configured, (2) what the routing table decided, (3) what the forwarding table will use. A mismatch between the layers tells you where the fault is. This chapter builds your toolbox with real output from the branch router BR1 in its original faulty state (primary next hop mistyped, a reject route for 172.30.5.0/24, a backup static with preference 20).

Command 1: the whole table

lab@BR1> show route terse
A V Destination        P Prf   Metric 1   Metric 2  Next hop        AS path
* ? 10.60.1.0/30       D    0                        >ge-0/0/0.0
* ? 10.60.2.0/30       D    0                        >ge-0/0/1.0
* ? 172.30.0.0/16      S   20                        >10.60.2.2
* ? 192.168.60.0/24    D    0                        >ge-0/0/2.0

The terse view puts one route per line: the star (active), protocol letter (D direct, L local, S static, O OSPF, B BGP, A aggregate), preference, and next hop. Here the /16 is active with preference 20 through 10.60.2.2, the backup. That is your first clue that the primary route never became active.

Command 2: one destination

To ask "what will the router do for this address?" give the address, not a prefix:

lab@BR1> show route 172.30.5.10
172.30.5.0/24      *[Static/5] 00:00:40
                       Reject

The router answers with the longest matching route, the /24, not the /16. That single output explains why the HR server fails. Related options:

Command	Use
show route 172.30.0.0/16 exact	only that exact prefix (all its routes, active and inactive)
show route 172.30.0.0/16 longer	more specific routes inside it, not the prefix itself
show route 172.30.0.0/16 orlonger	the prefix and all more specific routes
show route best 172.30.5.10	the single best route for an address
show route protocol static	routes from one source
show route table inet.0 protocol static	same, naming the table
show route summary	route counts by protocol

lab@BR1> show route 172.30.0.0/16 longer
172.30.5.0/24      *[Static/5] 00:00:40
                       Reject

The longer option found the black hole in one command: a more specific route lurking under the /16. Make this a habit when a covering route exists but a part of it fails.

Command 3: detail

lab@BR1> show route 172.30.0.0/16 exact detail
172.30.0.0/16 (1 entry, 1 announced)
        *Static Preference: 20
                Next hop type: Router
                Next hop: 10.60.2.2 via ge-0/0/1.0, selected
                State: <Active Int Ext>
                Age: 0:40
                Task: RT

"1 entry" is the key: only one route exists for this prefix. In the original design there should be two (primary and backup). Fields to read in detail output: preference, next-hop type (Router, Reject, Discard), the next-hop address, the active state, age and, for aggregates, contributing routes.

Command 4: the forwarding table

lab@BR1> show route forwarding-table destination 172.30.5.10
Destination        Type RtRef Next hop           Type Index    NhRef Netif
172.30.5.0/24      user     0                    rjct    612     2

Next hop Type	Meaning
ucst	unicast to a neighbour (with its address and interface)
rjct	reject (drop and send ICMP)
dscd	discard (drop silently)
rslv	resolve: an attached subnet that must ARP for the host
locl	local address of the router
ulst	unilist: several next hops installed (load balancing)

If the routing table and forwarding table disagree, suspect a platform or policy issue; for ordinary static routes they should match exactly.

Command 5: real packets

lab@BR1> ping 172.30.5.10 count 2
2 packets transmitted, 0 packets received, 100% packet loss

lab@BR1> traceroute 172.30.5.10 no-resolve
 1  * * *

Use ping to test reachability and traceroute to see where packets stop. A reject route would normally return ICMP unreachable; a discard route gives silence. Ping from the router uses the router's own source address, so also test from a host on the LAN (a ping with source lets you simulate this from the router).

The ticket. Branch router BR1 reaches the HQ network 172.30.0.0/16 over a fast primary link with a slow backup as a floating static route. Users complain that HQ is slow and that the HR server 172.30.5.10 is unreachable. Find out which next hop is used, fix the static routes, and restore access to the server over the primary link.

Static-routing faults fall into a handful of patterns. Learn the patterns and the workflow below, and you can solve most tickets in minutes.

A repeatable workflow

1. Reproduce. From the user's PC ping the server and a normal HQ address. Different results mean a specific-route problem; the same failure means a general path problem.
2. Ask the router about the destination. show route DESTINATION (an address, not a prefix).
3. Look at the whole prefix family. show route PREFIX exact and ... longer.
4. Check the next hop. Is it on a connected subnet? Does the interface list show it? show interfaces terse.
5. Fix one thing, commit, and re-verify with the same commands.
6. Test the real path from the host.

Step by step in the lab

Which next hop is used?

lab@BR1> show route 172.30.0.0/16 exact
172.30.0.0/16      *[Static/20] 00:00:40
                    >  to 10.60.2.2 via ge-0/0/1.0

The active route is Static/20: the backup next hop 10.60.2.2 is in use. The slow link explains "HQ is slow". There is no Static/5 line at all, so the primary route is not even in the table. Check the configuration:

lab@BR1> show configuration routing-options
static {
    route 172.30.0.0/16 {
        next-hop 10.60.1.6;
        qualified-next-hop 10.60.2.2 {
            preference 20;
        }
    }
    route 172.30.5.0/24 reject;
}

The primary next hop is 10.60.1.6, but the primary link is 10.60.1.0/30 with BR1 = 10.60.1.1 and HQ = 10.60.1.2. Address .6 is not on any connected subnet, so the route cannot be resolved and never becomes active. Fix it:

delete routing-options static route 172.30.0.0/16 next-hop 10.60.1.6
set routing-options static route 172.30.0.0/16 next-hop 10.60.1.2
commit

lab@BR1> show route 172.30.0.0/16 exact
172.30.0.0/16      *[Static/5] 00:00:00
                    >  to 10.60.1.2 via ge-0/0/0.0
                    [Static/20] 00:00:40
                    >  to 10.60.2.2 via ge-0/0/1.0

Now the primary is active with preference 5 and the backup waits below. The answer to the lab question "what preference does the backup have?" is 20.

Why is the HR server still unreachable? Ask about the address, not the prefix:

lab@BR1> show route 172.30.5.10
172.30.5.0/24      *[Static/5] 00:00:40
                       Reject

A forgotten /24 with reject is more specific than the /16 and wins regardless of preference. Remove it:

delete routing-options static route 172.30.5.0/24
commit and-quit

lab@BR1> show route 172.30.5.10
172.30.0.0/16      *[Static/5] 00:00:00
                    >  to 10.60.1.2 via ge-0/0/0.0
                    [Static/20] 00:00:40
                    >  to 10.60.2.2 via ge-0/0/1.0

PC can now ping 172.30.5.10 over the primary link. Also remember the return path: HQ must have a route to 192.168.60.0/24, and in this lab HQ already has one with its own floating backup.

The fault patterns

Symptom	Typical cause	Check
Route configured, never active	next hop not on a connected subnet; interface down	show route PREFIX exact, show interfaces terse
Traffic uses the backup link	primary route missing or wrong preference	star and preference in show route
One host in a range fails	more specific reject or discard route	show route PREFIX longer
Ping goes out, no reply	no return route at the far end	check the other router
Aggregate not seen by neighbours	no export policy, or policy matches wrong protocol	show configuration protocols ospf
Generated default never disappears	no contributor policy, or a contributor you did not intend	show route 0.0.0.0/0 exact detail
Default disappears but should not	contributor route (BGP) is down	show bgp summary, show route CONTRIBUTOR

Troubleshooting the generated default

In the Nagpur lab, when BGP to the ISP is deactivated, R2 loses the default route. That is the correct, designed behaviour. If you meet the opposite, the default stays after a failure, read the contributing routes line in detail. A contributor that is not the ISP prefix (for example R1's own LAN) means the contributor policy lacks the final term 2 then reject.

lab@R1> show bgp summary
Groups: 1 Peers: 1 Down peers: 0
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
100.64.10.2           64999          4         3       0       0        0:40 Establ
  inet.0: 2/3/3/0

A healthy session says Establ and the counts show how many routes were accepted. A session in Active or Connect state means the ISP routes, and therefore the contributor, are gone.

You have walked from route preference to static, aggregate and generated routes, then export policy, verification and troubleshooting. This last chapter pulls everything into one page you can revise the night before the JN0-351 exam.

The big picture

Junos builds one routing table (inet.0) from many sources. Each source gives its routes a preference; the lowest wins as the active route. The active route is copied to the forwarding table, and packets are forwarded by longest prefix match, which always beats preference. Everything in this module is a variation of those two rules.

Default preference values

Source	Preference
Direct	0
Local	0
Static	5
OSPF internal	10
IS-IS Level 1 internal	15
IS-IS Level 2 internal	18
RIP	100
Aggregate	130
OSPF external	150
BGP (internal and external)	170

Route types at a glance

Type	Purpose	Becomes active when
Static	Manual route to a next hop	next hop is reachable on a connected subnet
Qualified next hop	Floating backup with its own preference	better route is absent
Discard	Silently drop matching traffic	always (it has no next hop to resolve)
Reject	Drop and send ICMP unreachable	always
Aggregate	Summary built from more specific routes	at least one contributing route is active
Generated	Summary with a real forwarding next hop	at least one contributing route is active

Aggregate versus generated

• An aggregate usually points to discard, so traffic for a missing more-specific is dropped. A generated route takes the next hop of its primary contributing route.
• Both exist only while a contributor is active. This is what makes the generated default in the lab vanish when BGP fails.
• Neither is advertised automatically. A routing policy exported into the protocol is needed.

Commands to know cold

show route
show route PREFIX exact
show route PREFIX longer
show route protocol static
show route 0.0.0.0/0 exact detail
show route forwarding-table destination ADDRESS
show configuration routing-options
show interfaces terse
show | compare
commit confirmed 5
commit comment "text"

Exam checklist

• I can list the default preference of direct, static, OSPF, IS-IS, RIP, aggregate and BGP.
• I can explain why a /24 reject route beats a /16 static route.
• I can write a floating static route with qualified-next-hop and a preference value.
• I know the difference between discard and reject.
• I know that a static route with an unreachable next hop is not active.
• I can configure an aggregate and a generated route and read the contributing routes.
• I can write an export policy that advertises them into OSPF and know the resulting route is OSPF/150.
• I can read the star, the plus sign and the minus sign in show route.
• I can use show route and the forwarding table to prove which path a packet takes.
• I can follow the troubleshooting workflow: reproduce, ask about the address, check the prefix family, check the next hop, fix one thing, verify.