Rethinking the Network

Marten Terpstra

Subscribe to Marten Terpstra: eMailAlertsEmail Alerts
Get Marten Terpstra: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Blog Feed Post

Policy versus ACLs, it’s those exposed implementation details again

In a blog week dedicated to the application and the policies that govern them, I wanted to add some detail on a discussion I have with customers quite often. It should be clear that we at Plexxi believe in application policy driven network behaviors. Our Affinities allow you to specify desired behavior between network endpoints, which will evolve with the enormous amount of policy work Mat described in his 3 piece article earlier this week.


Many times when I discuss Affinities and policies with customers or more generically with network engineering types, the explanation almost always lands at Access Control Lists (ACLs). Cisco created the concept of ACLs (and its many variations used for other policy constructs) way way back as a mechanism to instruct the switching chips inside their routers to accept or drop traffic. It started with a very simple “traffic from this source to this destination is dropped” and has very significantly evolved since then in Cisco’s implementation and many other of the router and switch vendors.

There are 2 basic components in an ACL:

1. what should I match a packet on

2. what is the action I take once I found a match.

Both portions of an ACL have had lots of options and possibilities added over time. You can specify TCP an UDP port numbers, match on TCP flags, ICMP types, established connections, ethernet protocol types, you name it. Most everything you can find the a packet header can be matched against. The actions have also become more flexible; from the basic “permit” and “deny” long ago, you can now add actions that count packets, log packets, forward out a specific interface, mirror the packet and a host of others.

Not Abstract Enough

While this flexibility is good progress, it suffers from a very significant lack of abstraction. What you are programming when you are typing your ACLs is almost identical to what gets programmed in the switching chips inside your switch or router. For the vast majority of switches and routers, your ACLs are implemented in this thing called Ternary Content Addressable Memory or TCAM. It’s specialized memory that is specifically built to do easy matching of bit patterns, with the added ability to allow wildcard matches on bits. TCAM is used to store the first part of the ACL components, what should be matched.

Switch or router software takes your matching portion of the ACL and translates into bits that match a packet headers. The header portions you did not specify are added as wildcard matches and every packet that comes along is compared to the entry in this TCAM memory and a “yes” or “no” result is returned. When a “yes” is returned, a pointer to a specific action is provided and the switching chip will execute that action on that matched packet. Pretty straightforward and simple.

It is not surprising that ACLs look so similar to what TCAMs do. ACLs were modeled after TCAMs. 20 years ago the software engineers took the TCAM ability and created a CLI equivalent for it. Easy to create, easy to implement. But that also meant that some of the complexities of TCAMs are exposed to the user. If you ever configured ACLs I bet you struggled the most with getting the ordering right. TCAM matching is done in a specific sequence and only will continue until a match has been found. That ordering is explicitly exposed to you as the user. Which means you need to construct the order and solve the puzzle of more and less specific things to match on. And that gets very complicated when you have partially overlapping matching criteria.

Policy != ACL

It also not surprising that discussions about policy in networking always end up at ACLs, or use ACLs as the common language to explain functionality. But we have to be very careful not to equate policy to ACLs, or limit our thinking of policy options to what today’s ACLs can accomplish. The types of policy Mat described in his previous articles, and the types of policy described in the series of posts go well beyond the basics of ACLs and are quickly far too complex for humans to translate into ACLs. Of course any switching chip will have a specific set of capabilities that will limit its implementation of policy actions. But we should not equate the network portion of the entire policy framework to ACLs. ACLs are a tool that can be used to implement policy. And most policies will require far more than ACLs to implement.


[Today's fun fact: In only 7.6 billion years, the sun will reach its maximum size and will shine 3,000 times brighter. Better get working on that SFP 10,000,000 sunscreen. And perhaps an endless icebucket challenge.]

The post Policy versus ACLs, it’s those exposed implementation details again appeared first on Plexxi.

Read the original blog entry...

More Stories By Marten Terpstra

Marten Terpstra is a Product Management Director at Plexxi Inc. Marten has extensive knowledge of the architecture, design, deployment and management of enterprise and carrier networks.