cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
13280
Views
120
Helpful
15
Replies

IBNS 2.0 / Dynamic Interface Templace not applied correctly unless sticky cmd used

Jozef Cmorej
Level 1
Level 1

Hello Cisco community,

I am struggling a bit with the combination of IBNS 2.0 and interface/service templates.

My environment looks following:
- ISE 2.3, patch 4
- IBNS 2.0 / 802.1X and MAB simultaneously
- Authenticator / Catalyst 3850, SW 16.9.1
- Supplicants / Cisco FlexConnect AP2800 and NEAT Switch 3560cx

There are 3 interface templates configured on the switches. The template called DEFAULT_ACCESSPORT is the default one attached to all user ports. Then we have two additional templates, one for the FlexAPs called DEFAULT_WLAN_AP_PORT and second for the NEAT Supplicant Switches called NEAT_AUTHZ. The reason for using additional templates is that we need to change the mode of switch ports from access to trunk for all FlexAPs and NEAT Supplicant switches.

If we send “only” dVLAN and/or dACL as a part of authorization rules from the ISE to the switches, it works properly as there is no dynamic interface template assignment. Once the ISE send also the name of the interface/service template that is configured locally to the switches to change the mode of the switch port, it does not work correctly unless we configure the command access-session interface-template sticky under the template DEFAULT_ACCESSPORT.

Cisco says about this command: The access-session interface-template sticky command is mandatory to apply an inbuilt template that contains access-session commands on an interface.

But using this command breaks the concept of dynamic configuration as the switch port configuration remains active even the port is shutdown or the device is disconnected.

Is there any other way how to make it working in combination of IBSN2.0 with dynamic interface/service templates? Because in my opinion, this sticky command breaks up the whole concept with dynamic templates.

 

We would like to avoid using macros if possible as they affect all switchports.

The Interface Templates:
---------------------

template DEFAULT_ACCESSPORT
 dot1x pae authenticator
 spanning-tree bpduguard enable
 switchport access vlan 3
 switchport mode access
 switchport voice vlan 2
 mab
 access-session host-mode multi-domain
 access-session control-direction in
 access-session port-control auto
 access-session interface-template sticky
 service-policy type control subscriber DOT1X_DEFAULT_POLICY
!
template DEFAULT_WLAN_AP_PORT
 dot1x pae authenticator
 spanning-tree portfast trunk
 spanning-tree bpduguard enable
 switchport trunk native vlan 10
 switchport mode trunk
 switchport nonegotiate
 mab
 access-session host-mode multi-host
 access-session control-direction in
 access-session port-control auto
!
template NEAT_AUTHZ
 spanning-tree portfast trunk
 spanning-tree bpduguard disable
 switchport trunk native vlan 3
 switchport mode trunk
 access-session host-mode multi-host

 

Thank you.

2 Accepted Solutions

Accepted Solutions

I agree with you. We also figured it out, that different HW platforms and SW versions behave differently. Some of them have more troubles with dynamic templates than others. I have already spent tens of hours trying to make it work but unsuccessfully. I am convinced these features are not fully prepared for being deployed in live environment at the moment.

View solution in original post

It has been confirmed with the Cisco Development team that with interface template authorization from ISE to a switch, certain port configurations can be changed (example: 'switch mode access' to 'switch mode trunk'), but the host-mode configuration changes are not permitted.

 

The behavior we are facing to is expected and per design according to Cisco and it is not the bug as we thought initially. It means, we cannot use dynamic interface templates if they contain “access-session host-mode” commands.

 

The only option the customer has, is to manually attach a static template to the interface based on a device type. A lot of manual work must be done and it breaks the concept of dynamic interface configuration with the access-session commands.

 

View solution in original post

15 Replies 15

shamax_1983
Level 3
Level 3

I am suffering from the exact same problem.  Did you find a fix for this yet?

 

When debugging is enabled, I can see the template assignment is going through an infinite "bind->unbind->bind->unbind" loop and never get assigned properly to the interface.

 

Adding the "sticky" command to the original interface template seems to fix the issue. But as you said, this would essentially break the dynamic nature of the port, so doesn't really make much sense to use it in our use-case where want the port to go back to DEFAULT settings/template and be available if a user plugs in a PC or a Phone at a later stage.

