topic Re: Automatic Feed Service breaking existing infrastructure in Network Access Control

Automatic Feed Service breaking existing infrastructure

umahar — Wed, 04 May 2016 06:40:54 GMT

Hi ,

We hit a major change in profiling database where about 3000 Polycom phones changed their profile to Microsoft-Workstation.

I suspect this took place after the automatic feed update as I see new rules in Microsoft-Workstation profiling policy which is increasing the certainty factor for Microsoft-Workstation.

We need Feed Update in the future as we are planning to bring more devices such as IoT, Sensers etc. How do we make sure that Feed Update would not break any existing policy which might have catastrophic consequences ? Does Cisco publishes what updates it is going to release in the next update ?

Re: Automatic Feed Service breaking existing infrastructure

Timothy Abbott — Wed, 04 May 2016 13:57:56 GMT

Utkarsh,

Which profile attribute changed in ISE for the polycom phones? My gut tells me its the OUI but would like to confirm.

Regards,

-Tim

Re: Automatic Feed Service breaking existing infrastructure

umahar — Wed, 04 May 2016 15:12:48 GMT

Polycom phones were profiled using OUI with a CF of 10

Lot of polycom phones are coupled with Microsoft Lync service and also send dhcp-class-identifier attribute as MS-UC-Client.

Now we see a new condition as rule 4 on ISE for Microsoft-Workstation for the above dhcp-class-identifier which is changing the profile from Polycom to Microsoft-Workstation.

Re: Automatic Feed Service breaking existing infrastructure

Timothy Abbott — Wed, 04 May 2016 15:57:30 GMT

Utkarsh,

The reason I asked about OUI was because it is data we get directly from the IEFT and don't have any control over what is published. It is then included in our feed service update. In your case, we added a new condition to the Microsoft-Workstation profile policy that checks for a specific DHCP Class ID that is common on Microsoft-based PCs. As a workaround, you could add a similar condition to the the IP phone profile policy that such work in your environment. Unfortunately, we do not have a feature that shows the changes we make to the feed service.

Regards,

-Tim

Re: Automatic Feed Service breaking existing infrastructure

umahar — Wed, 04 May 2016 17:05:38 GMT

Timonthy,

Is it recommended to make changes to default profiling policies ? How do these manually altered profiling policies get updated on the next Feed Update ?

I was planning on not to touch the existing Polycom profiling policy but making another Polycom_custom profiling policy with two conditions (OUI+MS-UC-Client) so that it could beat the CF of Microsoft-Workstation.

We can then add this new policy group to the IP Phone logical group along with the old Polycom group

Re: Automatic Feed Service breaking existing infrastructure

Parag Mahajan — Fri, 06 May 2016 21:26:01 GMT

@Timonthy

I also faced same issue for one of my customer. Now customer is afraid of keeping feeder service on auto-update.

That's good idea to publish delta changes in profiling policy due to feeder update. We should publish daily update changes at least somewhere else on website or in feeder update email notification , so that you have 'Opportunity' to go back some other earlier versions. What do you say.

Currently we can go back 'Undo latest' just one version earlier. But what if profiling policy gets updated over weekend. We faced this Polycom issue on Monday and we had no idea whether its because of Friday, Saturday or Sundays update.

Re: Automatic Feed Service breaking existing infrastructure

Timothy Abbott — Mon, 09 May 2016 14:19:09 GMT

Parag,

I recommend the customer turn off auto-update in production if they are concerned about service interruption. If they have a lab environment, they could have auto-update turned on there with email notification so that they could then test in the lab environment prior to updating the production deployment.

Regards,

-Tim

Re: Automatic Feed Service breaking existing infrastructure

Parag Mahajan — Mon, 09 May 2016 14:38:36 GMT

Hi @Timothy Abbott

Thanks for reply. I agree with you and after this incident I have suggested the same. But customer opinion is it's too much work everytime.

They are asking why Cisco can not provide what Profiling policy changes update details in same feeder email notification, By doing this they can keep track how there profiling policies are evolving everyday and if they want to rollback to ANY earlier version they can manually do the changes.

What do you say ?

Re: Automatic Feed Service breaking existing infrastructure

Timothy Abbott — Mon, 09 May 2016 14:43:54 GMT

Parag,

I understand the customer's dilemma. Unfortunately, it is not a feature we currently have for the feed service. It isn't a issue of we can't but more of the fact that we haven't built it yet. I have forwarded the customer's feedback to the PM team as they are in control of what features are implemented in ISE.

Regards,

-Tim

Re: Automatic Feed Service breaking existing infrastructure

Parag Mahajan — Mon, 09 May 2016 14:57:48 GMT

Thanks a lot Tim