[EX/QFX] Performing filter-based forwarding in ELS devices

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

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;
}

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.

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

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

Knowledge Base