cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5255
Views
28
Helpful
15
Replies

Profiling FlexConnect AP and switch Interface Template

Arne Bier
VIP
VIP

Hello

 

Is there a best practice around handling Cisco FlexConnect APs and their switchport configuration when doing profiling?  Flex APs require commands relating to trunking and native VLAN etc. - which is different to the usual port template that I apply when I am authenticating access port devices.

 

I want all my Cat 9300 ports to have the same config to start off with - e.g. - and only if I AuthZ a FlexAP, I want ISE to send the necessary result to apply a different Port Template

interface FiveGigabitEthernet2/0/48
 device-tracking attach-policy IPDT_POLICY
 source template PORT-AUTH-TEMPLATE
 spanning-tree portfast

On the the Cat 9300 switch (IOS-XE 16.9.4) I have created two port templates - one for access ports, and one for FlexAPs - they both share the same subscriber service policy (802.1X first, then MAB, etc - IBNS 2.0)

 

template APFLEX-PORT-TEMPLATE
 spanning-tree portfast trunk
 dot1x pae authenticator
 dot1x timeout tx-period 7
 dot1x max-reauth-req 3
 switchport trunk native vlan 99
 switchport mode trunk
 mab
 access-session closed
 access-session port-control auto
 authentication periodic
 authentication timer reauthenticate server
 service-policy type control subscriber PORT-AUTH-POLICY
 description ** DOT1X FlexAP Trunk **


template PORT-AUTH-TEMPLATE spanning-tree portfast dot1x pae authenticator dot1x timeout tx-period 7 dot1x max-reauth-req 3 switchport access vlan 10 switchport mode access switchport voice vlan 15 access-session closed access-session port-control auto authentication periodic authentication timer reauthenticate server service-policy type control subscriber PORT-AUTH-POLICY description ** DOT1X Enabled Port **

When ISE profiles a Cisco AP then it returns an AuthZ Result as follows

 

ISE-authz-result.PNG

It works but is this the correct approach?  I noticed that even after the port is shut down, the config remains. It's not dynamic.

And the mixture of access and trunk settings looks messy.

 

We start off like this

S1#show run int fiveGigabitEthernet 2/0/48
interface FiveGigabitEthernet2/0/48
device-tracking attach-policy IPDT_POLICY
source template PORT-AUTH-TEMPLATE
spanning-tree portfast


When you successfully auth an AP on that port then through the magic of IBNS the config changes slightly (port-template sent via ISE)
S1#show run int fi 2/0/48
interface FiveGigabitEthernet2/0/48
device-tracking attach-policy IPDT_POLICY
source template PORT-AUTH-TEMPLATE
spanning-tree portfast trunk
end


which currently ‘expands‘ to a derived config of:

S1#show derived-config int fi 2/0/48
interface FiveGigabitEthernet2/0/48
description ** DOT1X FlexAP Trunk **
switchport access vlan 10
switchport trunk native vlan 99
switchport mode trunk
switchport voice vlan 15
device-tracking attach-policy IPDT_POLICY
authentication periodic
authentication timer reauthenticate server
access-session closed
access-session port-control auto
mab
dot1x pae authenticator
dot1x timeout tx-period 7
dot1x max-reauth-req 3
spanning-tree portfast trunk
service-policy type control subscriber PORT-AUTH-POLICY
end


And for sanity check, the AP is in trunk mode

S1#show int fi 2/0/48 switchport
Name: Fi2/0/48
Switchport: Enabled
Administrative Mode: trunk
Operational Mode: trunk
Administrative Trunking Encapsulation: dot1q
Operational Trunking Encapsulation: dot1q
Negotiation of Trunking: On
Access Mode VLAN: 10 (VLAN0010)
Trunking Native Mode VLAN: 99 (VLAN099)
Administrative Native VLAN tagging: disabled
Voice VLAN: 15 (VLAN0015)
Administrative private-vlan host-association: none
Administrative private-vlan mapping: none
Administrative private-vlan trunk native VLAN: none
Administrative private-vlan trunk Native VLAN tagging: enabled
Administrative private-vlan trunk encapsulation: dot1q
Administrative private-vlan trunk normal VLANs: none
Administrative private-vlan trunk associations: none
Administrative private-vlan trunk mappings: none
Operational private-vlan: none
Trunking VLANs Enabled: ALL
Pruning VLANs Enabled: 2-1001
Capture Mode Disabled
Capture VLANs Allowed: ALL
Protected: false
Unknown unicast blocked: disabled
Unknown multicast blocked: disabled
Vepa Enabled: false
Appliance trust: none


 

1 Accepted Solution

Accepted Solutions

Johannes Luther
Level 4
Level 4

So I finally get it working on a 2960X.

On the Catalyst 9300 I have a loop when applying an interface template via the ISE.
My guess is I'm hitting the bugs CSCwd26360

Regardless of the bug, here are my finding and my personal summary:

Interface templates are merged

