SRX

 View Only
last person joined: yesterday 

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.

    https://supportportal.juniper.net/s/article/How-to-configure-Filter-Based-Forwarding-on-SRX-for-a-typical-dual-ISP-scenario?language=en_US

    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 0.0.0.0/0 next-hop [ 10.1.1.2 10.2.2.2 ];
        }
        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)
    http://puluka.com/home
    ------------------------------

    Original Message


  • 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 ?


    Original Message


  • 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)
    http://puluka.com/home
    ------------------------------

    Original Message


  • 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.


    Original Message


  • 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 10.255.255.255/32 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 10.255.255.255/32 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 10.255.255.255/32 table isp1.inet.0;
   }
   condition isp2-down {
      if-route-exists 10.255.255.255/32 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 0.0.0.0/0 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 0.0.0.0/0 exact, instance isp1;
         then accept preference 10;
      }
      term from-isp2 {
         from route-filter 0.0.0.0/0 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 0.0.0.0/0 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 0.0.0.0/0 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
         10.0.0.0/8; #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
    ------------------------------

    Original Message