cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4073
Views
25
Helpful
16
Replies

3560CX Radius packets to ISE do not contain VSAs learned from CDP or LLDP. ISE not profiling correctly. Using MAB.

jawesterholm
Level 1
Level 1

I have a daisy chained 7965 phone and a laptop.  Laptop dot1x is functional.  Phone will not authorize correctly in ISE, it is being profiled as a 'Cisco-Device'.  When reviewing log in ISE, no cdp or lldp information is being provided.  Switch configs are:

 

Cisco IOS Software, C3560CX Software (C3560CX-UNIVERSALK9-M), Version 15.2(6)E1, RELEASE SOFTWARE (fc4)

 

aaa new-model
!
!
aaa group server tacacs+ BORAAAservers
server name BORAAAserver1
server name BORAAAserver2
!
aaa group server radius BORISE
server name IBR5LCRLXISE01R
server name IBR5DENLXISE01R
ip radius source-interface Vlan99
!
aaa authentication login BORNet group BORAAAservers local
aaa authentication dot1x default group radius
aaa authorization exec BORNet group BORAAAservers if-authenticated
aaa authorization commands 15 BORNet group BORAAAservers if-authenticated
aaa authorization network default group radius
aaa accounting dot1x default start-stop group radius
aaa accounting exec BORNet start-stop group BORAAAservers
aaa accounting commands 15 BORNet start-stop group BORAAAservers
aaa accounting network BORNet start-stop group BORAAAservers
aaa accounting connection BORNet start-stop group BORAAAservers
aaa accounting system default start-stop group BORAAAservers
!

!
aaa server radius dynamic-author
client 140.216.20.193 server-key 7xxx
client 140.215.24.14 server-key 7 xxx

 

device-sensor accounting
device-sensor notify all-changes

access-session template monitor
epm logging

lldp run

 

interface GigabitEthernet0/1
description GPR-Users
switchport access vlan 105
switchport mode access
switchport voice vlan 205
srr-queue bandwidth share 1 30 35 5
priority-queue out
authentication event fail action next-method
authentication event server dead action reinitialize vlan 105
authentication event server dead action authorize voice
authentication event server alive action reinitialize
authentication host-mode multi-auth
authentication order mab dot1x
authentication priority dot1x mab
authentication port-control auto
authentication violation restrict
mab
mls qos trust device cisco-phone
mls qos trust cos
dot1x pae authenticator
dot1x timeout tx-period 10
auto qos voip cisco-phone
spanning-tree portfast edge
service-policy input AUTOQOS-SRND4-CISCOPHONE-POLICY

 

ip device tracking

logging origin-id ip
logging facility local1
logging source-interface Vlan99
logging host 140.215.27.38
logging host 140.219.22.2
logging host 140.216.20.193 transport udp port 20514
logging host 140.215.24.14 transport udp port 20514

 

 

snmp-server group ise-group v3 auth

radius-server attribute 6 on-for-login-auth
radius-server attribute 8 include-in-access-req
radius-server attribute 25 access-request include
radius-server attribute 31 mac format ietf
radius-server dead-criteria time 5 tries 3

 

radius server IBR5LCRLXISE01R
address ipv4 140.216.20.193 auth-port 1812 acct-port 1813
key 7 xxx
!
radius server IBR5DENLXISE01R
address ipv4 140.215.24.14 auth-port 1812 acct-port 1813
key 7 xxx

----------------------------------------------

Show device-sensor cache int gig 0/1:

Device: 7cad.7421.eec0 on port GigabitEthernet0/1
--------------------------------------------------
Proto Type:Name Len Value
LLDP 8:management-address 14 10 0C 05 01 8C DB CD 9F 01 00 00 00 00 00
LLDP 0:end-of-lldpdu 2 00 00
LLDP 127:organizationally-specific 6 FE 04 00 12 BB 0B
LLDP 7:system-capabilities 6 0E 04 00 24 00 24
LLDP 6:system-description 46 0C 2C 43 69 73 63 6F 20 49 50 20 50 68 6F 6E 65
20 37 39 36 35 47 2C 56 31 31 2C 20 53 43 43 50
34 35 2E 39 2D 34 2D 32 53 52 33 2D 31 53
LLDP 5:system-name 29 0A 1B 53 45 50 37 43 41 44 37 34 32 31 45 45 43
30 2E 62 6F 72 2E 64 6F 69 2E 6E 65 74
LLDP 4:port-description 9 08 07 53 57 20 50 4F 52 54
LLDP 3:time-to-live 4 06 02 00 B4
LLDP 2:port-id 18 04 10 07 37 43 41 44 37 34 32 31 45 45 43 30 3A
50 31
LLDP 1:chassis-id 8 02 06 05 01 8C DB CD 9F
CDP 2:address-type 17 00 02 00 11 00 00 00 01 01 01 CC 00 04 8C DB CD
9F
CDP 16:power-type 6 00 10 00 06 2E E0
CDP 11:duplex-type 5 00 0B 00 05 01
CDP 25:power-request-type 12 00 19 00 0C EE C0 00 03 00 00 2E E0
CDP 28:secondport-status-type 7 00 1C 00 07 00 01 83
CDP 6:platform-type 23 00 06 00 17 43 69 73 63 6F 20 49 50 20 50 68 6F
6E 65 20 37 39 36 35
CDP 5:version-type 22 00 05 00 16 53 43 43 50 34 35 2E 39 2D 34 2D 32
53 52 33 2D 31 53
CDP 4:capabilities-type 8 00 04 00 08 00 00 04 90
CDP 3:port-id-type 10 00 03 00 0A 50 6F 72 74 20 31
CDP 1:device-name 19 00 01 00 13 53 45 50 37 43 41 44 37 34 32 31 45
45 43 30

 

Debug Radius:

RADIUS(00000000): Send Access-Request to 140.216.20.193:1812 onvrf(0) id 1645/147, len 264
RADIUS: authenticator 7A 4C 52 F6 5E 23 A8 03 - 21 84 89 4A 72 5D F7 48
RADIUS: User-Name [1] 14 "7cad7421eec0"
RADIUS: User-Password [2] 18 *
RADIUS: Service-Type [6] 6 Call Check [10]
RADIUS: Vendor, Cisco [26] 31
RADIUS: Cisco AVpair [1] 25 "service-type=Call Check"
RADIUS: Framed-MTU [12] 6 1500
RADIUS: Called-Station-Id [30] 19 "70-0B-4F-22-C8-81"
RADIUS: Calling-Station-Id [31] 19 "7C-AD-74-21-EE-C0"
RADIUS: Message-Authenticato[80] 18
RADIUS: 49 6E F7 0C 4A D9 C6 5E 4F C2 8A FB 49 F0 92 54 [ InJ^OIT]
RADIUS: EAP-Key-Name [102] 2 *
RADIUS: Vendor, Cisco [26] 49
RADIUS: Cisco AVpair [1] 43 "audit-session-id=8CDB63E500000036051DFDC9"
RADIUS: Vendor, Cisco [26] 18
RADIUS: Cisco AVpair [1] 12 "method=mab"
RADIUS: Framed-IP-Address [8] 6 140.219.205.159
RADIUS: NAS-IP-Address [4] 6 140.219.99.229
RADIUS: NAS-Port-Id [87] 20 "GigabitEthernet0/1"
RADIUS: NAS-Port-Type [61] 6 Ethernet [15]
RADIUS: NAS-Port [5] 6 50101
RADIUS(00000000): Sending a IPv4 Radius Packet
RADIUS(00000000): Started 5 sec timeout

RADIUS: Received from id 1645/147 140.216.20.193:1812, Access-Reject, len 38

 

Have tried deleting endpoint in ISE, no change.

Attached failure log from ISE

 

I have seen logs from other people on the web that contain additional VSA attribute 26 ub-types, such as Platform and System Description, which ISE uses to profile as Cisco IP Phone.  I have also added ISE ip helper addresses to the Voice VLAN interface.  No change.

 

Suggestions?  I have a TAC open but am getting no where with it.

1 Accepted Solution

Accepted Solutions

Hi

Device Sensor attributes (dhcp/cdp and lldp) are only sent in accounting packets after a client has been authenticated successfully by ISE.

 