When there is already a static interface applied and an interface template is applied using AAA, the templates and the interface configuration are merged. Highest priority has the dynamic interface template (over AAA), followed by the static interface configuration and finally the static interface template.

Reference: "Priority for Configurations Using Interface Templates"

 

Interface templates only ADD or REPLACE config

Configuration cannot be negated using interface templates. For example, if there is are storm control thresholds or action applied to the interface (either through static configuration or a statically applied template), there is no way to remove this config using a dynamic template. There may be other / additional ways through EEM or macros - but not by using templates.

My personal finding: If there is the requirement to dynamically and drastically change an interface configuration using AAA, the static interface configuration should have as few / minimal configuration lines as possible to have maximum flexibility. The per "use case" or device type config is applied through a dynamic template using AAA. However, the drawback to this approach is, that unauthorized hosts in low impact mode (which fails authorization), won't have a full interface configuration. This may be mitigated by applying a service template in the corresponding IBNS C3PL class.

 

Mandatory additional config

I could not get the whole thing to work without the additioanl interface template command:

access-session interface-template sticky 

"The Autoconf sticky feature avoids the need for detecting the end device and applying the template every time the link flaps or the device is removed and connected back. The access-session interface-template sticky command is mandatory to apply an inbuilt template that contains access-session commands on an interface. Configure the access-session interface-template sticky command to apply interface template on a port using a service policy."

Reference

 

View solution in original post

15 Replies 15

Johannes Luther
Level 4
Level 4

Hi Arne,

quite old article, but I'm struggling with this as well.
From my point of view, the Flex Template does not need any 802.1X or MAB config, because the MACs are authenticated by the WLC. .... So my wish would be to just convert the port into a trunk with a given native VLAN and a VLAN list ...

 Most of my customers just exclude AP ports from any authentication.  Most consider these "infrastructure" ports same as a connection between a switch and a router or a switch and a server.

Arne Bier
VIP
VIP

@Johannes Luther - what are you struggling with exactly? Is it with the implementation of this, or the concept that bothers you?

Some customers have APs in spaces that must be protected - they want ALL access ports protected. For APs that need trunk mode (Flex or Meraki) this solution works great. I am implementing this for a customer at the moment. No complaints.

If the AP is hidden under the ceiling and only the antenna is visible, then one could argue that this doesn't pose a network threat - the AP can be hidden away. 

The other thing to keep in mind is that NAC is not only there to make extra work for us ... but it also increases the visibility of the devices that are connected. Sure, you can get visibility elsewhere (NMS, or management platform of each device type) - but in case of NAC, ISE becomes a centralised visibility platform.

Lastly - if NAC is applied everywhere (even in tricky cases) then you are ready for things like Automated Threat Containment. Most customers are not there yet. But without NAC, you have no concept of a 'session' which is required to manage the endpoint - if an endpoint must be contained, re-auth'd, blocked etc - with NAC you have sessions, and sessions give you control at the network level.

Johannes Luther
Level 4
Level 4

Hi @Arne Bier 

thank you for your reply. So my exact scenario is:

  • Access switch port in closed mode with mode access
  • A client access specific interface template is configured on the ports (fixed): CLIENT-ACCESS-TEMPLATE
  • The switches (9300, 2960X) runs IBNS2.0 configuration
  • Ports by default are in multi-domain mode

My simple thought was: If a FlexConnect AP is connected, MAB authentication and authorization happens - the ISE knows by the MAC whether it's a FlexAP or a local mode AP.

My original plan was: For Flex APs, the ISE sends the RADIUS attribute:

cisco-av-pair = interface-template-name=AP-FLEX-TEMPLATE

 On the switch the AP-FLEX-TEMPLATE is:

template AP-FLEX-ACCESS-TEMPLATE
switchport mode trunk
switchport trunk native vlan <NATIVE-VLAN-ID>
switchport trunk allowed vlan <VLAN-ALLOWED-LIST>
switchport nonegotiate
spanning-tree portfast trunk
!

Depending on the platform weird things happens when the FlexAP is authorized:

- 2960X: Both interface templates - the fixed one on the port and the AP-FLEX-ACCESS-TEMPLATE are merged when performing a "show derived-config"

- 9300: There is a authentication loop on the ports (I have no idea why)

What I want to achieve is, that only the template for flex APs is applied - ideally without any NAC enforcement applied on the port, because the wireless clients are authenticated by the WLC... I don't want to authenticate them twice. Especially for PSK clients, I don't want to manage a list of wireless MACs on the ISE. If this is not possible I would go with "multi-host" and the AP "opens" the port for all attached clients.

I experimented with the additional attribute (NEAT):

cisco-av-pair = device-traffic-class=switch

However, this does not do the job as well... Some documents state, this is only supported with connected (cascaded) Catalyst switches (compact switch use case).

I'm not quite sure what the correct approach and combination of features is to make this work..

I also thought about (but did not try it out):

- SmartPort Macros (I just got a death chill down my spine as I wrote this bullet point)

- Triggering an EEM which does "something"(tm)

