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:
Justin Howell <[log in to unmask]>
Reply To:
Cisco Clean Access Users and Administrators <[log in to unmask]>
Date:
Tue, 1 Apr 2008 10:12:51 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (123 lines)
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