OK I think I've tracked it down ... it looks like a student plugged a Linksys switch/router into a clean access port. The MAC in the arp table is for a Linksys device, the dhcp.leases is our laptop. Thanks for the help guys, I think that's what's going on. Time to go track it down ...
Justin Howell Telecommunications Network Technician Solano Community College -----Original Message----- From: Cisco Clean Access Users and Administrators [mailto:[EMAIL PROTECTED] On Behalf Of Nathaniel Austin Sent: Tuesday, April 01, 2008 10:51 AM To: [email protected] Subject: Re: Weird Dead IP Problem Justin, Unfortunately not, it has to time out - we can't manually remove something from that list. That being said, that means we are getting traffic from that MAC/IP combo. Do you have a duplicate IP on the network? Nate Justin Howell wrote: > Ah ok now there's something interesting. The arp table has a different MAC > than the dhcp.leases file for that IP address. Is there a way to manually > delete an ARP entry? > > Justin Howell > Telecommunications Network Technician > Solano Community College > > -----Original Message----- > From: Cisco Clean Access Users and Administrators [mailto:[EMAIL PROTECTED] > On Behalf Of Nathaniel Austin > Sent: Tuesday, April 01, 2008 9:52 AM > To: [email protected] > Subject: Re: Weird Dead IP Problem > > Justin, > > It could be some sort of an arp issue or something similar. You said > that the traffic doesn't make it past the CAS, does it make it to the > CAS? Can you run a capture on the untrusted port of the CAS and verify > if we see the traffic there? If so, then I would definitely say its a > CAS problem. > > Check the CAS arp table too: cat /proc/click/intern_arpq/table - do you > see the offending IP in there with the correct MAC address and Vlan tag? > > Nate > > Justin Howell wrote: > >> 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 >> >>
