Header Only - DO NOT REMOVE - Extreme Networks

Any implication using ACL to classify ALL traffic?


Userlevel 5
Been given a requirement to implement a QoS configuration that I will be prioritising Voice and Video via an ACL on certain ports numbers.

My query is that I would then use a permit all on all remaining traffic to mark it with CS1 (DSCP 😎 and then put this into QP2.

The idea I believe is that anything quantified as 'bad' traffic can then be put into best effort, QP1, if required.

So my question is, all though I know ACL's are done in hardware I'm not sure if using an ACL for this purpose on every single packet would over burden the switch in some manner?

The switch is an X440, but interested if the outcome should this be a G2 or any other model be the same?

Many thanks in advance.

8 replies

Userlevel 7
Hi Martin,

packet editing via ACL should be implemented in hardware and not affect forwarding performance. ACLs are applied to every single packet anyway. As long as the switch has sufficient resources to apply the ACL you should be fine.

Erik
Userlevel 7
Erik Auerswald wrote:

Hi Martin,

packet editing via ACL should be implemented in hardware and not affect forwarding performance. ACLs are applied to every single packet anyway. As long as the switch has sufficient resources to apply the ACL you should be fine.

Erik

As an aside, you should ensure that you do not downgrade QoS of network control traffic.
Userlevel 5
Thanks for posting Erik.

Your answer nicely lead into my next question in how exactly I would not downgrade network control traffic.

My assumption would be that using a permit all rule to classify all traffic into QP2 would also capture network control traffic, which means I would have to create a rule to capture all the control traffic and queue appropriately.

My other thought is that I might be able to create the ACL so that I can simply just exempt all QP8 and QP7 (used for stacking) traffic.

Any ideas how you would do it?

Many thanks.
Userlevel 7
Martin Flammia wrote:

Thanks for posting Erik.

Your answer nicely lead into my next question in how exactly I would not downgrade network control traffic.

My assumption would be that using a permit all rule to classify all traffic into QP2 would also capture network control traffic, which means I would have to create a rule to capture all the control traffic and queue appropriately.

My other thought is that I might be able to create the ACL so that I can simply just exempt all QP8 and QP7 (used for stacking) traffic.

Any ideas how you would do it?

Many thanks.

As a start, you could match on the dot1p tag and dscp (or ip-tos) and change only frames with a value of 0 in both to QP2. That should leave anything already marked in the respective traffic class, and anything non-marked or non-IP in QP1. That of course assumes that network control is correctly marked and no traffic is incorrectly marked for a QoS class it is not supposed to use. You might need to add ARP to QP2 as well.
Userlevel 7
Martin Flammia wrote:

Thanks for posting Erik.

Your answer nicely lead into my next question in how exactly I would not downgrade network control traffic.

My assumption would be that using a permit all rule to classify all traffic into QP2 would also capture network control traffic, which means I would have to create a rule to capture all the control traffic and queue appropriately.

My other thought is that I might be able to create the ACL so that I can simply just exempt all QP8 and QP7 (used for stacking) traffic.

Any ideas how you would do it?

Many thanks.

It might work better to change the default dot1p and DSCP QP to QP2, and use ACLs to classify only special traffic (higher or lower priority than standard).
configure dot1p type dot1p_priority {qosprofile} qosprofile
configure diffserv examination code-point code_point {qosprofile} qosprofile[/code]You can find additional ideas and information in RFC 4594.
Userlevel 5
Thanks for the help - there is a slight problem with that in the why QoS is going to be implemented.

Basically the idea is not to trust anything at the edge, as it has been known for users to actively mark traffic with a QoS (DSCP) value. As an example a user could mark all their web traffic with a DSCP of 46 and then take advantage of QoS mechanisms employed, say for voice, also using DSCP 46.

So the idea is to create a untrusted and trusted area in the design. Everything south of the edge is untrusted. Everything north of the uplinks is trusted.

To make this demarcation work I will basically be turning off dot1p and diffserv examination south of the edge and enable it north of the uplinks.

ACL's will then be used at the edge to classify Voice and Video using port numbers with the use of diffserv replacement. Also the ACL will capture all remaining traffic and put it into QP2 as this thread details.

Now all traffic that enters the north side should be appropriately marked and we can use diffserv examination then onwards to trust the traffic. I will of course need to make sure any other traffic coming into the network, say from servers, web, are all put into QP2 (CS1, DSCP 😎.

So you can see I need the ACL to profile all traffic into QP2 as a kind of permit all, without trusting any 802.1p or DSCP values, while at the same time not effecting control traffic. It might be that I don't actually need to worry about any control traffic if I'm only applying this to an edge port?
Userlevel 7
Martin Flammia wrote:

Thanks for the help - there is a slight problem with that in the why QoS is going to be implemented.

Basically the idea is not to trust anything at the edge, as it has been known for users to actively mark traffic with a QoS (DSCP) value. As an example a user could mark all their web traffic with a DSCP of 46 and then take advantage of QoS mechanisms employed, say for voice, also using DSCP 46.

So the idea is to create a untrusted and trusted area in the design. Everything south of the edge is untrusted. Everything north of the uplinks is trusted.

To make this demarcation work I will basically be turning off dot1p and diffserv examination south of the edge and enable it north of the uplinks.

ACL's will then be used at the edge to classify Voice and Video using port numbers with the use of diffserv replacement. Also the ACL will capture all remaining traffic and put it into QP2 as this thread details.

Now all traffic that enters the north side should be appropriately marked and we can use diffserv examination then onwards to trust the traffic. I will of course need to make sure any other traffic coming into the network, say from servers, web, are all put into QP2 (CS1, DSCP 😎.

So you can see I need the ACL to profile all traffic into QP2 as a kind of permit all, without trusting any 802.1p or DSCP values, while at the same time not effecting control traffic. It might be that I don't actually need to worry about any control traffic if I'm only applying this to an edge port?

By changing the default mapping to have everything that would usually enter QP1 sent to QP2 changes nothing except providing an even lower queue to sent traffic to via ACL.

Traffic that would be sent to QP8 by default should not be allowed into access ports (e.g. by replacing the dot1p and/or DSCP fields). Inter switch links need to allow QP8 traffic.

Any traffic that shall be (de-)prioritized should be identified by an ACL and set to the intended "qosprofile".

Thus there is no trust for access ports.

You are right, applying the classification ACLs to access (edge) ports only should leave any network control traffic untouched.
Userlevel 5
Martin Flammia wrote:

Thanks for the help - there is a slight problem with that in the why QoS is going to be implemented.

Basically the idea is not to trust anything at the edge, as it has been known for users to actively mark traffic with a QoS (DSCP) value. As an example a user could mark all their web traffic with a DSCP of 46 and then take advantage of QoS mechanisms employed, say for voice, also using DSCP 46.

So the idea is to create a untrusted and trusted area in the design. Everything south of the edge is untrusted. Everything north of the uplinks is trusted.

To make this demarcation work I will basically be turning off dot1p and diffserv examination south of the edge and enable it north of the uplinks.

ACL's will then be used at the edge to classify Voice and Video using port numbers with the use of diffserv replacement. Also the ACL will capture all remaining traffic and put it into QP2 as this thread details.

Now all traffic that enters the north side should be appropriately marked and we can use diffserv examination then onwards to trust the traffic. I will of course need to make sure any other traffic coming into the network, say from servers, web, are all put into QP2 (CS1, DSCP 😎.

So you can see I need the ACL to profile all traffic into QP2 as a kind of permit all, without trusting any 802.1p or DSCP values, while at the same time not effecting control traffic. It might be that I don't actually need to worry about any control traffic if I'm only applying this to an edge port?

Thanks Erik, much appreciated.

Reply