The link below shows the type of attributes collected by the ISE RADIUS probe (it also states that the ISE RADIUS probe can collect cdp/lldp attributes only after a client has been authenticated

 

https://www.network-node.com/blog/2016/1/2/ise-20-profiling

 

If you can get the DHCP probe to work, ISE can profile the phone as a generic Cisco-ip-phone (using the dhcp-class-identifier attribute in the dhcp request). If you have an ISE authorization policy that successfully authenticates Cisco-ip-phone endpoints then the authenticating switch will start sending RADIUS accounting packets (which will include device-sensor cdp/lldp attributes allowing ISE to specifically profile the phone as a particular method).

 

For ISE to get CDP/LLDP information about a phone prior to it being authenticated successfully you will have to use the ISE SNMP Query probe.

hth
Andy

View solution in original post

16 Replies 16

paul
Level 10
Level 10

The device-sensor packets aren't sent via RADIUS authentication packets.  They are sent via RADIUS accounting.  You are missing:

 

aaa accounting update newinfo

 

This allows the switch to send accouting updates as it learns new information about a device.  You also set it for periodic updates as well.

Thanks for the reply.

I redid the aaa new model with the command added.
deleted endpoint in ISE
unplugged and plugged in IP phone 7965.
Same result. I have a slew of debugging turned on.

Also, if device-sensor does not pass cdp and lldp info to Radius....how
does Radius get the cisco avpair information to pass to ISE?

135480: Jan 18 12:44:33.614 MST: mab-ev: [7cad.7421.eec0, Gi0/1] Received
MAB context create from AuthMgr
135481: Jan 18 12:44:33.614 MST: mab-ev: MAB authorizing 7cad.7421.eec0
135482: Jan 18 12:44:33.614 MST: mab-ev: Created MAB client context
0x8700003A
135483: Jan 18 12:44:33.614 MST: mab : initial state mab_initialize has
enter
135484: Jan 18 12:44:33.614 MST: mab-ev: [7cad.7421.eec0, 140.219.205.159,
Gi0/1] Sending create new context event to EAP from MAB for 0x8700003A
(7cad.7421.eec0)
135485: Jan 18 12:44:33.617 MST: mab-ev: [7cad.7421.eec0, 140.219.205.159,
Gi0/1] MAB authentication started for 0x0E86E3A8 (7cad.7421.eec0)
135486: Jan 18 12:44:33.617 MST: AUTH-EVENT: [7cad.7421.eec0,
140.219.205.159, Gi0/1] Stopping restart timer if it is running as session
is no longer in AUTHZ_FAIL state - client 7cad.7421.ee
135487: Jan 18 12:44:33.617 MST: AUTH-EVENT: [7cad.7421.eec0,
140.219.205.159, Gi0/1] Client 7cad.7421.eec0, Context changing state from
'Authz Failed' to 'Running'
135488: Jan 18 12:44:33.617 MST: AUTH-EVENT: [7cad.7421.eec0,
140.219.205.159, Gi0/1] Client 7cad.7421.eec0, Method mab changing state
from 'Not run' to 'Running'
135489: Jan 18 12:44:33.617 MST: AUTH-EVENT: [7cad.7421.eec0,
140.219.205.159, Gi0/1] Policy processing started for
0xB900002C(7cad.7421.eec0)
135490: Jan 18 12:44:33.617 MST: AUTH-EVENT: [7cad.7421.eec0,
140.219.205.159, Gi0/1] Policy event will be processed synchronously for
0xB900002C
135491: Jan 18 12:44:33.617 MST: AUTH-EVENT: [7cad.7421.eec0,
140.219.205.159, Gi0/1] Authorization profile successfully applied for the
event Identity Update
135492: Jan 18 12:44:33.617 MST: AUTH-EVENT: Raising ext evt AuthZ Success
(21) on session 0xB900002C, client (unknown) (0), hdl 0x00000000, attr_list
0x00000000
135493: Jan 18 12:44:33.617 MST: AUTH-EVENT: [7cad.7421.eec0,
140.219.205.159, Gi0/1] Processing default action(s) for event
SESSION_STARTED for session 0xB900002C.
135494: Jan 18 12:44:33.617 MST: AUTH-EVENT: [7cad.7421.eec0,
140.219.205.159, Gi0/1] Handling external PRE event AuthZ Success for
context 0xB900002C.
135495: Jan 18 12:44:33.617 MST: AUTH-EVENT: Event id 27 is reported but
not defined in history queue for handle B900002C
135496: Jan 18 12:44:33.617 MST: mab-ev: [7cad.7421.eec0, 140.219.205.159,
Gi0/1] Invalid EVT 9 from EAP
135497: Jan 18 12:44:33.617 MST: mab-sm: [7cad.7421.eec0, 140.219.205.159,
Gi0/1] Received event 'MAB_CONTINUE' on handle 0x8700003A
135498: Jan 18 12:44:33.617 MST: mab : during state mab_initialize, got
event 1(mabContinue)
135499: Jan 18 12:44:33.617 MST: @@@ mab : mab_initialize -> mab_authorizing
135500: Jan 18 12:44:33.617 MST: mab-ev: [7cad.7421.eec0] formatted mac =
7cad7421eec0
135501: Jan 18 12:44:33.617 MST: mab-ev: [7cad.7421.eec0] created mab
pseudo dot1x profile dot1x_mac_auth_7cad.7421.eec0
135502: Jan 18 12:44:33.621 MST: mab-ev: [7cad.7421.eec0, 140.219.205.159,
Gi0/1] Starting MAC-AUTH-BYPASS for 0x8700003A (7cad.7421.eec0)
135503: Jan 18 12:44:33.621 MST: mab-ev: [7cad.7421.eec0, 140.219.205.159,
Gi0/1] Invalid EVT 9 from EAP
135504: Jan 18 12:44:33.621 MST: RADIUS/ENCODE(00000000):Orig. component
type = Invalid
135505: Jan 18 12:44:33.621 MST: RADIUS(00000000): Config NAS IP:
140.219.99.229
135506: Jan 18 12:44:33.621 MST: RADIUS(00000000): Config NAS IPv6: ::
135507: Jan 18 12:44:33.621 MST: RADIUS(00000000): sending
135508: Jan 18 12:44:33.621 MST: RADIUS: Message Authenticator encoded
135509: Jan 18 12:44:33.621 MST: RADIUS(00000000): Send Access-Request to
140.216.20.193:1812 onvrf(0) id 1645/102, len 264
135510: Jan 18 12:44:33.621 MST: RADIUS: authenticator 3C 12 09 E4 5E 05
C9 19 - A4 A3 34 D6 3E 63 5D 73
135511: Jan 18 12:44:33.621 MST: RADIUS: User-Name [1] 14
"7cad7421eec0"
135512: Jan 18 12:44:33.621 MST: RADIUS: User-Password [2] 18 *
135513: Jan 18 12:44:33.621 MST: RADIUS: Service-Type [6] 6
Call Check [10]
135514: Jan 18 12:44:33.621 MST: RADIUS: Vendor, Cisco [26] 31
135515: Jan 18 12:44:33.621 MST: RADIUS: Cisco AVpair [1] 25
"service-type=Call Check"
135516: Jan 18 12:44:33.624 MST: RADIUS: Framed-MTU [12] 6 1500
135517: Jan 18 12:44:33.624 MST: RADIUS: Called-Station-Id [30] 19
"70-0B-4F-22-C8-81"
135518: Jan 18 12:44:33.624 MST: RADIUS: Calling-Station-Id [31] 19
"7C-AD-74-21-EE-C0"
135519: Jan 18 12:44:33.624 MST: RADIUS: Message-Authenticato[80] 18
135520: Jan 18 12:44:33.624 MST: RADIUS: 62 6C 6F A4 D5 12 B3 01 3B 41 6D
11 12 3E AE FD [ blo;Am>]
135521: Jan 18 12:44:33.624 MST: RADIUS: EAP-Key-Name [102] 2 *
135522: Jan 18 12:44:33.624 MST: RADIUS: Vendor, Cisco [26] 49
135523: Jan 18 12:44:33.624 MST: RADIUS: Cisco AVpair [1] 43
"audit-session-id=8CDB63E50000003C05CBF1BB"
135524: Jan 18 12:44:33.624 MST: RADIUS: Vendor, Cisco [26] 18
135525: Jan 18 12:44:33.624 MST: RADIUS: Cisco AVpair [1] 12
"method=mab"
135526: Jan 18 12:44:33.624 MST: RADIUS: Framed-IP-Address [8] 6
140.219.205.159
135527: Jan 18 12:44:33.624 MST: RADIUS: NAS-IP-Address [4] 6
140.219.99.229
135528: Jan 18 12:44:33.624 MST: RADIUS: NAS-Port-Id [87] 20
"GigabitEthernet0/1"
135529: Jan 18 12:44:33.624 MST: RADIUS: NAS-Port-Type [61] 6
Ethernet [15]
135530: Jan 18 12:44:33.624 MST: RADIUS: NAS-Port [5] 6
50101
135531: Jan 18 12:44:33.624 MST: RADIUS(00000000): Sending a IPv4 Radius
Packet
135532: Jan 18 12:44:33.624 MST: RADIUS(00000000): Started 5 sec timeout
135533: Jan 18 12:44:33.684 MST: RADIUS: Received from id 1645/102
140.216.20.193:1812, Access-Reject, len 38
135534: Jan 18 12:44:33.684 MST: RADIUS: authenticator 5E 0F E9 11 C5 C2
ED 91 - 9C F5 5A 18 C6 71 A6 0B
135535: Jan 18 12:44:33.684 MST: RADIUS: Message-Authenticato[80] 18
135536: Jan 18 12:44:33.684 MST: RADIUS: 05 90 63 66 8A 83 B9 0D 11 40 CB
88 65 5E E4 EE [ cf@e^]
135537: Jan 18 12:44:33.684 MST: RADIUS(00000000): Received from id 1645/102
135538: Jan 18 12:44:33.684 MST: mab-ev: [7cad.7421.eec0, 140.219.205.159,
Gi0/1] MAB received an Access-Reject for 0x8700003A (7cad.7421.eec0)
135539: Jan 18 12:44:33.684 MST: %MAB-5-FAIL: Authentication failed for
client (7cad.7421.eec0) on Interface Gi0/1 AuditSessionID
8CDB63E50000003C05CBF1BB
135540: Jan 18 12:44:33.684 MST: mab-sm: [7cad.7421.eec0, 140.219.205.159,
Gi0/1] Received event 'MAB_RESULT' on handle 0x8700003A
135541: Jan 18 12:44:33.684 MST: mab : during state mab_authorizing,
got event 5(mabResult)
135542: Jan 18 12:44:33.684 MST: @@@ mab : mab_authorizing -> mab_terminate
135543: Jan 18 12:44:33.687 MST: mab-ev: [7cad.7421.eec0, 140.219.205.159,
Gi0/1] Deleted credentials profile for 0x8700003A
(dot1x_mac_auth_7cad.7421.eec0)
135544: Jan 18 12:44:33.687 MST: mab-ev: [7cad.7421.eec0, 140.219.205.159,
Gi0/1] Added username (7cad7421eec0) in mab for 0x8700003A
135545: Jan 18 12:44:33.687 MST: AUTH-EVENT: [7cad.7421.eec0,
140.219.205.159, Gi0/1] Authc failure from MAB (2), status Cred Fail (1) /
event fail (1)
135546: Jan 18 12:44:33.687 MST: AUTH-EVENT: [7cad.7421.eec0,
140.219.205.159, Gi0/1] Highest prio method: INVALID, Authz method:
INVALID, Conn hdl: mab
135547: Jan 18 12:44:33.687 MST: AUTH-EVENT: [7cad.7421.eec0,
140.219.205.159, Gi0/1] Client 7cad.7421.eec0, Method mab changing state
from 'Running' to 'Authc Failed'

The attached picture shows Cisco VSAs which contain platform, system description, etc.  Link to webpage is https://www.cisco.com/c/en/us/support/docs/security/identity-services-engine/200292-Configure-Device-Sensor-for-ISE-Profilin.html#anc6

 

 

 

Capture.PNG

 

Above shows the cisco avpairs being sent to radius.  nothing included to get it passed Cisco-Device in ISE (e.g. platform)

INVALID, Conn hdl: mab
135547: Jan 18 12:44:33.687 MST: AUTH-EVENT: [7cad.7421.eec0,
140.219.205.159, Gi0/1] Client 7cad.7421.eec0, Method mab changing state
from 'Running' to 'Authc Failed'



Looks like you are rejecting it in ISE. You should never be rejecting any connections.


You can't deny access to the network in an ISE install. You won't allow ISE to profile which is probably why you aren't getting the data. Your default rule should be Access-Accept with a DACL that limits access to the DNS and ISE PSNs only.


Hello, I have a dACL applied to the authorization profile with permit all, just to try to get it working.

 

Capture.PNG

 

 

Hi

 

What profiling probes do you have enabled on your ISE PSN nodes?

 

Adding ISE PSN as a helper address should give enough attributes for ISE to profile a phone as a generic Cisco-ip-phone.

 

To profile a phone as a particular model, ISE will need CDP/LLDP attributes. ISE can get these attributes by:

 

  1. If you have an ISE authorisation policy that permits access to generic cisco-ip-phones then ISE will learn the CDP/LLDP attributes when they are sent in accounting packets
  2. ISE can send an snmp query probe to collect the attributes from the switch

 

See the following document for enabling and setting up the DHCP/SNMP query probes on ISE

hth
Andy

 

https://community.cisco.com/t5/security-documents/ise-profiling-design-guide/ta-p/3739456

Hello, 

We use Radius Probe.  I added the configs for Radius per the link provided but still not being profiled correctly.  I still don't understand why the CDP/LLDP information containing the required avpairs are not being sent.  I also previously set up device-sensor lists to no avail.  Per the link you provided:  

The RADIUS probe also collects attributes sent in RADIUS accounting packets by the Device Sensor feature. This feature is covered in detail later in this guide under the Device Sensor section. You may also refer to Device Sensor - Catalyst Supported Platforms.  

 

I don't understand why my switch is not sending ISE cdp and lldp tlv info such as Platform and System Description as below.

 

Capture.PNG

Hi

Device Sensor attributes (dhcp/cdp and lldp) are only sent in accounting packets after a client has been authenticated successfully by ISE.

 

The link below shows the type of attributes collected by the ISE RADIUS probe (it also states that the ISE RADIUS probe can collect cdp/lldp attributes only after a client has been authenticated

 

https://www.network-node.com/blog/2016/1/2/ise-20-profiling

 

If you can get the DHCP probe to work, ISE can profile the phone as a generic Cisco-ip-phone (using the dhcp-class-identifier attribute in the dhcp request). If you have an ISE authorization policy that successfully authenticates Cisco-ip-phone endpoints then the authenticating switch will start sending RADIUS accounting packets (which will include device-sensor cdp/lldp attributes allowing ISE to specifically profile the phone as a particular method).

 

For ISE to get CDP/LLDP information about a phone prior to it being authenticated successfully you will have to use the ISE SNMP Query probe.

hth
Andy

As I have stated in my other two responses your bottom rule in your MAB policy should be Access-Accept with DACL to allow DNS and access to PSNs. This is what your MAB should look like (obviously only showing printers and phones):



If profiled as printer then apply Printer policy

Else if profiled as IP phone then IP phone policy

Else apply Limited_Access policy






 

Hi

 

I overlooked another method of ISE getting cdp/lldp attributes (as well as dhcp and vlan id) - I remembered this method today after I broke it on a development switch when I downgraded to an IOS where it doesn't work.

 

I'm using IBNS 2.0 new style config - I'm not sure whether this is available on legacy style which you seem to be using. Documentation for configuring this method for vlan-id is below:

 

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_usr_8021x/configuration/15-e/sec-usr-8021x-15-e-book/sec-vlan-dot1x-auth-request.html

 

I'm using the following to send device-sensor cdp/lldp and dhcp data (as well as vlan-id) to ISE when a device authenticates

 

access-session attributes filter-list list <LIST-NAME>
vlan-id
cdp
lldp
dhcp
!
access-session authentication attributes filter-spec include list <LIST-NAME>
access-session accounting attributes filter-spec include list <LIST-NAME>

 

hth
Andy

Do you see the VLAN ID show up under the endpoint in context visibility? I have that enabled as well and I don't see the VLAN ID under the endpoint.


Hi

 

No, I don't see the vlan-id under ISE (2.3 patch 5) context visibility but I can see it listed as a ciscoAVpair in the live logs.

 

My dev switch is a WS-C3650-48PD currently running 16.6.4a.

 

With the "access-session attributes filter-list" containing cdp, lldp, dhcp and vlan-id the ISE live logs showed the following (the client vlan-id should be 100 but is listed as 0):

 

cts-pac-opaque=****,
service-type=Call Check,
audit-session-id=0A2F6E050000000FA95C42B2,
method=mab,
vlan-id=0

 

When I removed vlan-id from the "access-session attributes filter-list", vlan-id (100) was displayed correctly in the live logs:

 

CiscoAVPair cts-pac-opaque=****,
service-type=Call Check,
audit-session-id=0A2F6E050000000EA95A5E10,
method=mab,
vlan-id=100

 

Cheers
Andy