Understanding IBNS 2.0

"The What?" - In this post I want to cover Identity Based Networking Services (IBNS) 2.0 to include benefits, configuration, & simply a general understanding of it. At first glance it can be a bit overwhelming so hopefully this helps.


"The Why?" - IBNS provides several benefits which include the following:

  • Session Management identity-based framework

  • Simpler way to be consistent across access methods/platforms/domains

  • Less interface configuration via interface template

  • Customizable features - ACL or assign critical SGT when AAA server is down;

  • Robust policy-control engine

  • Framework providing flexible/scalable services to secure clients

  • Allows separating authentication and authorization transactions between two or more AAA servers

  • Better way at detecting disconnects from indirectly connected hosts

IBNS main use cases are as follows:

  • Concurrent Authentication

  • Critical ACL after AAA failures

  • IPv6 support

  • Radius CoA (Change of Authorization) - IBNS supports CoA requests to manage client sessions

  • Web Authentication - Access session managers can conduct CoA for web authentication sessions

  • Interface templates - user defined reusable templates for interfaces which are used to manage interface config in an easier manner

  • Autoconf - Simplified solution for automatic interface config

"The How?" - Let's start with a brief overview of the components used, how they integrate with each other, & what each component does. The basis of how IBNS works is via C3PL (Cisco Common Classification Policy Language). Which C3PL is composed of class maps, policy maps, & service policies. Think of the correlations like this: class map is the control class, policy maps are the control policy, & the service policies are the control service policy. Another key component used that you will see in the configuration are the service templates.


Now that we have an overview of the components that make up IBNS 2.0 let's breakdown each one.

  • Control Class - these are a set of conditions that must equal true for the control policy to execute actions. The options for classes can match-all, match-any, or match none.

  • Service Templates contain attributes that can be used/applied to subscriber sessions through control policies. Example features include ACLs/vlans/spanning-tree config/etc.

  • Control Policies - these consist of one or more rules which mandates how the policy rules will be evaluated. The control policies consist of a control class, event, one or many actions to take.

  • Control Service Policy - essentially when you apply the control policy to end user interfaces so they take effect;

Now I will breakdown each component used in an example:


Let's do a quick overview of what an IBNS 1.0 port config may look like before breaking down IBNS 2.0 so that you can see the benefits:

interface GigabitEthernet1/0/2
 description Dot1x Access Port
 switchport access vlan XX
 switchport mode access
 ip access-group Base_ACL in 
 authentication order dot1x mab 
 authentication priority dot1x mab 
 authentication port-control auto  
 authentication periodic
 authentication timer reauthenticate 1800 
 authentication timer restart 1900 
 authentication timer inactivity 1700
 authentication event fail action next-method 
 mab 
 dot1x pae authenticator 
 dot1x timeout server-timeout 10 
 dot1x timeout tx-period 10  
 dot1x timeout supp-timeout 10 
 spanning-tree portfast
 spanning-tree bpduguard enable
end

Key point here is the benefit mentioned earlier of less port configuration across all access ports! The service templates help solve this issue!


Applying a service template to interfaces:

interface TwoGigabitEthernet1/0/1
 ...
 source template DefaultWiredDot1xClosedAuth
 ...
end

Brief example of what a service template of interface configs may look like:

template DefaultWiredDot1xClosedAuth
 dot1x pae authenticator
 dot1x timeout supp-timeout 7
 dot1x max-req 3
 switchport mode access
 switchport voice vlan XX
 mab
 access-session closed
 access-session port-control auto
 authentication periodic
 authentication timer reauthenticate server
 service-policy type control subscriber PMAP_DefaultWiredDot1xClosedAuth_1X_MAB
!

Let's breakdown the 'PMAP_DefaultWiredDot1xClosedAuth_1X_MAB' control policy. Note that this is a default Closed Auth policy from an SDA deployment; Some notes identified in green:

PMAP_DefaultWiredDot1xClosedAuth_1X_MAB
 event session-started match-all --event is a new session start
  10 class always do-until-failure --default class; continue to execute action in class until failure; new MAC on port initiate dot1x
   10 authenticate using dot1x retries 2 retry-time 0 priority 10 --dot1x higher priority than mab
 event authentication-failure match-first --event is auth failure
  5 class DOT1X_FAILED do-until-failure --failure type is class DOT1X_FAILED
   10 terminate dot1x  --Action terminate dot1x
   20 authenticate using mab priority 20 --Action authenticate via mab after dot1x termination
  10 class AAA_SVR_DOWN_UNAUTHD_HOST do-until-failure --AAA server down/unreachable
   10 activate service-template DefaultCriticalAuthVlan_SRV_TEMPLATE --Activate specific critical data vlan template
   20 activate service-template DefaultCriticalVoice_SRV_TEMPLATE --Activate specific critical voice vlan
   30 authorize --authorize hosts
   40 pause reauthentication --hold/pause reauth
  20 class AAA_SVR_DOWN_AUTHD_HOST do-until-failure
   10 pause reauthentication
   20 authorize
  30 class DOT1X_NO_RESP do-until-failure
   10 terminate dot1x
   20 authenticate using mab priority 20
  40 class MAB_FAILED do-until-failure
   10 terminate mab
   20 authentication-restart 60
  50 class DOT1X_TIMEOUT do-until-failure
   10 terminate dot1x
   20 authenticate using mab priority 20
  60 class always do-until-failure
   10 terminate dot1x
   20 terminate mab
   30 authentication-restart 60
 event aaa-available match-all
  10 class IN_CRITICAL_AUTH_CLOSED_MODE do-until-failure
   10 clear-session
  20 class NOT_IN_CRITICAL_AUTH_CLOSED_MODE do-until-failure
   10 resume reauthentication
 event agent-found match-all --If endpoint initiates EAP session, after mab authz, stop all methods, and authenticate host via dot1x
  10 class always do-until-failure
   10 terminate mab
   20 authenticate using dot1x retries 2 retry-time 0 priority 10
 event inactivity-timeout match-all --After inactivity-timeout clear authentication session
  10 class always do-until-failure
   10 clear-session --Clear session
 event authentication-success match-all
 event violation match-all
  10 class always do-until-failure
   10 restrict
 event authorization-failure match-all --authz failure after authc success
  10 class AUTHC_SUCCESS-AUTHZ_FAIL do-until-failure
   10 authentication-restart 60 --restart authc