Debug output (snip)

*Sep 18 03:39:57.588: TEMPLATE EVENT: Gi1/0/1: Binding template INTERFACE_TEMPLATE_LWAP
*Sep 18 03:39:57.599: AUTH-EVENT: [Gi1/0/1] Set port control (2->3)
*Sep 18 03:39:57.618: AUTH-EVENT: Updating LL action params for unauthz call for domain 1ter no mo
*Sep 18 03:39:57.622: AUTH-EVENT: Host mode is SH/MH. mac_seen flag unset in subblock
*Sep 18 03:39:57.625: TEMPLATE EVENT: Gi1/0/1: Unbinding template INTERFACE_TEMPLATE_LWAP

 

Unfortunately no fix yet. We have open several TAC cases as it seems to be all bugs.

Thanks for getting back to me.

 

I was afraid of that. In any case, I will be opening a TAC case too, so at least we can get a fix sooner rather than later.

What I figured is that, most of the fancy things that Cisco claim to work with Dynamic Template Assignments (as it relates to IBNS2.0 and ISE) are so buggy. Even the most simple use-case with a simple template assignment won't work.

I agree with you. We also figured it out, that different HW platforms and SW versions behave differently. Some of them have more troubles with dynamic templates than others. I have already spent tens of hours trying to make it work but unsuccessfully. I am convinced these features are not fully prepared for being deployed in live environment at the moment.

According to Cisco IBNS Experts, the sticky command is mandatory to use in conjunction with dynamic templates.

 

They suggested us trying to configure “sticky timer” and check if it helps. Unfortunately, it did not help us much.

 

Using this command, after the client disconnect (or port is shut) the template binding should be removed after xx seconds.

below link for more details about the bug:

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCva74457/?referring_site=ss&dtid=osscdc000283

 

I have just tested the command “access-session interface-template sticky timer 10” on the Catalyst 3850 SW 16.9.1. When I type this command under the default template and restart the interfaces where the FlexAP for MAB and the NEAT Supplicant switch for 802.1x are connected to, the result is following:

 

mab           Authc Failed

 

The reason is, that the command MAB has somehow disappeared from the derived configuration of this interface and the dynamic template is not applied to the interface. On the other side, the template configuration itself still contain the MAB command.

For the NEAT switch I do not see any active session for 802.1X.

Once I configure the previous command “access-session interface-template sticky”, both devices are successfully authenticated and authorized as expected.

 

It is really weird...

 

I ran into the same bug with 16.3.6 where MAB was disappearing from the port. We down graded to 3.6.9, and it fixed the MAB issue. it also sort of fixed another weird MAB session terminated issue we were running into.

 

3.6.9 however does not seem to work with the 'access-session interface-template sticky' regardless of whether it is applied to the 'default' template or the AP template that ISE is sending.

It has been confirmed with the Cisco Development team that with interface template authorization from ISE to a switch, certain port configurations can be changed (example: 'switch mode access' to 'switch mode trunk'), but the host-mode configuration changes are not permitted.

 

The behavior we are facing to is expected and per design according to Cisco and it is not the bug as we thought initially. It means, we cannot use dynamic interface templates if they contain “access-session host-mode” commands.

 

The only option the customer has, is to manually attach a static template to the interface based on a device type. A lot of manual work must be done and it breaks the concept of dynamic interface configuration with the access-session commands.

 

The behavior we are facing to is expected and per design

 

It's a feature.... How useful.

 

One thing I've found is that as soon as you add the access-session host-mode multi-host command to the template it adds other IBNS2.0 commands to the template config but because they are the interface defaults you can't see them unless you do show run all

 

show run all | sec ISE_FLEX_AP
template ISE_FLEX_AP
switchport trunk native vlan 123
switchport trunk allowed vlan 123,124
switchport mode trunk
switchport nonegotiate
hold-queue 0 in
hold-queue 0 out
load-interval 300
carrier-delay 0

 

After the host-mode is configured, the default commands (shown in red) are also configured as part of the template, now some of these contradict and therefore presumably overrule the interface's manual config

 

BHF1-DV-SWI-04#show run all | sec ISE_FLEX_AP
template ISE_FLEX_AP
switchport trunk native vlan 123
switchport trunk allowed vlan 123,124
switchport mode trunk
switchport nonegotiate
access-session host-mode multi-host
access-session control-direction both
no access-session closed
access-session port-control force-authorized
no access-session interface-template sticky
no authentication periodic
authentication timer reauthenticate 3600
hold-queue 0 in
hold-queue 0 out
load-interval 300
carrier-delay 0

Hello

recapping all previously said i'd suggest to stay with single host-mode multi-auth transfered from templates to the interface range command.

franklinb
Level 1
Level 1

I've got this working or so it appears and I wonder if there's a subtle difference for why - I apply the interface sticky to the interface level, not in the template:

interface GigabitEthernet1/0/7
...
access-session interface-template sticky timer 5
no snmp trap link-status
source template STD_PORT
!
template STD_PORT
dot1x pae authenticator
spanning-tree portfast
switchport access vlan 100
switchport mode access
switchport voice vlan 200
mab
access-session closed
access-session port-control auto
authentication periodic
authentication timer reauthenticate server
service-policy type control subscriber AI_DOT1X_MAB_POLICIES
subscriber aging inactivity-timer 30 probe
!
template TEST_FLEX_WAP_PORT
dot1x pae authenticator
spanning-tree portfast trunk
switchport access vlan 101
switchport trunk native vlan 101
switchport mode trunk
switchport nonegotiate
access-session control-direction in
access-session port-control auto
authentication periodic
authentication timer reauthenticate server
service-policy type control subscriber AI_DOT1X_MAB_POLICIES

Some comments:

- I see in doco they repeat several of the auth commands that are already active such as pae authenticator, mab etc.. initially I didn't have these and it seemed to make no diff but have added them in in troubleshooting, but in the end all my issues were around portfast. I would get errors saying it couldn't change port mode. Once I added the sticky I managed to fix the last bit

 

%Portfast has been configured on GigabitEthernet1/0/7 but will only
have effect when the interface is in a non-trunking mode.
%Warning: portfast should only be enabled on ports connected to a single
host. Connecting hubs, concentrators, switches, bridges, etc... to this
interface when portfast is enabled, can cause temporary bridging loops.
Use with CAUTION

or this one with a different config

Authentication must be disabled before changing port mode 
Command rejected: Conflict with Authentication. 

 

- I had to use native vlan and access vlan of the AP management or it wouldn't work. It would auth but the management IP wasn't accessable and spanning-tree showed the MAC on that VLAN being dropped

- I put a timer on the sticky command but not sure if it's even needed. How can I even check the status?

- Testing with ISE 2.4p7, C9300 running 16.12.3

 

i have couple of cases in CTAC on the dynamic template for flexconnect AP or NEAT-switch with exactly MAC-drop subject.

our config is default access vlan on interface & trunk native <nondefaultvlan> vlan+trunk mode in dynamic template at the moment. with this we have noticed host-mode on interface must be multi-host (our standard is multi-auth) otherwise MACs start DROP.

for the neat circumstances for the expected behavior r little bit different but the same MAC-DROPs r in effect if ISE's authorization profile for NEAT has both "NEAT-checkbox" checked & dynamic Template defined & dynamic template definition on the switch doesnt contain "mode trunk".

C9.3K 16.9.3|16.9.4 & couple of higher

 

i'm about year already in fighting Cisco's IBNS2.0 & it looks for me more & more like epic fail 

 

Any updates on your cases with this issue ?

 

Im facing similar issues ...

well... with compact switches we have no problem with either IBNS1.0 or IBNS2.0. host mode in this case is multi-auth. But with flexconnect mode APs it's not the case. Below is quasi-workaround we use now:
1st the host-mode of multi-host is MUST, 2nd trunk native vlan for AP mgmt in the dynamic template must match access vlan on the authenticator's port. Otherwise: a) if u check NEAT option in the authZ profile, port's running config will be mangled with access vlan from the template, port mode trunk; b) if configured access vlan on the port doesn't match trunk native vlan from template, your locally switched wireless clients... dont receive IP addressing by DHCP (here CTAC is already for half of year cant give me BUG ID :0)

one short notice about your config: as u dont change host-mode within dynamic template u dont need interface-template sticky statement. in my understanding "interface-template sticky" is only way to make port transit into desired host-mode (quite unobvious though :0)
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: