Support Support Downloads Knowledge Base Service Request Manager My Juniper Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

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

0

0

Article ID: KB34774 KB Last Updated: 26 Jul 2019Version: 1.0
Summary:

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.

 

Symptoms:

Routing instance type forwarding is not supported.

root# show routing-instances
FBF-test {
    ##
    ## Warning: statement ignored: unsupported platform (ex4600-40f)
    ##
    instance-type forwarding;
}

 

Solution:

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

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

 

Related Links

Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Security Alerts and Vulnerabilities

Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search