Header Only - DO NOT REMOVE - Extreme Networks

EXOS Lose Internal Access After Applying Policy Based Routing


Userlevel 2
We are trying to route traffic from a particular server out an ASA firewall. We are moving from a Cisco core where we had the following in place:

ip access-list extended PBR-ASA
permit ip host 10.10.34.54 any
!
route-map ASA-MAP permit 10
match ip address PBR-ASA
set ip default next-hop 10.10.0.3

The behavior on the Cisco was basically to set the 0.0.0.0 route for that particular server to point to the ASA (10.10.0.3), but it still seemed to use all other routes internally so internal connectivity was just fine.

We have tried the following, but when we apply this we lose internal access to the Server (10.10.34.54):

entry PBR-ASA {
if match all {
source-address 10.10.34.54/32;
}
then {
redirect 10.10.0.3;
count pbr-asa;
}
}

I was applying this Access-List to the vlan that this server belonged to:

configure access-list PBR-ASA vlan VLAN305 ingress

We only want this server to redirect to 10.10.0.3 for it's external access. Any ideas on how to achieve this?

Thanks!

14 replies

Check out page 36.

http://extrcdn.extremenetworks.com/wp-content/uploads/2014/10/ACL_Solutions_Guide.pdf
Also, what equipment do you have?
Userlevel 2
Jeremy,

This is on some x670 switches. Does the flow-redirect 'add nexthop' work similar to the 'set ip default next-hop' in Cisco?

Thanks!
Userlevel 7
Ty Kolff wrote:

Jeremy,

This is on some x670 switches. Does the flow-redirect 'add nexthop' work similar to the 'set ip default next-hop' in Cisco?

Thanks!

Hi Ty,

the list of nexthop entries created via add nexthop are used to define fallbacks if one (or more) nexthop(s) is(are) unreachable. This is different from setting a different default route via PBR in Cisco IOS.

Erik
Userlevel 7
Hi Ty,

you could add an ACL entry to permit traffic from the server to any internal network before the redirect entry. That way internal traffic will be forwarded normally, only external traffic would use PBR, similar to setting a different default route via PBR in Cisco IOS.

Erik
Userlevel 2
So something like this should do the trick? This would allow access to the local subnet(s) 10.0.0.0/8 and then redirect to 10.10.0.3 for all non internal traffic?

entry PBR-LOCAL { if match all { source-address 10.10.34.54/32; destination-address 10.0.0.0/8; } then { permit; count pbr-local; } } entry PBR-ASA { if match all { source-address 10.10.34.54/32; } then { redirect 10.10.0.3; count pbr-asa; } } [/code]
Userlevel 2
Ty Kolff wrote:

So something like this should do the trick? This would allow access to the local subnet(s) 10.0.0.0/8 and then redirect to 10.10.0.3 for all non internal traffic?

entry PBR-LOCAL { if match all { source-address 10.10.34.54/32; destination-address 10.0.0.0/8; } then { permit; count pbr-local; } } entry PBR-ASA { if match all { source-address 10.10.34.54/32; } then { redirect 10.10.0.3; count pbr-asa; } } [/code]

I tested this in a lab and production environment and I can confirm that this does indeed do what we expected. It allows the server access to the local 10.0.0.0/8 subnet, but redirects all other traffic to 10.10.0.3.
Userlevel 7
Ty Kolff wrote:

So something like this should do the trick? This would allow access to the local subnet(s) 10.0.0.0/8 and then redirect to 10.10.0.3 for all non internal traffic?

entry PBR-LOCAL { if match all { source-address 10.10.34.54/32; destination-address 10.0.0.0/8; } then { permit; count pbr-local; } } entry PBR-ASA { if match all { source-address 10.10.34.54/32; } then { redirect 10.10.0.3; count pbr-asa; } } [/code]

Thanks for letting us know! 🙂
Userlevel 7
Hi Ty,

that looks good to me, I would try that. 🙂

Erik
Userlevel 6
Interesting case... Just curious.. Did you try to trace to and from the server to check the path?
Userlevel 7
Henrique wrote:

Interesting case... Just curious.. Did you try to trace to and from the server to check the path?

Hi Henrique,

the set ip default next-hop feature of Cisco IOS policy based routing is quite special. It results in normal, non-policy routing for every matching packet whose destination follows a specific (i.e. non-default) route. Only if no specific route to the destination exists and the default route would be used, the specified next-hop is used instead.

The policy based routing available on EXOS always redirects matching packets (if fast-path forwarded).

Thus the different results.

Erik
Userlevel 6
Henrique wrote:

Interesting case... Just curious.. Did you try to trace to and from the server to check the path?

Hi Erik, understood. Thanks for the explanation from Cisco side. 🙂
Userlevel 2
I haven't had a chance to test this yet. I will be circling back to this in about a week and a half and let you know the results.
Userlevel 6
Ty Kolff wrote:

I haven't had a chance to test this yet. I will be circling back to this in about a week and a half and let you know the results.

Great, thank you.

Reply