first time CoA

[edondurguti]

I have this problem where first time users hit default reject profile because they are not being profiled. They remain unknown until i reconnect. Can this be because of the access point is 1231 converted to lightweight. (it does support change of vlan though). I have CoA set to ReAuth. Still not sure if this is a packet of disconnect issue with that AP. if someone faced this id appreciate the help

Sent from Cisco Technical Support iPhone App

[edondurguti]

I do have profiling enabled

here are the files

btw, do i need to do debugging from secondary ( cuz the secondary node is set as the primary monitoring role)

https://dl.dropbox.com/u/75261564/ise.logs.zip

[Tarik Admani]

Hi,

We are taking the logs from the node itself, the monitoring node is for the authentications.

Thanks,

Tarik Admani
*Please rate helpful posts*

[edondurguti]

done,

got it from the primary are you able to download the files?

[Tarik Admani]

I downloaded them, do you have a screenshot of the timeframe on when you reproduced the issue?

I would like get the timestamps and mac on when you attempted it.

disregard, i just opened the zip file.

Thanks,

Tarik Admani
*Please rate helpful posts*

[edondurguti]

they are on the sides for authorization, it's all withing 3 minutes

[Tarik Admani]

You sent me the prrt.log files I need the profiler.log file.

Thanks,

Tarik Admani
*Please rate helpful posts*

[edondurguti]

https://dl.dropbox.com/u/75261564/ise.logs.zip

there you go

[edondurguti]

oh my bad cuz it's above it kinda messed up rows, give me a sec

[edondurguti]

let me know if you got them

https://dl.dropbox.com/u/75261564/ise.logs.zip so i can delete the files

[edondurguti]

I also get emails as alarms saying

Dynamic Authorization Failed for Device:WLC-PRIMARY

[Tarik Admani]

Hi,

Your best bet is to open a tac case, after looking through the logs I dont see the profiler log capturing radius even that occured at 11:09, it seems as if the endpoint was created well before the debugs were turned on because there is an endpoint id assigned.

If I were you, i would open a tac case and reproduce the issue with a packet capture from the WLC (you can go to monitor > tools > tcpdump) you can filter using ip host (wlcipadd). Provide this information to tac along with the screenshots that you provided and you should get a quick turnaround.

If you want to debug this yourself you can, the endpoint id is (d18c8261-e7bc-11e1-95b6-5cf3fc25cfa8) and when you see the entries in the profiler.log that match this condition you can see they are all endpoint updates (starting at 11:10:42), there isnt an add which tells me that something may have got dropped internally in the profiler process.

Also are you running on a appliance (because i see some probes enabled on gig3...can you verify this and turn off any probes that you arent using.

Tarik Admani
*Please rate helpful posts*

[edondurguti]

Tarik,

thanks for your reply, yes it's in the appliance, and it showed that because the probes were enabled on all interfaces thats why it showed as failing.

P.s this ID

d18c8261-e7bc-11e1-95b6-5cf3fc25cfa8 I do not see it in this file:

[first]profiler.log

I do see it in the second one though, and it is because it worked the second time.

[edondurguti]

012-08-16 10:33:59,222 INFO  2012-08-16 10:33:59,222  [CoAHandler][] cisco.profiler.infrastructure.profiling.CoAHandler- Skip CoA for DISCONNECTED end point 00:26:C6:6A:DE:22 (policy Workstation)

this is what I saw too

[edondurguti]

Tarik,

I did not open a case with TAC yet becuase i am trying to figure it out myself, I think there is like a bug in the database or something because some things look weird and this is what i've found:

I have created some custom profiles with custom attributes like check for FQDN and all that, and then I have deleted them.

I've done the profile log ( thnx for the heads up) and I've found some errors and why the first time users get in can't be profiled:

It is trying to profile it with previous rules which I have deleted and are now still the the database somehow, I do not know how to solve this but here is the log part:

This is what is says first:

Caused by: Can not delete the rule with fqn NAC Group:NAC:PROFILERCheck_Test_for_fqdnRule4603716b-e44d-4b01-9308-2826829a79bcCheck7f9b8a99-9cdd-4402-b769-c85e4d38722f this is being refered by other rules [6e0b40d0-e322-11e1-ba0b-5cf3fc25cfa8,PROFILERRule_Test_for_fqdnRule4603716b-e44d-4b01-9308-2826829a79bc,]; nested exception is:

then:

Name:Microssssoft

FullName:TEST_FOR_FQDN

Description:this is the test for microsoft

MinimumCertaintyMetric:10

ActionId:

ScanActionId:6ed0fa70-be86-11e1-ba69-0050568e002b

ParentId:

Enabled:true

HasIdentityGrp:true

IdentityGrpID:79efb500-e310-11e1-ba0b-5cf3fc25cfa8

PolicyRules:{Test_for_fqdnRule4603716b-e44d-4b01-9308-2826829a79bc=-3}

:Unable to update EndpointPolicy. Unable to create / update EndpointPolicy. Rule must contain atleast one Check.

com.cisco.profiler.common.ProfilerException: Unable to update EndpointPolicy. Unable to create / update EndpointPolicy. Rule must contain atleast one Check.

    at com.cisco.profiler.api.EndpointPolicyHandler.update(EndpointPolicyHandler.java:320)

This Rule doesn't exist anymore, and when they show up in authorization as you can see from the screenshots above when users first hit the ISE (they do not have any identity group assigned to it)

[edondurguti]

it's not collecting logs anymore I think, i'll rebooted it and probably reset the whole thing :]