!

The service policy works from the top down. Each event has classes which are referenced below. Remember that the classes have match conditions which can be all, any, or none in order for a match result on the given class.


An overview of the control classes in the control policy (which are self explainable once you walkthrough each class). These are referenced in the above service policy under specific events:

class-map type control subscriber match-all AAA_SVR_DOWN_AUTHD_HOST 
 match authorization-status authorized
 match result-type aaa-timeout
!
class-map type control subscriber match-all AAA_SVR_DOWN_UNAUTHD_HOST
 match authorization-status unauthorized
 match result-type aaa-timeout
!
class-map type control subscriber match-all AUTHC_SUCCESS-AUTHZ_FAIL
 match authorization-status unauthorized
 match result-type success
!
class-map type control subscriber match-all DOT1X
 match method dot1x
!
class-map type control subscriber match-all DOT1X_FAILED
 match method dot1x
 match result-type method dot1x authoritative
!
class-map type control subscriber match-all DOT1X_MEDIUM_PRIO
 match authorizing-method-priority gt 20
!
class-map type control subscriber match-all DOT1X_NO_RESP
 match method dot1x
 match result-type method dot1x agent-not-found
!
class-map type control subscriber match-all DOT1X_TIMEOUT
 match method dot1x
 match result-type method dot1x method-timeout
!
class-map type control subscriber match-any IN_CRITICAL_AUTH
 match activated-service-template DefaultCriticalVoice_SRV_TEMPLATE
!
class-map type control subscriber match-any IN_CRITICAL_AUTH_CLOSED_MODE
 match activated-service-template DefaultCriticalAuthVlan_SRV_TEMPLATE
 match activated-service-template DefaultCriticalVoice_SRV_TEMPLATE
!
class-map type control subscriber match-all MAB
 match method mab
!
class-map type control subscriber match-all MAB_FAILED
 match method mab
 match result-type method mab authoritative
!
class-map type control subscriber match-none NOT_IN_CRITICAL_AUTH
 match activated-service-template DefaultCriticalVoice_SRV_TEMPLATE
!
class-map type control subscriber match-none NOT_IN_CRITICAL_AUTH_CLOSED_MODE
 match activated-service-template DefaultCriticalAuthVlan_SRV_TEMPLATE
 match activated-service-template DefaultCriticalVoice_SRV_TEMPLATE
!

A few quick notes before we cap this post off:


If you are running what most call the legacy way (IBNS 1.0) you can actually use the tool Cisco has to convert the configurations to IBNS 2.0. This can be done via:

 #authentication display new-style

Actually per Cisco, best practice for transitioning to IBNS 2.0 in the best way possible is to configure a single port using IBNS 1.0, test the transition in non-production environment to get the most accurate IBNS 2.0 configuration that meets your needs, and then deploy in production.


The only way you can transition back to using IBNS 1.0 is if there have been zero changes to the control policy, issued a wr mem, and/or any other IBNS 2.0 configuration changes. If you have performed any of these items then you will not be allowed to revert back. You can revert back via:

#authentication display legacy privileged  

Here is a quick way to determine what IBNS mode the NAD is running:

#authentication display config-mode

Some global AAA/radius configurations are different between IBNS 1.0 & 2.0.

  • The 'aaa accounting dot1x' command is converted to 'aaa accounting identity' in IBNS 2.0 style.

  • The 'authentication mac-move permit' command is the default in IBNS 2.0, and therefore, the configuration does not show up in the running configuration. If you want to disable mac-move, configure 'access-session mac-move deny' explicitly in the global configuration mode.

  • The 'device-sensor accounting' command is replaced with the 'access-session attributes filter-list' command set in IBNS 2.0 configuration.

Lastly, once in the new style config mode, the 'show authentication' commands are replaced with show 'access-session' commands for session verification.


Ok, that wraps up this post supporting the understanding of IBNS 2.0, Cheers!

0 comments

Recent Posts

See All

In this tidbit I want to cover some high level notes on general trustsec items as well as some good-to-knows. A brief overview of what trustsec is: TrustSec provides scalable access controls by uniqu

I want to walkthrough enabling the External RESTful Services (ERS) APIs in Cisco ISE 3.0 so that we can consume ISE APIs in later posts to do a variety of things to include endpoint creation/manipulat