CLEANACCESS Archives

April 2008

CLEANACCESS@LISTSERV.MIAMIOH.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Nathaniel Austin <[log in to unmask]>
Reply To:
Cisco Clean Access Users and Administrators <[log in to unmask]>
Date:
Tue, 1 Apr 2008 13:50:40 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (135 lines)
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:[log in to unmask]] On Behalf Of Nathaniel Austin
> Sent: Tuesday, April 01, 2008 9:52 AM
> To: [log in to unmask]
> 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:[log in to unmask]] *On Behalf Of *Caines, Max
>> *Sent:* Tuesday, April 01, 2008 9:18 AM
>> *To:* [log in to unmask]
>> *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:[log in to unmask]] *On Behalf Of *Justin Howell
>>     *Sent:* 01 April 2008 16:50
>>     *To:* [log in to unmask]
>>     *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
>>
>>     

ATOM RSS1 RSS2