- Maybe using a Pyhton script in the guestshell (however this is not possible on C2960 series).

Great point and well argued. I think that multi-host might be the answer. As long as the AP is always the device that sends the first frame. 

Maybe others have better idea ?

Hi Arne,
So, I'm working on this topic again. Regarding Multi-Host: The AP should be in a different VLAN as the clients ... So I guess this eliminates this option...

Arne Bier
VIP
VIP

I am starting to understand why the majority of folks just don't bother to put Wireless Access Points into a NAC enabled port. Because it's tricky to implement. And as I recently discovered, Meraki APs don't even support NAC authentication. 

In a world where the WAP is connected in some tunnelled mode (like CAPWAP), then it's a no brainer, because you need a simple access mode interface for those types of WAPs - and NAC works perfectly well. But as soon as you have a trunk scenario, or WAP that lacks the supplicant, you have to look for other solutions.

Johannes Luther
Level 4
Level 4

So I finally get it working on a 2960X.

On the Catalyst 9300 I have a loop when applying an interface template via the ISE.
My guess is I'm hitting the bugs CSCwd26360

Regardless of the bug, here are my finding and my personal summary:

Interface templates are merged

When there is already a static interface applied and an interface template is applied using AAA, the templates and the interface configuration are merged. Highest priority has the dynamic interface template (over AAA), followed by the static interface configuration and finally the static interface template.

Reference: "Priority for Configurations Using Interface Templates"

 

Interface templates only ADD or REPLACE config

Configuration cannot be negated using interface templates. For example, if there is are storm control thresholds or action applied to the interface (either through static configuration or a statically applied template), there is no way to remove this config using a dynamic template. There may be other / additional ways through EEM or macros - but not by using templates.

My personal finding: If there is the requirement to dynamically and drastically change an interface configuration using AAA, the static interface configuration should have as few / minimal configuration lines as possible to have maximum flexibility. The per "use case" or device type config is applied through a dynamic template using AAA. However, the drawback to this approach is, that unauthorized hosts in low impact mode (which fails authorization), won't have a full interface configuration. This may be mitigated by applying a service template in the corresponding IBNS C3PL class.

 

Mandatory additional config

I could not get the whole thing to work without the additioanl interface template command:

access-session interface-template sticky 

"The Autoconf sticky feature avoids the need for detecting the end device and applying the template every time the link flaps or the device is removed and connected back. The access-session interface-template sticky command is mandatory to apply an inbuilt template that contains access-session commands on an interface. Configure the access-session interface-template sticky command to apply interface template on a port using a service policy."

Reference

 

achim2
Level 1
Level 1

Hi Johannes, though this is a quite old post, I have a question regarding your solution: Above, you and Arne mentioned multi-host. In my opinion, multi-host is mandatory for a flex ap. Do you also switch the host-mode via template or do you start with multi-host for the flex aps already? I experienced additional issues when we try to switch access to trunk and multi-auth or multi-domain to multi-host. For the flex aps it works with workarounds, but not for downlink switches. And NEAT should not be combinated with templates and in addition NEAT only configures mode trunk but not host-mode multi-host...

I can't comment - I have safely pushed this issue under the rug for the time being - my customers generally don't use NAC on wireless access points (thank goodness for that).

Hi @achim2 ,
so it's more or less the same as @Arne Bier mentioned in the next post. At the end of the day it was very frustrating and the topic is pushed aside. However, here are my personal findings:

  • If interface template assignments are used with ISE, the "access-session interface-template sticky timer" is mandatory. Otherwise you'll end up with interface configuration flapping with link flaps.
  • MAB and NEAT are mutually exclusive. The NEAT functionality cannot be used in combination with MAB ports. So it's pretty hard to develop an "universal" plug and play confguration.

I cannot remember more things for now. From my point of view it's a not properly documented and not stable solution. I guess Cisco won't put much effort in this topic (cascaded switches, NAC for flex APs) in traditional network scenarios. I bet with fairy dust DNA Center and SDA fabrics, there are other ways to tacle such things.

achim2
Level 1
Level 1

Hi @Arne Bier@Johannes Luther, hi all,

fortunately, I have got this working in the meantime. APs are authenticated and get the interface template with mode trunk and host-mode multi-host which helps them to work at any switchport in the network. And not only flexconnect aps are working, but also supplicant switches which are used as port extension in offices. They have uplinks, which are accessible to end users and should be authenticated like other end devices. There are still some smaller issues, but this feature can be used in production.

Now I'm working on creating awareness for this great feature at Cisco itself, since there is no guide yet and the responses from Cisco employees differ between "no, this will never work" and "good idea, I think this should work". If somebody else plans to use IBNS 2.0 to have a unique port config on the switches, feel free to contact me!

I would be keen to revisit this with some of my customers where we had given up on trying, or ran into issues we could not resolve.

Are you saying that you are in touch with Cisco to update their official documentation? That would be nice.

Do you have a blog or a working document to share in the meantime?

It really would be nice if you could put this into a blog post describing as much as possible what your findings are.