Significance of "receive" next-hop static routes in JunOS

Significance of "receive" next-hop static routes in JunOS

One 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.

Linux, FreeBSD, Juniper, Cisco / Network security articles and troubleshooting guides

Significance of "receive" next-hop static routes in JunOS

Significance of "receive" next-hop static routes in JunOS