cancel
Showing results forĀ 
Search instead forĀ 
Did you mean:Ā 

XMC - Authentication question

XMC - Authentication question

AntonioP
New Contributor II
Hello,

please apologize my English and tyvm for having this hub so we can discuss tech stuff.

Im having an issue regarding info i see on the XMC. Im not sure where to begin explaining this, but basicaly the XMC is showing me apipa IP for a given host even though im sure it has got the IP reserved for that MAC from the DHCP server. Im sure because i can ping the IP and the name of the host is resolved correctly.

Thing is, when this happens the policy configured to take effect does not apply and the end device lands on a different VLAN other than the one the policy is supposed to send ot he port.

Im not sure if this a XMC issue or something going on between the SW and the DHCP server.

I caught one of the end devices passing from the reserved dhcp IP to the apipa and this is what i see.

16a57d30f6084f878df1c929cd673964.png
10210e6720b4463eb1f0580b416cb88a.png
db5a3a76f03b472193663d644eac7397.png1e936509fe264b8f95bc423b6e2bf0bb.png
What im asking is if there is any relation or known issue between the way this device is following authentication, as i see it first tries to MAC auth and succeeds, but then goes dot1x and fails, and the fact that the XMC shows me apipa ip, even though im sure the end device got the dhcp reserved ip and i can ping it, but simply im having an issue with not landing on correct vlan.

Sorry if this is confusing.. 

Any ideas would be great. 

Thank you.
1 ACCEPTED SOLUTION

Hello,

Do you have any global subnets enabled for Router IP discovery? If the subnet is not defined these act as filters and can prevent showing the correct address. 

I think that screenshot is from policy "User Sessions" tab. Does it show the same 169 address in Control end systems tab as it does in the policy "User Sessions". Policy User sessions is a bit different from end system information from Control. 

If you see the same 169 address in Control you can try the following: 

Right click the NAC that will be handling the authentication for the end system --> WebView --> Diagnostics --> Appliance/Server Diagnostics

Set the following to "Verbose"

Authentication request processing - NAC

IP resolution

DHCP

Click OK. 

Then delete the end system in control and have the device re-authenticate. Once the link local address is seen, go back and disable diagnostics. The log will contain information on how IP resolution was determined. You can try to search the log for the actual IP address of the device, or the link local. 

Searching by last 3 octets of the mac address hyphen delimited will show all debug lines associated to the end system itself. 

Eg: 

If mac address is: 

12:34:56:11:AA:22

Search for: 

11-AA-22

The debug log may contain sensitive information so I would not suggest uploading it to this thread. 

Thanks
-Ryan

View solution in original post

8 REPLIES 8

TimS
New Contributor II
That sounds like the problem, when the printers gets to deep sleep (standby). They shutdown the gigabit interface to 100mbit/s. Try to turn off this function in the printer and it should run probably

AntonioP
New Contributor II
They say a picture is worth a thousand words, well this one is basically what im trying to figure out.

77e5fc8fe20344d789fcac068f2119ec.png

Hello,

Do you have any global subnets enabled for Router IP discovery? If the subnet is not defined these act as filters and can prevent showing the correct address. 

I think that screenshot is from policy "User Sessions" tab. Does it show the same 169 address in Control end systems tab as it does in the policy "User Sessions". Policy User sessions is a bit different from end system information from Control. 

If you see the same 169 address in Control you can try the following: 

Right click the NAC that will be handling the authentication for the end system --> WebView --> Diagnostics --> Appliance/Server Diagnostics

Set the following to "Verbose"

Authentication request processing - NAC

IP resolution

DHCP

Click OK. 

Then delete the end system in control and have the device re-authenticate. Once the link local address is seen, go back and disable diagnostics. The log will contain information on how IP resolution was determined. You can try to search the log for the actual IP address of the device, or the link local. 

Searching by last 3 octets of the mac address hyphen delimited will show all debug lines associated to the end system itself. 

Eg: 

If mac address is: 

12:34:56:11:AA:22

Search for: 

11-AA-22

The debug log may contain sensitive information so I would not suggest uploading it to this thread. 

Thanks
-Ryan

RYAN,

bullzeye. TY.

This,
4b2ac5c05bb14cec8736dfe48e2cb8df.png
adding the subnets for router ip discovery, plus this:

5864fe16329349368fa8619cccb8dc6b.png
seems to have solved my issue.
Will let you all know in a few days.

TYVM all for helping.
GTM-P2G8KFN