Header Only - DO NOT REMOVE - Extreme Networks

Configure Flow Redirect with Multiple Match Conditions


I have successfully configured flow redirect a few times using examples from other posts here on the Extreme site such as:

https://gtacknowledge.extremenetworks.com/articles/How_To/How-to-configure-flow-redirect
and
https://gtacknowledge.extremenetworks.com/articles/How_To/How-to-create-and-apply-an-ACL-in-EXOS

However, in some cases I need to be able to enable flow redirect in a very specific manner for specific hosts. For example I might need host 10.22.70.10 to not be matched for flow redirect when accessing the Internet (0.0.0.0/0) but I do want it to be matched for flow redirect when it is destined for any private network (10.0.0.0/8, 192.168.0.0/16 or 172.16.0.0/12).

I realize this question is more about configuring access lists than flow redirect. I am fairly new to access list configurations on the Extreme devices.

I would think I could do something similar to this:
entry one {
if match all {
source-address 10.22.70.10/32 ;
destination-address 10.0.0.0/8 ;
} then {
deny ;
} [/code] if match all {
source-address 10.22.70.10/32 ;
destination-address 192.168.0.0/16 ;
} then {
deny ;
}
if match all {
source-address 172.16.0.0/16;
destination-address 172.16.0.0/12;
} then {
deny ;
if match all {
source-address 10.0.0.0/8 ;
} then {
permit ;
}

Does anyone have any thoughts or advice on this?

11 replies

Userlevel 7
Hi Trevor,

What you have above should work. The first matching entry will be taken, so you would catch a packet from that host going to any of the RFC1918 addresses before it hits the last permit.

Of course, if you wanted to flow-redirect the traffic, the action in those entries should be 'redirect-name', not 'deny'.
Userlevel 3
Hi Trevor,

if you want:
- host 10.22.70.10 to not be matched for flow redirect when accessing the Internet (0.0.0.0/0)
- flow redirect for network (10.0.0.0/8, 192.168.0.0/16 or 172.16.0.0/12).

Your ingress vlan/port ACL may look like below:

entry acl_10 { if {
source-address 10.22.70.10/32 ;
destination-address 10.0.0.0/8 ;
} then {
permit;
redirect-name My_GW ;
}}

entry acl_192 { if {
source-address 10.22.70.10/32 ;
destination-address 192.168.0.0/16 ;
} then {
permit;
redirect-name My_GW ;
}}

entry acl_172 { if {
source-address 10.22.70.10/32 ;
destination-address 172.16.0.0/12 ;
} then {
permit;
redirect-name My_GW ;
}}

--
Jarek
Hi Trevor,

if you want:
- host 10.22.70.10 to not be matched for flow redirect when accessing the Internet (0.0.0.0/0)
- flow redirect for network (10.0.0.0/8, 192.168.0.0/16 or 172.16.0.0/12).

Your ingress vlan/port ACL may look like below:

entry acl_10 { if {
source-address 10.22.70.10/32 ;
destination-address 10.0.0.0/8 ;
} then {
permit;
redirect-name My_GW ;
}}

entry acl_192 { if {
source-address 10.22.70.10/32 ;
destination-address 192.168.0.0/16 ;
} then {
permit;
redirect-name My_GW ;
}}

entry acl_172 { if {
source-address 10.22.70.10/32 ;
destination-address 172.16.0.0/12 ;
} then {
permit;
redirect-name My_GW ;
}}

--
Jarek
Thanks for the effort on this Jarek. What I am actually going for is for flow-redirect to be used for Internet traffic, whereas private traffic will just use the normal routing table. The specific use case is that I am forcing Internet traffic to pass through a firewall.
Userlevel 3
Hi Trevor,

if you want:
- host 10.22.70.10 to not be matched for flow redirect when accessing the Internet (0.0.0.0/0)
- flow redirect for network (10.0.0.0/8, 192.168.0.0/16 or 172.16.0.0/12).

Your ingress vlan/port ACL may look like below:

entry acl_10 { if {
source-address 10.22.70.10/32 ;
destination-address 10.0.0.0/8 ;
} then {
permit;
redirect-name My_GW ;
}}

entry acl_192 { if {
source-address 10.22.70.10/32 ;
destination-address 192.168.0.0/16 ;
} then {
permit;
redirect-name My_GW ;
}}

entry acl_172 { if {
source-address 10.22.70.10/32 ;
destination-address 172.16.0.0/12 ;
} then {
permit;
redirect-name My_GW ;
}}

--
Jarek
Ok, then delete the redirect-name My_GW from ACL entries 🙂
and add last ACL entry with

entry acl_all { if {
source-address 10.22.70.10/32 ;
} then {
permit;
redirect-name My_GW ;
}}

--
Jarek
Brandon,
Thanks for the fast reply. I made a mistake in typing my example. The last matching statement should have actually said:

" permit ;
redirect-name GTAC_redirect;"

So to be clear, those "deny" statements will only indicate that the traffic does not match the access-list and no special action should be taken upon it; not that it will deny the traffic from flowing through the normal routing process, right?

Trevor
Userlevel 7
Brandon,
Thanks for the fast reply. I made a mistake in typing my example. The last matching statement should have actually said:

" permit ;
redirect-name GTAC_redirect;"

So to be clear, those "deny" statements will only indicate that the traffic does not match the access-list and no special action should be taken upon it; not that it will deny the traffic from flowing through the normal routing process, right?

Trevor

No, the 'deny' will drop the traffic. If you want to allow it to be forwarded through the normal routing process, you would need a 'permit' action in the entry.
Userlevel 7
Brandon,
Thanks for the fast reply. I made a mistake in typing my example. The last matching statement should have actually said:

" permit ;
redirect-name GTAC_redirect;"

So to be clear, those "deny" statements will only indicate that the traffic does not match the access-list and no special action should be taken upon it; not that it will deny the traffic from flowing through the normal routing process, right?

Trevor

Also, I just noticed you had all the match conditions/actions in one large entry. There needs to be an entry per match condition/action pair. See below for an example:
entry allow_10{ if { source-address 10.22.70.10/32; destination-address 10.0.0.0/8; } then { permit; } } entry allow_192{ if { source-address 10.22.70.10/32; destination-address 192.168.0.0/16; } then { permit; } } entry allow_172{ if { source-address 10.22.70.10/32; destination-address 172.16.0.0/12; } then { permit; } } entry redirect_internet{ if { source-address 10.22.70.10/32; } then { redirect-name internet_redirect; } }
[/code]
Brandon,
Thanks for the fast reply. I made a mistake in typing my example. The last matching statement should have actually said:

" permit ;
redirect-name GTAC_redirect;"

So to be clear, those "deny" statements will only indicate that the traffic does not match the access-list and no special action should be taken upon it; not that it will deny the traffic from flowing through the normal routing process, right?

Trevor

Thanks for the hard work on this. I am going to be implementing this a little later this week. I will post back with the results.
Brandon,
Thanks for the fast reply. I made a mistake in typing my example. The last matching statement should have actually said:

" permit ;
redirect-name GTAC_redirect;"

So to be clear, those "deny" statements will only indicate that the traffic does not match the access-list and no special action should be taken upon it; not that it will deny the traffic from flowing through the normal routing process, right?

Trevor

I'm sorry I wasn't able to respond back to this for so long but I have good news to report. I was able to achieve what I wanted using the examples by Brandon and Jarek.

There were two issues that I had to work through though:

1. I wanted to apply the flow redirect on a port basis instead of a vlan basis. When I unconfigured the access-list command and then tried to change it to a port basis, I got this error message:

"Error: Flow redirect name used with the redirect-name keyword does not exist, unable to install this policy"

When I even tried to just reapply the access-list on a vlan basis, I still got the error message. I even called Extreme support and the person I spoke with didn't really know why this was happening either. I actually had to reboot the switch in order to be able to make the change. I wonder if others have experienced this and if perhaps there is a way I can just restart a specific service instead of having to fully restart the switch.

2. I noticed that flow-redirect will apply even if the destination is a network that is directly connected to the Extreme switch that is ipforwarding enabled. I had to actually go into the policy file and add an entry for the directly connected network that was just a "permit" action with no flow-redirect. Is that expected behavior?

Thanks,

Trevor
Userlevel 7
Brandon,
Thanks for the fast reply. I made a mistake in typing my example. The last matching statement should have actually said:

" permit ;
redirect-name GTAC_redirect;"

So to be clear, those "deny" statements will only indicate that the traffic does not match the access-list and no special action should be taken upon it; not that it will deny the traffic from flowing through the normal routing process, right?

Trevor

Regarding 2., that is expected because the ACL acts on the frame before routing.
Brandon,
Thanks for the fast reply. I made a mistake in typing my example. The last matching statement should have actually said:

" permit ;
redirect-name GTAC_redirect;"

So to be clear, those "deny" statements will only indicate that the traffic does not match the access-list and no special action should be taken upon it; not that it will deny the traffic from flowing through the normal routing process, right?

Trevor

Thank you for the assistance on this everyone. It was very helpful. Perhaps in a future exos version the reboot won't be needed or perhaps that was just a one time thing.

Reply