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.
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.
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.
R1
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
R2
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