cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
Announcements
Choose one of the topics below to view our ISE Resources to help you on your journey with ISE

This community is for technical, feature, configuration and deployment questions.
For production deployment issues, please contact the TAC! We will not comment or assist with your TAC case in these forums.
Please see How to Ask the Community for Help for other best practices.

4064
Views
6
Helpful
9
Replies
Highlighted
Beginner

IBNS 2.0 Device Sensor Accounting

Hello together

I got a Cat2960S (15.2(2)E5) and a Cat2960X (15.2(4)E1) configured with IBNS 2.0. Everything is working fine from an authentication and authorization perspective but the switch does not send the device sensor data to ISE via RADIUS accounting. Therefore profiling for some devices is not working. The RADIUS profiling probe is activated in ISE.

In IBNS 1.0 i had to use the device-sensor accounting command, but this command is not available anymore under IBNS 2.0.

Currently I have the following device sensor and  accounting configuration:

aaa group server radius ISE
 server-private 10.40.250.234 auth-port 1812 acct-port 1813 test username RADIUS-TEST idle-time 30 key XYZ
 ip radius source-interface Vlan2030
!
aaa authentication dot1x default group ISE
aaa authorization network default group ISE
aaa accounting update newinfo periodic 5
aaa accounting identity default start-stop group ISE
!
aaa server radius dynamic-author
 client 10.40.250.234 server-key XYZ

!
device-sensor filter-list cdp list CDP-FILTER
 tlv name device-name
 tlv name platform-type
device-sensor filter-spec cdp include list CDP-FILTER
device-sensor notify all-changes
access-session attributes filter-list list DEVICE-SENSOR
 cdp
access-session accounting attributes filter-spec include list DEVICE-SENSOR

Any idea's how to get the device sensor data to ISE with IBNS 2.0? Am I missing a configuration parameter?

Best regards

Martin

1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted

FYI this fixed a profiling issue we were having with IOS XE 16.9.4. Before applying these commands ISE was not seeing the endpoints DHCP Class Identifier, afterwards everything works. Thanks!

View solution in original post

9 REPLIES 9
Highlighted
Cisco Employee

Hi Martin,

When IBNS 2.0 is used the device sensor data is not added to the radius accounting packets even after addition of the command device-sensor accounting (in some cases this command is not available after enabling IBNS 2.0 due to CSCur93458), so the following commands are needed to be added:

access-session attributes filter-list list <list name>
cdp
lldp
dhcp

access-session accounting attributes filter-spec include list <list name>

Regards,

Jatin

~ Do rate helpful posts.

~Jatin
Highlighted

Hi Jatin

Thanks for your response. As you might see in my example I already added these commands to my configuration. But I still don't see any data sent via RADIUS accounting. Any other ideas :) ?.

Best regards

Martin

Highlighted

I am also missing this command on the 3850 03.06.04.E platform while using similar config as above. When debugging radius accounting, I do not see any info sent.

