In some situations, users may need to redirect traffic to a specific next hop. To accomplish this, they can use filter-based forwarding (FBF). Whereas in legacy platforms, instance-type forwarding is supported, in ELS platforms however, it is not supported. So users must use the instance-type virtual-router.
This article details how to use the instance-type virtual-router to enable filter-based forwarding on in ELS devices.
Routing instance type forwarding is not supported.
root# show routing-instances FBF-test { ## ## Warning: statement ignored: unsupported platform (ex4600-40f) ## instance-type forwarding; }
To perform filter-based forwarding in ELS devices, use the following instructions.
Use the routing instance–type virtual-router with an instance-import policy. For the example below, we are pinging from R1 to the loopback interface in R3 (100.100.100.100). The preferred path to reach 100.100.100.100 from R2 is via interface xe-0/0/2, but we will forward the traffic through xe-0/0/1.
Topology
R1
root@R1> show route 100.100.100.100 inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 100.100.100.100/32 *[Static/5] 3d 19:36:37 > to 10.10.10.2 via xe-0/0/0.0 root@R1> ping 100.100.100.100 PING 100.100.100.100 (100.100.100.100): 56 data bytes 64 bytes from 100.100.100.100: icmp_seq=0 ttl=63 time=10.798 ms 64 bytes from 100.100.100.100: icmp_seq=1 ttl=63 time=11.106 ms ^C --- 100.100.100.100 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 10.798/10.952/11.106/0.154 ms
Static route pointing to R2
{master:0} root@R1> show configuration routing-options static { route 100.100.100.100/32 next-hop 10.10.10.2; }
R2
The preferred route to 100.100.100.100 is via xe-0/0/2.
root@R2# run show route 100.100.100.100 inet.0: 10 destinations, 11 routes (10 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 100.100.100.100/32 *[Static/5] 00:00:10 > to 12.12.12.2 via xe-0/0/2.0 [Static/20] 00:00:10 > to 11.11.11.2 via xe-0/0/1.0
Configure the routing-instance with the instance-type virtual-router, but do not add any interface. The instance-import statement is used to leak the route from inet.0 so as to enable resolution of the next-hop for the static route.
instance-import
root@R2# show routing-instances FBF-test { instance-type virtual-router; routing-options { static { route 0.0.0.0/0 next-hop 12.12.12.2; } instance-import FBF-export; } }
Configure the policy for the instance-import statement.
root@R2# show policy-options policy-statement FBF-export { term 1 { from { instance master; route-filter 12.12.12.0/30 exact; } then accept; } term 2 { then reject; } }
Verify the results.
root@R2# run show route 100.100.100.100 inet.0: 10 destinations, 11 routes (10 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 100.100.100.100/32 *[Static/5] 00:08:26 > to 12.12.12.2 via xe-0/0/2.0 [Static/20] 00:08:26 > to 11.11.11.2 via xe-0/0/1.0 FBF-test.inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[Static/5] 3d 19:36:27 > to 12.12.12.2 via xe-0/0/2.0
Configure and apply a firewall filter to redirect traffic destined to 100.100.100.100 to be forwarded by the routing-instance. You can use the " then count " option to make sure that the filter is working.
then count
root@R2# show firewall family inet { filter FBF-test { term 1 { from { source-address { 10.10.10.1/32; } destination-address { 100.100.100.100/32; } } then { count FBF-count; routing-instance FBF-test; } } term 2 { then accept; } } } root@R2# show interfaces xe-0/0/0 unit 0 { family inet { filter { input FBF-test; } address 10.10.10.2/30; }
Check the results.
root@R1> ping 100.100.100.100 rapid count 10 PING 100.100.100.100 (100.100.100.100): 56 data bytes !!!!!!!!!! --- 100.100.100.100 ping statistics --- 10 packets transmitted, 10 packets received, 0% packet loss round-trip min/avg/max/stddev = 10.417/10.819/11.311/0.232 ms
root@R2> show firewall Filter: FBF-test Counters: Name Bytes Packets FBF-count 1020 10
R3
It is confirmed that the packets are being received by R3 via interface xe-0/0/1.
{master:0}[edit] root@R3# run monitor traffic interface xe-0/0/1 size 1500 no-resolve matching "host 10.10.10.1" verbose output suppressed, use <detail> or <extensive> for full protocol decode Address resolution is OFF. Listening on xe-0/0/1, capture size 1500 bytes 13:34:40.042352 Out IP 100.100.100.100 > 10.10.10.1: ICMP echo reply, id 58945, seq 0, length 64 13:34:40.053379 Out IP 100.100.100.100 > 10.10.10.1: ICMP echo reply, id 58945, seq 1, length 64 13:34:40.064359 Out IP 100.100.100.100 > 10.10.10.1: ICMP echo reply, id 58945, seq 2, length 64 13:34:40.075307 Out IP 100.100.100.100 > 10.10.10.1: ICMP echo reply, id 58945, seq 3, length 64 13:34:40.086305 Out IP 100.100.100.100 > 10.10.10.1: ICMP echo reply, id 58945, seq 4, length 64 13:34:40.097309 Out IP 100.100.100.100 > 10.10.10.1: ICMP echo reply, id 58945, seq 5, length 64 13:34:40.108306 Out IP 100.100.100.100 > 10.10.10.1: ICMP echo reply, id 58945, seq 6, length 64 13:34:40.119304 Out IP 100.100.100.100 > 10.10.10.1: ICMP echo reply, id 58945, seq 7, length 64 13:34:40.130305 Out IP 100.100.100.100 > 10.10.10.1: ICMP echo reply, id 58945, seq 8, length 64 13:34:40.141349 Out IP 100.100.100.100 > 10.10.10.1: ICMP echo reply, id 58945, seq 9, length 64 ^C 10 packets received by filter 0 packets dropped by kernel
2021-03-23: Updated the Related Link Title to match the new title that aligns with Juniper's Inclusion & Diversity initiatives