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

Who Me Too'd this topic

802.1x | DHCP BAD_ADDRESS | IP Conflict 0.0.0.0

yaplej
Level 1
Level 1

Hello,

We are experiencing a lot of BAD_ADDRESSES in our DHCP scopes where 802.1x is enabled.  The problem seems to stem from IPDT or Device Tracking depending on the version of IOS you have.  This is not a unique issue to me.

https://supportforums.cisco.com/t5/security-and-network-management/ise-802-1x-ip-conflict-at-0-0-0-0/td-p/2066699

 

There have been several proposed solutions:

https://www.cisco.com/c/en/us/support/docs/ios-nx-os-software/8021x/116529-problemsolution-product-00.html

 

So far nothing has worked in our environment.

 

The "probe delay" seems like it would be the easiest solution and it seems like that works mostly but only when there is a single switch/management-point for the site.  When there are multiple switches or "stacks" each sending their own device tracking probes the problem seems to surface again.

 

The "use-svi" method does not work because our switches are L2-only so there is no SVI in the same VLAN/subnet as the 802.1x authenticated devices.  We have the management SVI on a seprate/dedicated VLAN.

 

We have also disabled GARP on our Windows machines trying to stem this DHCP BAD_ADDRESS issue but we are coming up with nothing.

 

I was wondering if anyone else has seen and could confirm that what I am seeing is expected.

 

The "auto-source fallback override" solution MIGHT be the only working solution in our type of environment where there are multiple L2-only access switches.  I have not gotten myself enough of the 3850 switches to verify this but I am working on that.  The plan is to use a single assigned address for all device tracking probes.  I really hope that works so I dont need to use an seprate auto-source fallback address for each switch.

 

 

Who Me Too'd this topic