Static Routing
Next Hop Values#
On R2, verify that there is a BGP route to 1.1.1.1.
user1@R2>
user1@R2> show route 1.1.1.1
inet.0: 15 destinations, 15 routes (15 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
1.1.1.1/32 *[BGP/170] 5d 13:58:29, localpref 100
AS path: 17 17 17 17 I, validation-state: unverified
> to 10.10.10.1 via ge-0/0/1.0
On R1, configure static route to 10.22.1.32/27 with next-hop 10.10.10.2, preference 6. The ping from R1’s loopback to R2’s 10.22.1.34 interface must succeed. How RIB looks like, when a static route is configured with a next hop set to the IP address of the directly-attached host:
user1@R1> show route 10.22.1.32
inet.0: 15 destinations, 16 routes (13 active, 0 holddown, 3 hidden)
+ = Active Route, - = Last Active, * = Both
10.22.1.32/27 *[Static/6] 00:04:48
> to 10.10.10.2 via ge-0/0/2.0
On R1, modify the static route to 10.22.1.32/27 to have only a next-hop of ge-0/0/2. Verify that R1’s loopback no longer is able to ping R2’s 10.22.1.34. How RIB looks like, when a static route has a next hop set to a direct interface instead of the IP address of the remote host:
user1@R1> show route 10.22.1.32
inet.0: 15 destinations, 16 routes (13 active, 0 holddown, 3 hidden)
+ = Active Route, - = Last Active, * = Both
10.22.1.32/27 *[Static/6] 00:00:04
> via ge-0/0/2.0
#LessonLearned When the interface is of type Ethernet, then it can not be configured as next-hop of a static route.
Overwriting next-hop values#
Ensure that R4 is able to reach 10.22.1.34.
root@R4> show route 10.22.1.32
inet.0: 13 destinations, 15 routes (13 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.22.1.32/27 *[Static/190] 00:00:04
> to 10.22.1.2 via ge-0/0/3.0
root@R4>
root@R4> ping 10.22.1.34 source 4.4.4.4
PING 10.22.1.34 (10.22.1.34): 56 data bytes
64 bytes from 10.22.1.34: icmp_seq=0 ttl=64 time=1.449 ms
64 bytes from 10.22.1.34: icmp_seq=1 ttl=64 time=1.683 ms
^C
--- 10.22.1.34 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.449/1.566/1.683/0.117 ms
root@R4>
On R1, create a second static route to 10.22.1.32/27 with next-hop the WAN interface of R4. Make its preference lower (numerically higher) than of the route via R2’s WAN interface:
[edit]
user1@R1# ...tic route 10.22.1.32/27 next-hop 10.10.10.2 preference 10
[edit]
user1@R1# ...tic route 10.22.1.32/27 next-hop 10.10.10.10 preference 11
[edit]
user1@R1# show routing-options
rib inet.0 {
static {
route 0.0.0.0/0 next-hop 172.17.81.1;
}
}
autonomous-system 17;
static {
route 10.22.1.32/27 {
next-hop [ 10.10.10.2 10.10.10.10 ];
preference 11;
}
}
[edit]
user1@R1#
#LessonLearned When an existing static route already has a next hop, and a new next hop is configured, then:
- the new next hop value is added to the existing next hop value forming a list of next hops,
- the last entered preference value overwrites the previous preference value.
Qualified Next Hop, aka Floating Static Route#
Replace the second static route with qualified-next-hop;
user1@R1# show routing-options
rib inet.0 {
static {
route 0.0.0.0/0 next-hop 172.17.81.1;
}
}
autonomous-system 17;
static {
route 10.22.1.32/27 {
next-hop 10.10.10.2;
preference 11;
}
}
[edit]
user1@R1# .../27 qualified-next-hop 10.10.10.10 preference 12
[edit]
user1@R1# show routing-options
rib inet.0 {
static {
route 0.0.0.0/0 next-hop 172.17.81.1;
}
}
autonomous-system 17;
static {
route 10.22.1.32/27 {
next-hop 10.10.10.2;
qualified-next-hop 10.10.10.10 {
preference 12;
}
preference 11;
}
}
[edit]
user1@R1# commit check
configuration check succeeds
[edit]
user1@R1# commit
commit complete
Both static routes are installed in RIB and the route via R2’s WAN interface is the active one:
user1@R1> show route 10.22.1.32
inet.0: 15 destinations, 17 routes (13 active, 0 holddown, 3 hidden)
+ = Active Route, - = Last Active, * = Both
10.22.1.32/27 *[Static/11] 00:00:04
> to 10.10.10.2 via ge-0/0/2.0
[Static/12] 00:00:04
> to 10.10.10.10 via ge-0/0/4.0
user1@R1>
Impact of the Resolve option#
I make sure that R4 can reach R1’s loopback:
root@R4> show route 1.1.1.1
inet.0: 13 destinations, 15 routes (13 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
1.1.1.1/32 *[BGP/170] 6d 13:09:30, localpref 100
AS path: 17 17 17 17 I, validation-state: unverified
> to 10.10.10.9 via ge-0/0/1.0
[BGP/170] 22:41:08, localpref 100, from 2.2.2.2
AS path: 17 17 17 17 I, validation-state: unverified
> to 172.17.81.1 via fxp0.0
root@R4>
R1 updated config:
root@R1> show configuration routing-options static route 10.22.1.32/27
next-hop 10.22.1.4;
resolve;
preference 11;
root@R1>
And the routes necessary for the resolution do exist in RIB:
root@R1> show route 10.22.1.4
inet.0: 15 destinations, 16 routes (14 active, 0 holddown, 2 hidden)
+ = Active Route, - = Last Active, * = Both
10.22.1.0/27 *[BGP/170] 00:16:14, localpref 200
AS path: 22 I, validation-state: unverified
> to 10.10.10.10 via ge-0/0/4.0
root@R1> show route 10.22.1.0
inet.0: 15 destinations, 16 routes (14 active, 0 holddown, 2 hidden)
+ = Active Route, - = Last Active, * = Both
10.22.1.0/27 *[BGP/170] 00:16:26, localpref 200
AS path: 22 I, validation-state: unverified
> to 10.10.10.10 via ge-0/0/4.0
root@R1>
Testing reachability of R2’s interface in 10.22.1.32/27 from R1’s loopback:
root@R1> ping 10.22.1.34 source 1.1.1.1
PING 10.22.1.34 (10.22.1.34): 56 data bytes
64 bytes from 10.22.1.34: icmp_seq=0 ttl=64 time=2.265 ms
64 bytes from 10.22.1.34: icmp_seq=1 ttl=64 time=3.113 ms
64 bytes from 10.22.1.34: icmp_seq=2 ttl=64 time=1.987 ms
^C
--- 10.22.1.34 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.987/2.455/3.113/0.479 ms
root@R1>
Combining the resolve option with the qualified-next-hop option#
root@R1> show configuration routing-options static
route 10.22.1.32/27 {
next-hop 10.22.1.4;
resolve;
preference 11;
}
root@R1>
root@R1> configure
Entering configuration mode
[edit]
root@R1# ...tic route 10.22.1.32/27 next-hop 10.10.10.10 preference 12
[edit]
root@R1# show routing-options static route 10.22.1.32/27
next-hop [ 10.22.1.4 10.10.10.10 ];
resolve;
preference 12;
[edit]
root@R1#
#LessonLearned The option resolve can not be used with qualified-next-hop.
Rejecting Packets Matching a Static Route#
On R1, remove the static route to 10.22.1.32/27. Replace it with a static route to the same network but with reject as option instead of a next hop value. Initiate a ping to R2’s 10.22.1.34. Observe any ICMP messages on R1.
Configured intent:
user1@R1> show configuration routing-options
rib inet.0 {
static {
route 0.0.0.0/0 next-hop 172.17.81.1;
}
}
autonomous-system 17;
static {
route 10.22.1.32/27 {
reject;
preference 6;
}
}
user1@R1>
Observed reality:
user1@R1> ping 10.22.1.34 source 1.1.1.1
PING 10.22.1.34 (10.22.1.34): 56 data bytes
ping: sendto: No route to host
ping: sendto: No route to host
ping: sendto: No route to host
ping: sendto: No route to host
^C
--- 10.22.1.34 ping statistics ---
4 packets transmitted, 0 packets received, 100% packet loss
user1@R1>
Discarding Packets Matching A Static Route#
On R1, replace reject with discard and commit. Initiate a ping to R2’s 10.22.1.34.
Expected outcome: No ICMP messages are reported by R1.
Implementation:
user1@R1> show configuration routing-options
rib inet.0 {
static {
route 0.0.0.0/0 next-hop 172.17.81.1;
}
}
autonomous-system 17;
static {
route 10.22.1.32/27 {
discard;
preference 6;
}
}
user1@R1>
Observed reality:
user1@R1>
user1@R1> ping 10.22.1.34 source 1.1.1.1
PING 10.22.1.34 (10.22.1.34): 56 data bytes
#LessonLearned The option reject is polite and verbose. The option discard is silent and indifferent.