Significance of "receive" next-hop static routes in JunOS
Significance of "receive" next-hop static routes in JunOSOne of the many next-hop options for static routes in Junos is the "receive" next-hop.
Based on Juniper manual for static routes:
http://www.juniper.net/techpubs/en_US/junos13.2/topics/reference/configuration-statement/static-edit-routing-options.html,
Quote:
Quote:
receive—Install a route for this next-hop destination into the routing table.
The receive option forces the packet to be sent to the Routing Engine.
The receive option can be useful in the following cases:
For receiving MPLS packets destined to a VRF instance's loopback address
For receiving packets on a link's subnet address, with zeros in the host portion of the
address
I will show a practical example on what a "receive" next-hop implies for static routes in
Junos:
Code:
+-------+ +-------+
| | | |
| R1 +---------------------+ R2 |
| | | |
+---+---+ +---+---+
| |.1
| |
| |
| |
| |10.42.7.0/24
| |
| |
| |
| |.2
+---+---+ +---+---+
| | | |
| R3 +---------------------+ R4 |
| |.1 10.42.25.0/24 .2| |
+-------+ +-------+
In the above diagram, R4 uses two static routes 10.10.10/24 and 20.20.20/24 with "receive"
next hop.
Code:
[edit]
admin@R4# show routing-options static
route 10.10.10.0/24 receive;
route 20.20.20.0/24 receive;
After injecting/exporting these routes into the IGP, let's see them from R1 (default metrics,
1Gbps links everywhere):
Code:
admin@R1> show route 10.10.10/24
inet.0: 26 destinations, 27 routes (26 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.10.10.0/24 *[OSPF/150] 00:22:57, metric 0, tag 0
to 10.42.4.1 via ge-0/0/7.0
> to 10.42.6.1 via ge-0/0/8.0
admin@R1> show route 20.20.20/24
inet.0: 26 destinations, 27 routes (26 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
20.20.20.0/24 *[OSPF/150] 00:23:02, metric 0, tag 0
> to 10.42.4.1 via ge-0/0/7.0
to 10.42.6.1 via ge-0/0/8.0
This means that R4 injects them into OSPF and sends the type 5 lsa via both paths: R3 and R2.
R1 sees two equal costs paths towards these two destinations. Load balancing is not really
performed, although it looks like so. Junos default behavior.
Code:
admin@R1> ping 10.10.10.1 count 1
PING 10.10.10.1 (10.10.10.1): 56 data bytes
64 bytes from 10.42.25.2: icmp_seq=0 ttl=63 time=10.364 ms
--- 10.10.10.1 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 10.364/10.364/10.364/0.000 ms
admin@R1> ping 20.20.20.54 count 1
PING 20.20.20.54 (20.20.20.54): 56 data bytes
64 bytes from 10.42.7.2: icmp_seq=0 ttl=63 time=8.220 ms
--- 20.20.20.54 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 8.220/8.220/8.220/0.000 ms
What does the above mean ? R1 uses one path for one 10.10.10.0/24 and the other for 20.20.20.0/24. What else ? We ping 10.10.10.1 and 20.20.20.53 and we get replies from other addresses. It means that packets for those destinations were absorbed by the routing engine of R4 and this router replied with source of the ingress interface.
What else does it mean ? Traffic to any destination in those two subnets will be absorbed by R4's routing engine (20.20.20.54 for example).
Let's see how these look like on R4:
Code:
admin@R4> show route protocol static table inet.0
inet.0: 26 destinations, 26 routes (26 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.10.10.0/24 *[Static/5] 00:34:09
Receive
20.20.20.0/24 *[Static/5] 00:34:09
Receive
admin@R4> show route forwarding-table destination 10.10.10.4 vpn default
Routing table: default.inet
Internet:
Destination Type RtRef Next hop Type Index NhRef Netif
10.10.10.0/24 user 0 recv 33 2
admin@R4> show route forwarding-table destination 20.20.20.53 vpn default
Routing table: default.inet
Internet:
Destination Type RtRef Next hop Type Index NhRef Netif
20.20.20.0/24 user 0 recv 33 2
admin@R4> show route forwarding-table destination 10.10.10.4 vpn default extensive
Routing table: default.inet [Index 0]
Internet:
Destination: 10.10.10.0/24
Route type: user
Route reference: 0 Route interface-index: 0
Flags: sent to PFE
Next-hop type: receive Index: 33 Reference: 2
admin@R4> show route forwarding-table destination 20.20.20.53 vpn default extensive
Routing table: default.inet [Index 0]
Internet:
Destination: 20.20.20.0/24
Route type: user
Route reference: 0 Route interface-index: 0
Flags: sent to PFE
Next-hop type: receive Index: 33 Reference: 2
The next-hop of both static routes in RIB (routing engine) shows "Receive", in forwarding table (pushed to data plane), "recv" type.