Cisco 9200L : NAC behaviour with dynamic vlan assignement dead server

[rrsstefano]

Hi all,

I want to ask you experts some suggestion on how really work mechanism between Cisco switches and radius server when using dynamic vlan assignement and the radius suddenly will be unavailable.

With server dead command under port configuration is possible to statically set the vlan to use in case server is not reachable

but I don't know if it can be used/is a suggested solution in case of dynamic vlan assignement...I think that if device remain connected it will continue to work on the dynamic vlan previously assigned by Radius, but if device disconnect and reconnect while radius is still unavailable on what vlan it will be put ?

Thanks for all suggestion

Stefano

[MHM Cisco World]

Yes you can 

Authentication event server dead action authorization vlan xx

Authentication event server alive action reinitialize <- this to re authz the host authz when server dead 

MHM

[rrsstefano]

Hi MHM,

thanks for you reply.

Because our customer want to use more dynamic vlan , then we have to control on a daily based manner which dynamic vlan is pushed on a specific port and align the dead action auth vlan  command to the actual vlan assignements...is it correct ?

[Arne Bier]

I guess you have some options about what to do when RADIUS is dead

1) Authorize using the configured interface VLAN

2) Authorize using a common critical VLAN (for sessions in the DATA domain) and you can also define whether or not to assign voice permission (to tag the traffic with the defined voice VLAN for voice endpoints).

3) Authorize a custom critical VLAN based on a lot of configurations on the switch - this is using a combination of customised port templates, where you can group interfaces to use a named port template that has its own critical VLAN - e.g. desktop PCs always get critical VLAN 100, versus printers that get VLAN 200.

I tend to use IBNS 2.0 where all this is defined. And IBNS 2.0 also provides another mechanism where (simplistically speaking) the switch will assign a role to an endpoint (with the help of ISE) and then cache that role - if ISE should be unavailable, then the switch has a cache of roles to work with and doesn't require the critical VLAN. But this also doesn't help you when you have to auth an endpoint that has never been seen on the switch before. In that case, critical VLAN or the defined interface VLAN is the only solution. I have never used that mechanism.

Have a look here for a better explanation.

The thing to remember is that normally, the only thing we tend to plug/unplug a lot on the wired network is workstations. We don't do the same with cameras, printers, HVAC, etc. Those devices won't be affected when ISE dies. Don't use session timeouts on those permanently attached devices.

[rrsstefano]

Hi Arne, thanks for you suggestion.

On our customer setup we have an old-style configuration like this :

interface GigabitEthernet1/0/48
description Server Video
switchport access vlan 28
switchport mode access
switchport voice vlan 120
srr-queue bandwidth share 10 10 20 60
queue-set 2
priority-queue out
authentication control-direction in
authentication event fail action next-method
authentication event server dead action authorize vlan 28
authentication event server dead action authorize voice
authentication event no-response action authorize vlan 28
authentication event server alive action reinitialize
authentication host-mode multi-domain
authentication order dot1x mab
authentication port-control auto
authentication periodic
authentication timer reauthenticate server
mab
mls qos trust device cisco-phone
mls qos trust cos
dot1x pae authenticator
dot1x timeout tx-period 7
dot1x max-reauth-req 3
spanning-tree portfast edge
spanning-tree bpduguard enable
end

So if by Radius ( not Cisco ISE but other vendor Forescout ) we push a dynamic vlan , normally a quarantine vlan or remediation vlan or in some cases a different vlan related to a particular type of devices, we would that this dynamic vlan remain also when the reauthentication timer expires 

Thanks

So I think we are using  option 2 you suggested.

[rrsstefano]

Hi Arne,

I'm looking more deeply to your last statement and matching with my last test i have a question for you

The thing to remember is that normally, the only thing we tend to plug/unplug a lot on the wired network is workstations. We don't do the same with cameras, printers, HVAC, etc. Those devices won't be affected when ISE dies. Don't use session timeouts on those permanently attached devices.

--> we use session timeout ( 12 hours for now pushed by radius server ) and I discovered surprisingly that it server is dead and session timeout expires, devices remain in the vlan previously authorized.

The critical vlan set by command "authentication event server dead action authorize vlan...." have effect only if I connect a new devices or the old device is disconnected and reconnected.Now I'm in doubt if this behaviour is valid also if there is a dynamic vlan assigned by radius during previous authentication...at the next session timeout expiration also the dynamic vlan is confirmed fot the device ?

Do you have experience on this ?

Thank a lot

[MHM Cisco World]

authentication event server dead action authorize vlan <<- this effect only new device, the old device will contious use same VLAN it assign by radius when the re-auth timer end and the server dead it will get vlan by this command. 
note:- this command only workaround you must solve the server dead in short time

MHM

[rrsstefano]

Hi MHM,

by test made , old devices remain in VLAN previously authorized static or dynamic also After session timeout expiration if It It remain connected even if server Is dead.If I disconnect cable or restart authentication then device Is put in the critical VLAN set by the authentication event server dead authorized VLAN command.

The drawback of this command Is that we have tò align the VLAN if It Is different from the static VLAN set in the switchport access VLAN command....

I tried tò test the authentication event server dead authorize without specifying VLAN but It doesnn't work...the Port remain in Unauthorized state....I made this test thi nking that without VLAN specified almost win the static VLAN configured...but serms not the case....

[Aref Alsouqi]

I don't think what you are trying to achieve is possible, because if the attribute of the VLAN ID is returned from the RADIUS server, dynamically, and that server is not available anymore, the switch won't have any idea of what VLAN ID it should associate to the session.

[rrsstefano]

yes Aref I think so, this is why we are thinking to a solution updating regularly the access static vlan and the critical vlan with the value returned by RADIUS based on the profile of device connected.

Also solution suggested by Arne to use IBNS 2.0 could be a valid one.

Thanks for your suggestion

[MHM Cisco World]

there is solution BUT this need more work 
instead of send VLAN-ID send VLAN name group
the SW that have UP of VLAN it will use it, other SW can use different

BUT thi solution for inter_SW VLAN assign 

MHM 

[rrsstefano]

MHM ,

but how usage of vlan-name could solve issue of server dead ?

[Arne Bier]

I have only been using IBNS 2.0 in customer deployments. The syntax is very clear about reauthentication during failures - it sets the data VLAN and voice VLAN and then disables the reauth temporarily - e.g. for Un-Authd endpoints

  15 class AAA_SVR_DOWN_UNAUTHD_HOST do-until-failure
   10 clear-authenticated-data-hosts-on-port
   20 activate service-template EMPLOYEE_CRITICAL_AUTH_ACCESS
   30 activate service-template DEFAULT_CRITICAL_VOICE_TEMPLATE
   40 authorize
   50 pause reauthentication

And then a different logic for Auth'd endpoints

 20 class AAA_SVR_DOWN_AUTHD_HOST do-until-failure
   10 pause reauthentication
   20 authorize

Perhaps your IBNS 1.0 style configuration achieves the same thing in a single line of config. There are some limitations between IBNS 1.0 and 2.0  

[rrsstefano]

Hi Arne,

probably usage of IBNS 2.0 could be a more powerful solution....never tested ...I try it in test plant

Thanks a lot