View Only
last person joined: 21 hours ago 

Ask questions and share experiences about the SRX Series, vSRX, and cSRX.
  • 1.  PBR on a Virtual router

    Posted 04-18-2024 14:56

    Hello ,

    I am having a requirement from client , they have SRX cluster with a custom routing instanace (Virtual router)  called Prod.inet.0

    All LAN interfaces  ( vlan 5, vlan6,vlan 7)and WAN interface ( ISP1) are in  this custom routing instance

    in default instance inet.0 ,we have only fxp0 (mgmt) 

    Now customer is requesting a new ISP line , so there will be WAN 2 next week .

    Requirement is that traffic 

    1) traffic from vlan 5 and vlan6 always go to wan1

    2) Traffic from vlan 7 always go to wan 2

    3) in case wan1 goes down , wan2 should take all traffic for vlan5/6

    4) in case wan2 goes down , wan1 should take all traffic for vlan7

    DO i need to create  a new routing instance of type forwarding ? I checked Filterbase forwarding but thats talk about routing instance forwarding

    Here the custom routing instance is of type Virtual router so client cannot change it to forwarding ;

    Kindly suggest  the config .thanks in advance

  • 2.  RE: PBR on a Virtual router

    Posted 04-18-2024 19:26

    Yes,  part of doing the configuration will add a forwarding instance.  You can see an example configuration here.

    The forwarding instance is a new one created for this purpose as noted for both ISP.

    You do need to be sure that the routing options section you configure are under your virtual router Prod  and not the main level

    routing-options {
        interface-routes {
            rib-group inet IMPORT-PHY;
        static {
            route next-hop [ ];
        rib-groups {
            IMPORT-PHY {
                import-rib [ inet.0 routing-table-ISP1.inet.0 routing-table-ISP2.inet.0 ];

    And in your case the match criteria will be source ip addresses for the desired zone traffic and not the destination ports as in the example.

    Steve Puluka BSEET - Juniper Ambassador
    IP Architect - DQE Communications Pittsburgh, PA (Metro Ethernet & ISP - Retired)

  • 3.  RE: PBR on a Virtual router

    Posted 04-19-2024 05:35

    Hi Steve ,

    Thanks for your reply . This means that i have to create 2 routing instances ( both forwarding )  for two ISPs 

    currently in prod.inet.0  VR ,  ihave a default static route configured ,  which i have to remove ?

    and then call two default static routes in 2 new routing instances ?

  • 4.  RE: PBR on a Virtual router
    Best Answer

    Posted 04-19-2024 19:55

    Yes, two forwarding routing instances are created as in the example.

    You create the filters with source address matching for the forwarding instances for each ISP.

    In the Prod routing instance you add the rib group and import with the filter created in the main instance updated for your Prod.inet.0 import.

    set routing-instance Prod routing-options interface-routes rib-group inet IMPORT-PHY

    set routing-options rib-groups IMPORT-PHY import-rib Prod.inet.0

    set routing-options rib-groups IMPORT-PHY import-rib routing-table-ISP1.inet.0

    set routing-options rib-groups IMPORT-PHY import-rib routing-table-ISP2.inet.0

    The existing default route in the Prod routing instance can remain.  This will be used by traffic that does not match for the forwarding routing instance.

    Steve Puluka BSEET - Juniper Ambassador
    IP Architect - DQE Communications Pittsburgh, PA (Metro Ethernet & ISP - Retired)

  • 5.  RE: PBR on a Virtual router

    Posted 04-20-2024 04:20

    Hi Steve ,

    this works . Many thanks for your help .

    also i am using route monitoring policy using probe to a public ip 

    i am using  the option to change preference of 2nd isp to low if isp1 goes down and it works as well.

  • 6.  RE: PBR on a Virtual router

    Posted 04-19-2024 05:56

    I'd like to flesh it out a bit further with some pseudo-config based on some multi-ISP scenarios I've encountered:

    ### for uniformity, the pseudo-config below has the two ISPs each in their own VR
    # monitor your ISP
    services rpm {
       probe isp1 {
          # insert whatever tests you'd like with routing-instance isp1
       probe isp2 {
          # insert whatever tests you'd like with routing-instance isp2
    # insert a flag route if the tests fail
    services ip-monitoring {
       policy isp1 {
          match rpm isp1;
          then preferred-route routing-instance isp1 route discard; # the flag route can be anything that's not in use anywhere else
       policy isp2 {
          match rpm isp2;
          then preferred-route routing-instance isp2 route discard; # it's ok to use the same IP since we're placing it into a difference VR
    # routing policies
    policy-options {
       # convert the flag routes from ip-monitoring into routing policy conditions
       condition isp1-down {
          if-route-exists table isp1.inet.0;
       condition isp2-down {
          if-route-exists table isp2.inet.0;
       # prevent default routes from leaving the ISP vr if the ISP is down
       policy-statement isp1-export {
          term block-default-when-down {
             from route-filter exact, condition isp1-down;
             then reject;
          otherwise accept;
       policy-statement isp2-export {
          # same as isp1-export but checking condition isp2-down
       # populate your default routes in your prod VR using this policy
       policy-statement prod-import {
          term from-isp1 {
             from route-filter exact, instance isp1;
             then accept preference 10;
          term from-isp2 {
             from route-filter exact, instance isp2;
             then accept preference 20;
       # and a policy for your alternate internet selection VR
       policy-import alt-inet-import {
          # same as prod-import but invert the preferences
    # now to apply everything
    routing-instance {
       prod {
          # other existing config, except WAN1 moved to its own VR
          routing-options instance-import prod-import;
       alternate-internet {
          # this routing instance will have only default routes
          instance-type forwarding;
          routing-options instance-import alt-inet-import;
       isp1 {
          instance-type virtual-router;
          interface WAN1;
          routing-options {
             static route next-hop isp1_gateway_address;
             instance-export isp1-export;
             # if you plan on accepting incoming traffic from the internet, you need to have routes to the corresponding internal destinations
             # you can do that with rib groups or instance-import; if you won't be accepting incoming traffic, then no need to import any routes here
       isp2 {
          instance-type virtual-router;
          interface WAN2;
          routing-options {
             static route next-hop isp2_gateway_address;
             instance-export isp2-export;
    # finally, a PBR filter to direct internet traffic to the alternate-internet routing instance
    firewall family inet filter go-to-other-internet {
       term non-internet-traffic {
          from destination-address {
             # list your internal addresses here
   ; #etc
          then accept;
       term internet-traffic {
          then routing-instance alternate-internet;
    # apply the PBR filter to VLAN7
    interfaces VLAN7 unit 0 family inet filter input go-to-other-internet;

    The end result from this will be that you split your internet traffic between the two ISPs as you are required to do, but the ISPs will also back each other up automatically.

    Nikolay Semov