Sep 28 10:19:56.587 CET: RADIUS/ENCODE(00000000):Orig. component type = Invalid
Sep 28 10:19:56.587 CET: RADIUS(00000000): Config NAS IP: 10.1.9.152
Sep 28 10:19:56.587 CET: RADIUS(00000000): Config NAS IPv6: ::
Sep 28 10:19:56.587 CET: RADIUS(00000000): sending
Sep 28 10:19:56.588 CET: RADIUS(00000000): Send Accounting-Request to 10.7.10.222:1646 id 1646/15, len 449
Sep 28 10:19:56.588 CET: RADIUS: authenticator A4 B5 14 6A 51 5E 58 A4 - FB 87 EB 9C 76 DF C6 C8
Sep 28 10:19:56.588 CET: RADIUS: Vendor, Cisco [26] 44
Sep 28 10:19:56.588 CET: RADIUS: Cisco AVpair [1] 38 "lldp-tlv= "
Sep 28 10:19:56.588 CET: RADIUS: Vendor, Cisco [26] 25
Sep 28 10:19:56.588 CET: RADIUS: Cisco AVpair [1] 19 "lldp-tlv= "
Sep 28 10:19:56.588 CET: RADIUS: Vendor, Cisco [26] 30
Sep 28 10:19:56.589 CET: RADIUS: Cisco AVpair [1] 24 "lldp-tlv= "
Sep 28 10:19:56.589 CET: RADIUS: Vendor, Cisco [26] 28
Sep 28 10:19:56.589 CET: RADIUS: Cisco AVpair [1] 22 "lldp-tlv= "
Sep 28 10:19:56.589 CET: RADIUS: Vendor, Cisco [26] 27
Sep 28 10:19:56.589 CET: RADIUS: Cisco AVpair [1] 21 "lldp-tlv= "
Sep 28 10:19:56.589 CET: RADIUS: Framed-IP-Address [8] 6 10.191.1.119
Sep 28 10:19:56.589 CET: RADIUS: User-Name [1] 14 "d4785600424a"
Sep 28 10:19:56.589 CET: RADIUS: Vendor, Cisco [26] 49
Sep 28 10:19:56.589 CET: RADIUS: Cisco AVpair [1] 43 "audit-session-id=0A0109980000117F07BE675A"
Sep 28 10:19:56.589 CET: RADIUS: Vendor, Cisco [26] 18
Sep 28 10:19:56.589 CET: RADIUS: Cisco AVpair [1] 12 "method=mab"
Sep 28 10:19:56.589 CET: RADIUS: Called-Station-Id [30] 19 "C4-14-3C-98-01-01"
Sep 28 10:19:56.589 CET: RADIUS: Calling-Station-Id [31] 19 "D4-78-56-00-42-4A"
Sep 28 10:19:56.589 CET: RADIUS: NAS-IP-Address [4] 6 10.1.9.152
Sep 28 10:19:56.590 CET: RADIUS: NAS-Port-Id [87] 22 "GigabitEthernet2/0/1"
Sep 28 10:19:56.590 CET: RADIUS: NAS-Port-Type [61] 6 Ethernet [15]
Sep 28 10:19:56.590 CET: RADIUS: NAS-Port [5] 6 50201
Sep 28 10:19:56.590 CET: RADIUS: Acct-Session-Id [44] 10 "00001598"
Sep 28 10:19:56.590 CET: RADIUS: Class [25] 58
Sep 28 10:19:56.590 CET: RADIUS: 6F C1 30 18 AF 64 47 0F 8E B3 F6 52 9F 5C 1D A4 BF 0B 00 00 00 00 00 00 52 30 30 30 33 63 36 34 30 2D [o0dGR\R0003c640-]
Sep 28 10:19:56.590 CET: RADIUS: 30 31 2D 35 37 65 62 37 64 30 66 00 00 00 00 00 00 00 00 00 00 00 [ 01-57eb7d0f]
Sep 28 10:19:56.590 CET: RADIUS: Acct-Status-Type [40] 6 Watchdog [3]
Sep 28 10:19:56.590 CET: RADIUS: Event-Timestamp [55] 6 1475050796
Sep 28 10:19:56.590 CET: RADIUS: Acct-Input-Octets [42] 6 2126
Sep 28 10:19:56.590 CET: RADIUS: Acct-Output-Octets [43] 6 9634
Sep 28 10:19:56.590 CET: RADIUS: Acct-Input-Packets [47] 6 22
Sep 28 10:19:56.590 CET: RADIUS: Acct-Output-Packets [48] 6 17
switch(config-if)#
Sep 28 10:19:56.590 CET: RADIUS: Acct-Delay-Time [41] 6 0
Sep 28 10:19:56.591 CET: RADIUS(00000000): Sending a IPv4 Radius Packet
Sep 28 10:19:56.591 CET: RADIUS(00000000): Started 5 sec timeout
Sep 28 10:19:56.597 CET: RADIUS: Received from id 1646/15 10.7.10.222:1646, Accounting-response, len 20
Sep 28 10:19:56.598 CET: RADIUS: authenticator F3 D7 97 72 A9 6C 3C 13 - C5 43 AF ED 81 3F 26 11
switch(config-if)#

Highlighted

Hi

In the debugs we can see lldp TLVs are being sent.


Sep 28 10:19:56.588 CET: RADIUS: Cisco AVpair [1] 38 "lldp-tlv= "
Sep 28 10:19:56.588 CET: RADIUS: Vendor, Cisco [26] 25
Sep 28 10:19:56.588 CET: RADIUS: Cisco AVpair [1] 19 "lldp-tlv= "
Sep 28 10:19:56.588 CET: RADIUS: Vendor, Cisco [26] 30
Sep 28 10:19:56.589 CET: RADIUS: Cisco AVpair [1] 24 "lldp-tlv= "
Sep 28 10:19:56.589 CET: RADIUS: Vendor, Cisco [26] 28
Sep 28 10:19:56.589 CET: RADIUS: Cisco AVpair [1] 22 "lldp-tlv= "
Sep 28 10:19:56.589 CET: RADIUS: Vendor, Cisco [26] 27
Sep 28 10:19:56.589 CET: RADIUS: Cisco AVpair [1] 21 "lldp-tlv= "

On the switch, this is how it is shown in the debugs. If you want to see the TLVs then you can do 'show device-sensor cache mac <>'. Also in ISE, you can see the TLVs if you check the accounting reports.

Thanks

Vishal

Highlighted

Hi Jatin

We had the similar issue. After enabling the above mentioned commands sensor seems to be working however cannot view the dhcp infor sent via radius accounting. Only cdp and lldp is sent. Have you seen this issue?

Note we are running 3.7.3 code 3850

Thanks

Gaj

Highlighted

Hi Gaj

Can you check if 'ip dhcp snooping' and 'ip dhcp snooping vlan <>' are enabled? We need that for dhcp attributes to be cached and sent.

Thanks

Vishal

Highlighted

FYI this fixed a profiling issue we were having with IOS XE 16.9.4. Before applying these commands ISE was not seeing the endpoints DHCP Class Identifier, afterwards everything works. Thanks!

View solution in original post

Highlighted

If you don't want to use dhcp snooping, ip helpers on the l3 interfaces (physical or SVI) will accomplish the same thing.

 

Dhcp snooping is the only way to get dhcp informstion via the device sensor/radius probe.

 

Pretty common for a deployment to use both, or choosing just ip helper. 

Highlighted

We use dhcp snooping to support arp inspection anyways, it was nice to turn off the helpers and the DHCP probe.
Isn't dhcp snooping required for device tracking to work anyways?