cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1582
Views
5
Helpful
11
Replies

Good 2960S code for ISE??

Kevin P Sheahan
Level 5
Level 5

There is a bug (CSCug08069) that I'm hitting that prevents the dACL in the ISE authz profile from overriding the default ACL applied as a pACL on the switch. This is destroying my move from monitor mode to low-impact mode, and I'm wondering if anyone has used and can recommend some good 2960S 15.x code that has worked with their radius server dACL in the past. Any insight would be very helpful.

Kind Regards,

Kevin

Kind Regards, Kevin Sheahan, CCIE # 41349
11 Replies 11

blenka
Level 3
Level 3

This error code is related to AAA functionality, I will suggest to contact SAC.

Kevin P Sheahan
Level 5
Level 5

Thanks for replying. Can you please elaborate on what your knowledge and experience is with this bug. Also, what is SAC?


Sent from Cisco Technical Support Android App

Kind Regards, Kevin Sheahan, CCIE # 41349

Kevin,

What exact IOS are you running?

Kevin P Sheahan
Level 5
Level 5

I've tried both 15.0(2)SE2, and SE4


Sent from Cisco Technical Support Android App

Kind Regards, Kevin Sheahan, CCIE # 41349

I've tried both 15.0(2)SE2, and SE4

That's disturbing.


Disturbing because the next IOS is 15.1(2)S and I haven't tested this version yet.

Kevin P Sheahan
Level 5
Level 5

I just got a 2960S for my lab today so I'm gonna test it this weekend. Hope I don't have to drop to 12 code just to make it work. This is one of the most irritating bugs I've encountered recently because everything will work beautifully for a while and then suddenly user complaints cause me to look at the switch and the default ACL is blocking random flows even though the dACL is applied. It's back in monitor mode until I can find code that works.


Sent from Cisco Technical Support Android App

Kind Regards, Kevin Sheahan, CCIE # 41349

Kevin,

If you ever need to go down to 12.X then I highly recommend 12.2(55)SE8.  Don't even bother with the rest.

Kevin P Sheahan
Level 5
Level 5

Thank you very much for that recommendation it will save me quite a bit of time and effort if I do have to downgrade to 12. I'll update the discussion with results.


Sent from Cisco Technical Support Android App

Kind Regards, Kevin Sheahan, CCIE # 41349

Keep us posted.  I'm keen to know what you'll find. 

Hi,

I am not running into this issue, but I wanted to see if moving your users from static ips over to the dhcp reservations would be out of the equation? I have a feeling that the 12.2(58) will fix this issue either as my experience with any ip device tracking with static ip addressing has been to move away from static ips...I know this doesnt help but didnt want you to hit this same issue after downgrading to 12.2(58) since that can take some time.

Thanks,

Tarik Admani
*Please rate helpful posts*

Well this is getting frustrating. dACLs are applying to the session appropriately, even with static IPs, as the first 'any' in the ACE is replaced by the host's ip address. Even with the 12.2(55)SE8 code, I'm seeing the pACL (default ACL) is still blocking very small amounts and random sets of traffic from a successfully authenticated/authorized host. I have to be out on another project tomorrow but Wednesday I will be opening a TAC case for this. I've configured this function many times I cannot imagine that it's anything but a bug but we'll see. Hard to see it as a bug if I've tried all available 15.x code releases as well as this 12.2(55)SE8 with the same results.

Any new ideas are appreciated, some notes are below.

  • ip device tracking is enabled, as well as with the use svi probe option.
  • 'show ip access-list interface g1/0/x' shows that the first 'any' in the dACL is being properly replaced by the host's ip address.
  • 90% of the time, everything works wonderfully. Randomly, the default ACL applied to the switchport for unauthenticated sessions starts blocking legitimate traffic even though the dACL is applied. I've seen IGMP, CAPWAP, HTTP, HTTPS, and other ports that are not permitted by default being blocked randomly after a dACL is applied. This condition will typically resolve itself within minutes, only to be seen again on a completely different random switch/port/session/host later on in the day.

Kind Regards,

Kevin Sheahan, CCIE # 41349

Kind Regards, Kevin Sheahan, CCIE # 41349