Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 
Community Member

acs 5.2 - expanding Radius Change of Authorisation (CoA) support


I've been testing the new 'manual' CoA support in acs 5.2.

I'd really like to be able to achieve port bounces automatically (Disconnect:Port Bounce—Terminate the session and restart the port).

For example if I've authenticated and authorised a mab request in acs 5.2 and ACS knows that the device vlan has changed as part of the aaa then I'd like acs to send a RADIUS CoA back to the switch to automatically bounce the port so that the device works again quickly.

I've had a look in the bug toolkit and can't see any enhancement requests for CoA in ACS 5.x.

Does anyone else out there want to do this sort of thing or know if there are any non-public enhancement requests present for this sort of feature?

Thanks very much

Everyone's tags (4)
Cisco Employee

Re: acs 5.2 - expanding Radius Change of Authorisation (CoA) sup


     I am not sure that this would work as a bounce of the port would cause the dot1x state to clear on the port and MAB would happen all over again.  But even something that isn't simple can be coded around with enough effort so if you would really like to see this feature I would suggest contacting your Cisco Account Rep and have then open a Product Enhancement Request on your behalf.


Community Member

Re: acs 5.2 - expanding Radius Change of Authorisation (CoA) sup

Hi Jesse

Thanks for that.  You've made me think a bit more about this!  The scenario that I had in mind was rolling out mab for the first time where VLANs may well change for devices that don't have supplicants.  Probably the best solution for this is to reduce DHCP lease times pre mab implementation so that devices won't have an inappropriate IP address for very long if they change VLAN.

I'm still interested in ACS being able to programatically fire off CoA port bounces to get devices out of trouble though.  In the scenario when a device has given itself a link-local IP address for whatever reason (DHCP service failure, broken firewall rules that have since been fixed etc) and dot1x / mab decides it's time to (re)authenticate it I think it should be fairly easy to get ACS to bounce the port to encourage re-dhcp.

If the switch is implementing IP device tracking or dhcp snooping then it can send the client device IP in the radius authentication request.  It should then be possible to use an IP end station filter in ACS to match all clients authenticating with link local addresses then optionally fire off a CoA port bounce.

Does that sound useful / feasible to anyone?

It seems that the current IP end station filter in ACS 5.2 requires that the IP is present in Attribute 31 (Calling-Station-Id) whilst switches have features to insert the IP of the client into Attribute 8 (Framed-IP-Address) (radius-server attribute 8 include-in-access-req).

I have a feeling this may turn in to two feature requests.



CreatePlease to create content