For When You Can't Have The Real Thing
[ start | index | login ]
start > 3Com > 4500G > Traffic Filtering

Traffic Filtering

Created by dave. Last edited by dave, 6 years and 66 days ago. Viewed 6,939 times. #3
[diff] [history] [edit] [rdf]
labels
attachments
(June 21, 2007)

A simple traffic filtering example for the 3Com 4500G

Your traffic filtering is made up of these parts:

  • An ACL ruleset, which defines the traffic you want to filter;
  • A traffic behavior, which is what you want to do with the traffic
  • A traffic classifier, which is the mechanism which tests traffic against the ACL ruleset
  • A qos policy which glues the classifier to the desired behavior
Qos policies are applied at the port-level, not the vlan level like we are used to.

The noodle-baker is that since the policy applies the behavior to traffic which passes the ACL ruleset, you have to write your ruleset upside-down; ie use the ruleset to permit traffic you want to deny, and deny traffic you want to permit.

Consider the following example that is a little more complex than the one in the manual.

I have a common network 10.0.0.0/24 on which I have a DHCP server. I have a collection of customer networks, each of which is a class-C in the 10.1.0.0 space – so for this example, 10.1.0.0/24 and 10.1.1.0/24. I want each customer network to be able to talk to the common network, but not to each other.

So OK, let’s define the ACL:

acl number 3100
rule deny ip source 10.1.0.0 0.0.0.255 destination 10.1.0.0 0.0.0.255
rule deny ip source 10.1.1.0 0.0.0.255 destination 10.1.1.0 0.0.0.255
rule permit ip source 10.1.0.0 0.0.255.255 destination 10.1.0.0 0.0.255.255
quit

This looks counter-intuitive, but consider that we want to apply our desired behavior to traffic which is permitted through this ACL.

ACLs are evaluated from top to bottom, with the first match being the applied result. So for this ruleset, 10.1.0.0/24 to 10.1.0.0/24 traffic does not make it through the ACL. 10.1.0.0/24 to 10.1.1.0/24 traffic does make it through this ACL. Anything not specified here does NOT make it through this ACL.

This is our behavior:

traffic behavior deny-traffic 
filter deny
quit

This is the classifier. It checks the traffic against the ruleset. This is written this way because it is possible to specify multiple ACLs and other conditions in and or or combinations in order to have different behaviors. This is how the qos system works.

traffic classifier customer-net-classifier
if-match acl 3100
quit

This is the policy, connecting the classifier with the desired behavior.

qos policy customer-net-policy
classifier customer-net-classifier behavior deny-traffic
quit

In other words, DENY traffic which is permitted through the ACL. In the absence of contradicting policy, anything which does not make it through the ACL is permitted through the policy.

Finally, we have to apply the policy to the Ethernet interfaces which will carry the affected traffic, in our example ports 19 and 20:

interface GigabitEthernet 1/0/19
qos apply policy customer-net-policy inbound
quit
interface GigabitEthernet 1/0/20
qos apply policy customer-net-policy inbound
quit

That's it.

no comments | post comment
This is a collection of techical information, much of it learned the hard way. Consider it a lab book or a /info directory. I doubt much of it will be of use to anyone else.

Useful:


snipsnap.org | Copyright 2000-2002 Matthias L. Jugel and Stephan J. Schmidt