CLEANACCESS Archives

March 2012

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:
"King, Ronald A." <[log in to unmask]>
Reply To:
Cisco Clean Access Users and Administrators <[log in to unmask]>
Date:
Thu, 1 Mar 2012 08:50:34 -0500
Content-Type:
multipart/signed
Parts/Attachments:
text/plain (5 kB) , smime.p7s (6 kB)
My experience with the NAC appliances has me believing the underlying OS is
a purpose built Red Hat (RHEL5) derivative.  That said, RHEL's default
behavior is to add the MAC address into the Ethernet interface's
configuration file.  This is for security and perhaps to assist the plug and
play capabilities.  So, when new NICs are installed, they are automatically
detected and installed, but, since their already exists hardware, according
to the kernel, it adds them using interface references in numerical order.
We see this a lot in virtual environments when copying VMs as the copying
causes the hardware address (MAC) to change, which is intentional to avoid
conflicts.  

I teach Red Hat (RHEL6) here at a local community college, and, recently, we
ran into this issue, but simply removing the MACs in the ifcfg files did not
fix it.  We had to edit the file /etc/udev/rules.d/70-persistent-net.rules
and change the MAC addresses there to.  If you fell that might be required
in your case, back up the rules file before making changes.  An error in it
could cause the system issues booting and/or connecting to the network.
But, because RHEL5 uses a script called from /etc/udev/rules.d/60-net.rules,
this does not apply as it is automated and detecting at startup.

Feel free to hit me up offline for more information if anyone would like.

Ronald King
Security Engineer, NSU
http://security.nsu.edu


-----Original Message-----
From: Cisco Clean Access Users and Administrators
[mailto:[log in to unmask]] On Behalf Of Antonio Soares
Sent: Thursday, March 01, 2012 7:20 AM
To: [log in to unmask]
Subject: Re: MacOS Lion not recognized by current 4.8.x?

Just to let know the group that the problem was solved this way:

1) when the NICs were replaced on CAS2, the files
/etc/sysconfig/network-scripts/ifcfg-eth2(3) were updated with the new Mac
Addresses.
2) for some reason, after a few reboots, the NAC appliance changed the NICs
order, the integrated NICs became eth2 and eth3 and the non-integrated
became eth0 and eth1.
3) the HWADDR entry in the ifcfg2 and ifcfg3 were commented out. After a
reboot, the NICs showed up in the correct order.
4) the problem was still active, no way to ping from CAS1 to CAS2 over the
HA interface (eth2).
5) we noticed that in CAS1, the server that didn't have any hardware
failures, the HWADDR entry was uncommented and that it appeared in the end
of the file. We made the same on CAS2, and after a reboot everything started
working again.

This doesn't make too much sense, but it worked. Any comments ?


Regards,

Antonio Soares, CCIE #18473 (R&S/SP)
[log in to unmask]
http://www.ccie18473.net


-----Original Message-----
From: Cisco Clean Access Users and Administrators
[mailto:[log in to unmask]] On Behalf Of Antonio Soares
Sent: segunda-feira, 20 de Fevereiro de 2012 18:40
To: [log in to unmask]
Subject: Re: MacOS Lion not recognized by current 4.8.x?

Hello group,

We just made an upgrade from 4.8.0 to 4.8.2 and we are fighting with a very
strange issue. One of the PCI Express NICs got faulty and we had to replace
it. Now we have the two Servers not able to communicate with each other.
Each one says Active, Peer Dead. The 'eth2' are connected to different
switches but from the switches (via SVI interface) it is possible to ping
each CAS Server. But from the Server we cannot ping the peer Server...

It was working after a few reboots... But yesterday a new reboot was made
just to check the behavior and it happened again. We are not sure but we
think the problem was there before one of the NICs got faulty...

Any ideas ?


Thanks.

Regards,

Antonio Soares, CCIE #18473 (R&S/SP)
[log in to unmask]
http://www.ccie18473.net


-----Original Message-----
From: Cisco Clean Access Users and Administrators
[mailto:[log in to unmask]] On Behalf Of Jeremy Wood
Sent: terça-feira, 30 de Agosto de 2011 03:02
To: [log in to unmask]
Subject: Re: MacOS Lion not recognized by current 4.8.x?

Make sure you double check your hostnames/SSL cert CN's and ensure
they are all lowercase before you upgrade. We were on 4.8.0 and moved
to 4.8.2 for Lion support and in the process hit this bug
(http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fe
tchBugDetails&bugId=CSCtq35120).
Ended up having to get our certs reissued and barely made it before
our students got back.

--Jeremy

On Mon, Aug 29, 2011 at 11:17, Kurt Huenemann <[log in to unmask]> wrote:
> Yup, just got the word from Cisco that although we already deploy the
> 4.8.2.591 Mac Agent, we're still at 4.8.0 code on the CAM and CAS.
>
> Just downloaded the 4.8.2 code and notes, and will get started on that
> little project!
>
> Thanks, all, for your comments.
>
> Kurt
>
> Kurt E. Huenemann, Assoc. Vice President for Information Resources
> HEIDELBERG UNIVERSITY
> 310 East Market Street
> Tiffin, Ohio 44883
> 419.448.2351
> [log in to unmask]
>
> Do not ever e-mail your password to anyone.
> CNIT will never ask for your password in an e-mail.
>
>
> On Mon, Aug 29, 2011 at 10:10 AM, Daniel T <[log in to unmask]> wrote:
>>
>> Kurt, I just upgraded to 4.8.2 to get Lion support. You will need to
>> upload MAC agent 4.8.2.x591 (note the "1" at the end) to the Mgr after
>> the upgrade. I haven't had any problem after the upgrade.
>>
>> Regards,
>> /Daniel
>>
>>
>> On Mon, Aug 29, 2011 at 5:09 AM, Kurt Huenemann <[log in to unmask]>
>> wrote:
>> > Friends,
>> >
>> > Returning students with MacOS 10.7 (Lion) are not being recognized by
>> > Cisco
>> > NAC, and we've had to admit them via the "mac filter" method.
>> >
>> > Is this a known issue, or have we missed something in our setup?
>> >
>> > Thanks, in advance, for any ideas.
>> >
>> > Kurt
>> >
>> > Kurt E. Huenemann, Assoc. Vice President for Information Resources
>> > HEIDELBERG UNIVERSITY
>> > 310 East Market Street
>> > Tiffin, Ohio 44883
>> > 419.448.2351
>> > [log in to unmask]
>> >
>> > Do not ever e-mail your password to anyone.
>> > CNIT will never ask for your password in an e-mail.
>> >
>
>


ATOM RSS1 RSS2