There are several situations where we need to write some form of policy such as QoS, routing policies used in for example redistribution, filtering and policy-based routing, dot1x and so on. Lately I had to update a policy used by the master controller (MC) in an IWAN design. What are some important things to consider when writing the policy?
The number to start with – If you start with the number one then it won’t be possible to insert anything above this line at a later time. How certain are you that you will never have to put anything before the starting line? My recommendation is to start with a higher number such as 100.
Space between each line – Don’t number your lines 100, 101, 102, 103 and so on. Leave some more space between each line in case you have to insert something later between two lines. A spacing of 10 should be fine for most situations.
Go from most granular to least granular – The policy should go from as granular as possible to the least granular at the end. If you have a statement that is too broad you may catch more than you expected even if you have a more granular statement later. For that reason try to put the most granular statements at the top and move to less granular statements further down.
Put some space between the penultimate and ultimate line – Leave some space between the second to last line and the last one. So if your second to last line is 200, don’t put the last one at 201. Leave some extra space in there in case you want to put something else in front of the last line.
One other thing I like to do is to name my policies something like QOS-POLICY-001 to indicate that this is the first version of the QoS policy. The next one would be 002 and so on. In some cases it may be better to write a new policy than updating the old one and in some cases you just want to update the old one.
Here is an example of a MC policy which shows some of the concepts I described above.
[code lang=”text”]
class CIFS sequence 100
match application cifs policy low-latency-data
class WIFI_CONTROL sequence 120
match application capwap-control policy low-latency-data
class WIFI_DATA sequence 140
match application capwap-data policy low-latency-data
class DEFAULT sequence 300
match dscp default policy low-latency-data
[/code]
Good stuff Daniel. My unsolicited and simple advice:
1. Counts by tens
2. Make the final “permit all” or “deny all” a really big number
It’s very easy to remember and works well in 99% of cases. Example:
route-map TEST permit 10
stuff
route-map TEST deny 20
stuff
route-map TEST permit 1000
Nice Explanation.
Daniel, These are helpful advice on Numbering Policies in Networking. I have learned a lot of things through this post. Great article thanks and keep it up!