07-04-2021 07:33 AM
I want to profile a non cisco IP phone (that uses MAB) by LLDP System name with ISE, from the packet captures on ISE TCP Dump, I can see that the System Name is being sent in the accounting request packet (Model name is SSP2210SLT):
But I don't see any LLDP-TLV in the access-request packet.
LLDP seems to be working correctly for the interface:
SW#sh lldp neigh gi0/3 det ------------------------------------------------ Local Intf: Gi0/3 ... Port Description: eth0 System Name: SSP2210SLT ...
My question is how am I supposed to profile the device based on LLDP attributes if I can't send them via access-request packets?
Below is my AAA/LLDP config, am I missing something?
aaa new-model ! ! aaa group server radius dnac-client-radius-group server name dnac-radius_<First IP> server name dnac-radius_<Sec IP> ip radius source-interface Vlan1047 ! ! aaa authentication dot1x default group dnac-client-radius-group aaa authorization exec default local aaa authorization network default group dnac-client-radius-group aaa accounting update newinfo periodic 2880 aaa accounting identity default start-stop group dnac-client-radius-group ! ! ! ! ! aaa server radius dynamic-author client <First IP> server-key 7 <removed> client <Sec IP> server-key 7 <removed> ! device-sensor filter-list lldp list iseLLDP tlv name system-name tlv name system-description tlv name system-capabilities ! device-sensor filter-list dhcp list iseDHCP option name host-name option name parameter-request-list option name class-identifier ! device-sensor filter-list cdp list iseCDP tlv name device-name tlv name capabilities-type tlv name version-type tlv name platform-type device-sensor filter-spec dhcp include list iseDHCP device-sensor filter-spec lldp include list iseLLDP device-sensor filter-spec cdp include list iseCDP device-sensor notify all-changes ! ip device tracking probe auto-source override ip device tracking probe delay 60 ! ! access-session attributes filter-list list Def_Acct_List cdp lldp dhcp http ! ! dot1x system-auth-control dot1x critical eapol ! ! lldp run ! ! interface GigabitEthernet0/3 switchport mode access ip device tracking maximum 10 switchport voice vlan 2046 mab access-session control-direction in access-session closed access-session port-control auto authentication periodic authentication timer reauthenticate server spanning-tree portfast edge service-policy type control subscriber PD_MAB ! ! radius-server attribute 6 on-for-login-auth radius-server attribute 6 support-multiple radius-server attribute 8 include-in-access-req radius-server attribute 25 access-request include radius-server attribute 31 mac format ietf upper-case radius-server attribute 31 send nas-port-detail mac-only radius-server dead-criteria time 5 tries 3 radius-server deadtime 3 ! radius server dnac-radius_<First IP> address ipv4 First IP auth-port 1812 acct-port 1813 timeout 4 retransmit 3 key 7 <removed> ! radius server dnac-radius_<Sec IP> address ipv4 Sec IP auth-port 1812 acct-port 1813 timeout 4 retransmit 3 key 7 <removed> !
07-04-2021 08:21 AM
Hi @SMD28316 ,
please check the TLV using the:
switch#show device-sensor cache interface g0/3
Note: in ISE, you can see the TLVs if you check the Accounting Reports.
Also take a look at: Configure Device Sensor for ISE Profiling.
Hope this helps !!!
07-04-2021 10:58 AM
Hi,
That's another non-obvious thing about profiling.
You want to use Device Sensor to profile your IP Phone.
Device Sensor take CDP/LLDP/DHCP info and sends that info to ISE using Radius Accounting.
But what's not obvious is that in order to send Radius Accounting to ISE for a particular session, you have to 'authenticate' that device.
In your case, you can do something like this:
- create a profiling policy that references only the MAC OUI ('My-Phone-parent' policy = if MAC OUI is/contains my-vendor)
- create an authorization policy that references the above profiling policy and has the following result/authorization profile:
Access-Accept + voice VLAN (if required) + dACL Deny_ANY (no network access; LLDP/CDP is allowed by default for a 802.1x port)
At this point, you just 'faked' a successful authentication in a way that you 'allowed' the session (Radius Access-Accept) but actually you don't allow any traffic (Deny_ANY dACL). For this session, the switch will send accounting data
Accouting data means CDP/LLDP info that ISE receives which you use in a new child profiling (parent would be 'My-Phone-parent').
This profiling child policy will reference the extra LLDP info that you want, and will trigger a CoA event when that info is recevied by ISE.
ISE will rescan authorization rules and will match an upper authorization rule where you actually reference the new child profiling policy.
BR,
Octavian
07-05-2021 01:11 PM
> ... how am I supposed to profile the device based on LLDP attributes if I can't send them via access-request packets?
> ... am I missing something?
No, your configuration looks fine.
Profiling works asynchronously and the attributes are not sent as part of access requests. Although you are getting the attributes via accounting updates, ISE may also get them via SNMP queries of the network devices by ISE. Still, Octavian is correct that the endpoint needs be online with an active session. If ISE classifying the endpoint with a new profiling policy or group while the endpoint is online, if the change of the profiling policy or group evaluated to a new authorization policy rule, and , if ISE profiling CoA action is to re-auth or port-bounce, then ISE will trigger a CoA. If the endpoint re-authenticates later, it will also use the updated profiling policy.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide