cancel
Showing results for 
Search instead for 
Did you mean: 
Create a Post
Raphael_V
Ivory

Policy Based Routing and default route / features

Hi everyone,

just some questions regarding policy based routing.

We have defined a default IPv4 static route in GAIA that points to an IP address of our router.
Now I have configured a new network that needs its default route to point to a different IP address.

Policy based routing is not yet configured, only static IPv4 routes.
The idea was to configure PBR the following way:
1) Create an Action Table with the option "Default Route" ticked and the different router IP address.
2) Create a Policy table with the new network as matching criteria.

Now I have the following questions:

a) Will the newly created PBR default route conflict with my default static IPv4 route for all my other networks?
I do not want end up with all my other networks using the default route defined in PBR... only the new network.

b) The PBR sk article states that some features are not supported with PBR like: Anti Spam Blade, Mail Transfer Agent.
Is it possible to configure PBR and continue to use these features with all the networks that use IPv4 static routing?
If I understand this statement right then this features are only not available for the PBR routed networks and will continue to work fine with all my other networks, is that correct?

Thanks and best regards
Raphael

5 Replies

Re: Policy Based Routing and default route / features

I don't understand your problem in detail.

You can control the PBR routes according to „policy rules“. So you can make sure that the default route is changed or not changed. It all depends on the policy rules.    

Further information can be found in the following SK100500:

Policy-Based Routing (PBR) on Gaia OS 

Best Regards

Heiko

Duane_Toler
Nickel

Re: Policy Based Routing and default route / features

Only the networks being matched in the PBR configuration will be affected.  Similar to an ACL or route-map, there's a default "deny" meaning "no match" at the end.

0 Kudos

Re: Policy Based Routing and default route / features

in my little experiance with PBR and default route, for the subnet included in the table, I had to create additional action for internal routing between subnet directly connected to the same gateway.

In detail in a scenario where subnet A, B, C are connected to the same gateway and for the subnet C I create a PBR with default route, I have to create the PBR to route from C to A by interface A and from C to B by interface B.

0 Kudos
Duane_Toler
Nickel

Re: Policy Based Routing and default route / features

If you do want Subnet C to communicate with Subnets A and B, then you will need to make a policy match rule for that to allow it.

Something like:

set pbr table SubnetC_to_A static-route default nexthop gateway address A.1.1.1 priority 1

set pbr table SubnetC_to_B static-route default nexthop gateway address B.1.1.1 priority 1

set pbr table SubnetC_default static-route default nexthop gateway address Z.1.1.1 priority 1

set pbr rule priority 1 match from C.1.1.0/24 to A.1.1.0/24 interface ethC

set pbr rule priority 1 action table SubnetC_to_A

set pbr rule priority 2 match from C.1.1.0/24 to B.1.1.0/24 interface ethC

set pbr rule priority 2 action table SubnetC_to_B

set pbr rule priority 3 match interface ethC

set pbr rule priority 3 action table SubnetC_default

Re: Policy Based Routing and default route / features

Gianluca & Duane are correct in that you would need PBR policy rules for routes to other internal (Non-Default) routes. 

I'd like to help reinforce the thought process when managing a PBR policy in R77.x with the following explanation I used to give to my engineers (Not sure if same in R80, but would assume so)...

Once a source packet matches a PBR rule; it enters the PBR territory and NEVER leaves PBR territory!  The moment you define a source network to match in PBR, then ANYTHING coming from that network will bypass the normal routing kernel and only look at PBR policy rules.

We had to replicate an entire "normal" routing table (~120 routes) into PBR rules to allow internal connectivity to continue.  And route changes occurred weekly as we on-boarded new branch offices.  It was a NIGHTMARE to manage on an internal/segmentation firewall with all these routes that handfuls of engineers had access to work on and troubleshoot.  If you have a simple "normal" kernel routing table that doesn't change often, then it's really not that bad to adjust to some PBR.

Also keep in mind that if any route change is needed for some reason..you'd need to apply it to both normal static route table, AND the PBR table if the route is applicable to both.

0 Kudos