cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1976
Views
10
Helpful
3
Replies

What method would you choose if starting DOT1X - Cisco Common Classification Policy Language (C3PL) or Traditional

John Palmason
Level 4
Level 4

Hello, I am just beginning my venture down the DOT1X path and I have been using this community for most if not all of my information gathering.  I am now running into a question that I would like to see the community weigh in on:

 

Use Cisco Common Classification Policy Language (C3PL) IBNS 2.0 or Traditional DOTX1 interface commands.

 

I have seen the benefits matrix and C3PL has many more plus's than traditional method.  What I wanted to know is if anybody has used the new method in a small/medium size deployment and if they have any thoughts or learnings they are willing to share. 

 

Thank you for you input either yay or nay.

 

John Palmason

1 Accepted Solution

Accepted Solutions

It’s very important to note that after you start configuring the C3PL policies themselves, you cannot revert to the legacy mode. You can switch back only if you haven’t configured C3PL yet; otherwise, you have to erase the switch configuration and reload or restore an older backup configuration.


C3PL allows the configuration to exist in memory once and be invoked multiple times. This is a processor- and memory-efficiency enhancement. Among the administrator-facing differences, the most notable benefits are:
 
802.1X and MAB can run simultaneously without having to sequence the two distinctive authentication processes, whereby 802.1X authentication has to be failed for MAB to start.
 
The use of service templates to control preconfigured ACL on the interface in the event of RADIUS not being available.
The new C3PL style does provide some very useful enhancements such as service templates. With the introduction of service templates, another ACL that would permit network access can be applied to the interface when a certain condition matches, such as when the RADIUS server is not reachable. This is known as the Critical ACL functionality
There is also a pretty cool feature in C3PL known as Critical MAB. This allows the switch to use a locally defined list of MAC addresses in the event that the centralized RADIUS server is unavailable.
Basically, the use of C3PL is recommended in a Secure Access deployment with ISE only in cases where you require the use of Critical ACL, Critical MAB, or interface templates. Otherwise, just continue to use the classic method of authentication configuration and keep your configurations across all platforms similar.

 

 

 

please do not forget to rate.

View solution in original post

3 Replies 3

It’s very important to note that after you start configuring the C3PL policies themselves, you cannot revert to the legacy mode. You can switch back only if you haven’t configured C3PL yet; otherwise, you have to erase the switch configuration and reload or restore an older backup configuration.


C3PL allows the configuration to exist in memory once and be invoked multiple times. This is a processor- and memory-efficiency enhancement. Among the administrator-facing differences, the most notable benefits are:
 
802.1X and MAB can run simultaneously without having to sequence the two distinctive authentication processes, whereby 802.1X authentication has to be failed for MAB to start.
 
The use of service templates to control preconfigured ACL on the interface in the event of RADIUS not being available.
The new C3PL style does provide some very useful enhancements such as service templates. With the introduction of service templates, another ACL that would permit network access can be applied to the interface when a certain condition matches, such as when the RADIUS server is not reachable. This is known as the Critical ACL functionality
There is also a pretty cool feature in C3PL known as Critical MAB. This allows the switch to use a locally defined list of MAC addresses in the event that the centralized RADIUS server is unavailable.
Basically, the use of C3PL is recommended in a Secure Access deployment with ISE only in cases where you require the use of Critical ACL, Critical MAB, or interface templates. Otherwise, just continue to use the classic method of authentication configuration and keep your configurations across all platforms similar.

 

 

 

please do not forget to rate.

Great summary.  To echo this, when we are assessing CPL vs. legacy with customers we look at what their switches will support.  If all their switches support CPL we will go with that.  If there is a mix of support we will discuss having config standardization using the legacy config across the board vs. taking advantage of CPL on the switches that support it.

Thank you both for your feedback, it is very helpful to hear others thoughts on this subject.  I am currently at the per-monitor stage with our deployment and I am just looking to soak up as much information as I can before starting this job.  I have a good lab for testing etc, so I will try out the show commands and capture some dif's to educate myself.

 

e.g. knowing that that they have some gotchas round using them.

authentication display new-style

JP