If you look in the Windows event log (I forget which one) an IP conflict will be recorded along with the Mac address of the machine causing the conflict...
From: Cisco Clean Access Users and Administrators [mailto:[EMAIL PROTECTED] On Behalf Of Justin Howell Sent: Tuesday, April 01, 2008 12:47 To: [email protected] Subject: Re: Weird Dead IP Problem Hi Max, I've done some sniffs and traffic does not seem to make it past the CAS. I see the requests leave the client but they don't seem to go anywhere, like the CAS is not passing them. I'm planning on doing more sniffs to try and find out what's going on, just haven't gotten to them yet. Another strange wrinkle ... the previous 'bad' IP addresses we had excluded ... just for kicks, I hard-coded those to a couple of clients and now they both work perfectly fine. How bizarre. So we get an occasional bad IP, but it doesn't stay bad forever. That's sounding more and more like a conflict ... Justin Howell Telecommunications Network Technician Solano Community College From: Cisco Clean Access Users and Administrators [mailto:[EMAIL PROTECTED] On Behalf Of Caines, Max Sent: Tuesday, April 01, 2008 9:18 AM To: [email protected] Subject: Re: Weird Dead IP Problem Hi Justin Have you tried sniffing the network to see what's happening at layer 2? For example, are name lookups working on the client? If no, does the DNS server see them and respond? If yes, does the CAS see the HTTP requests and what happens to its responses? Regards Max Caines IT Services, University of Wolverhampton Wolverhampton, West Midlands WV1 1SB Tel: 01902 322245 Fax: 01902 322777 ________________________________ From: Cisco Clean Access Users and Administrators [mailto:[EMAIL PROTECTED] On Behalf Of Justin Howell Sent: 01 April 2008 16:50 To: [email protected] Subject: [CLEANACCESS] Weird Dead IP Problem OK, here's a strange one, maybe someone's seen this. Our original CAS setup was one managed subnet, class C, 172.16.6.0/24 to be exact. Real IP Gateway, In-Band deployment. The untrusted interface of the CAS and default route for the managed subnet was 172.16.6.1. Over the past two yeara, we would suddenly come up with a computer that would pull a particular IP, and with that IP, could not communicate with the CAS or any part of the network; it was like the IP was blacklisted or in conflict. DNS would not resolve; if I put in the IP of the CAS, I could get to the login portal, but when I tried to download the agent, it would timeout. No other network resources could be accessed, even those allowed by the unauthenticated role. Cisco of course blamed our network, that it was an IP problem on our network. Their solution was to break the managed subnet into two chunks, and exclude the offending IP. The computer would finally pull a different IP, and all would be well. The problem is, this problem keeps happening. It's currently broken into three different subnet chunks. And now this morning, we've got another IP that is not communicating with the CAS. The problem is, with every new chunk made, it requires its own default gateway; the CAS DHCP pages do not allow me to reuse the existing gateway. So each 'bad' IP we've got to exclude results in losing it and another IP for a gateway from our pool. We've got enough IPs for the moment, but this is getting annoying. We have another DHCP server for clients not on Clean Access, but it does not have a pool for the 172.16.6.0 subnet, so theoretically the only way this problem could be caused by an IP conflict would be a user on that subnet hard-coding an address. But they would still be on the clean access subnet, still have to authenticate/remediate, so I should see them on Users page or the event logs. Any one seen this? Or have suggestions? Cisco was not very helpful last time I called ("Just make two subnets - that IP problem is your problem not Clean Access's") so I'm hesitant to open another TAC and spend my week on the phone. Justin Howell Telecommunications Network Technician Solano Community College (707) 864-7205
