Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 

TAC Security Podcast Episode #19 - Troubleshooting the NAC Appliance (Clean Access)

TACSecurityPodcastEpisode19.png

Episode Information

Episode Name: Episode 19 - Troubleshooting the NAC Appliance

Contributors:  Nevin Absher, Blayne Dreier, Jay Johnston, Magnus Mortensen

Posting Date: May 10, 2011

Description: This  episode focuses on the Network Admission Control (NAC) appliance, with special guest Nevin Absher from the Cisco AAA TAC Team in RTP, NC. The discussion starts with a basic introduction to how network  administrators can use the NAC appliance to control access to the network in various deployment scenarios. The discussion then moves to NAC deployment and operation best practices as well as specific issues that some administrators encounter when deploying the solution, and how to avoid them. NAC troubleshooting methodologies and techniques are also discussed.

Listen Now    (MP3 24 MB; 36:39 mins)

Subscribe to the Podcast in iTunes by clicking the image below:

button_itunes.gifrss.gif

About the Cisco TAC Security Podcast

The  Cisco TAC Security Podcast Series is created by Cisco TAC engineers.  Each episode provides an in-depth technical discussion of Cisco product  security features, with emphasis on troubleshooting.

Complete episode listing and show information

Show Notes

NAC Documentation and Information Resources

NAC Appliance Chalk Talk Series

NAC Appliance Documentation


Doc for creating custom AV check

Version history
Revision #:
1 of 1
Last update:
‎05-02-2011 07:03 AM
Updated by:
 
Labels (1)
Comments
New Member

Hi Lads

Excellent episode as per usual :-)

No David White on this episode? It felt like Christmas, but without Santa...

I have a Q, which hopefully you will be able to answer. Around the 20 min mark you lads are speaking about Vlans and creating an SVI. Nevin mentions that traffic that when an SVI is configured without an IP address traffic is punted to the RP, rather than being layer 2 switched. Is this just for NAC and the Virtual Gateway Mode? The reason I ask is, I can't see any reason why a switch (when NAC was not involved), that had traffic that is at layer 2 would be sent to the RP. Back in the day I tried getting traffic to be filtered by an ACL applied to an SVI, even though it had no IP address, but it seemed that I needed to apply an IP for the access-list to take effect. I probably tried this on a 3750/3560, not 65k.

Magnus also mentions that he's seen issues with this (Layer 2 Vlans having an SVI with no IP address) and the FWSM. Magnus, any chance you could elaborate on this please?

Many thanks as always.

Cisco Employee

Hi Golly,

Hopefully I don't confuse you more as I try to explain this.  The issue is actually seen with anything where L2 vlans are bridged (NAC, FWSM, IDS).  If you're bridging 2 L2 vlans, and both have an SVI, the mac address for the RP is injected into that vlan.  Since the mac address is the same for all SVI's, the 'untrusted' vlan now has an entry for the mac that is returned via ARP for your gateway. So when you send a packet destined for your gateway the switch sees that there is a mac entry in the local vlan (SVI) and sends the packet there.  Since the interface is either shutdown, or without an IP it just gets dropped.

Let me know if that helps, or just muddys the waters more.

Thanks,

Nevin

New Member

Hi Nevin

Thank you very much Sir - that's crystal clear now. Just to confirm, with reagrds to the FWSM this will only be applicable for transparent contexts?

Many thanks again.

Cisco Employee

Yes, we usually see that issue creep up in TFW mode. If the setup was routed, the host computers are sending to the MAC address of the FWSM interface.. .not the SVI beyond it. As a result, even if there is an SVI on both side, the destination MAC forces the packet to the FWSM and not to the SVI.

New Member

Hi Magnus

I had that exact issue (split an already enabled SVI into two by using a transparent FWSM), but manually changed the MAC on one of the SVI's to fix this (I thought that this was the only work around), now I know. Many thanks for the clarification.


Congratulations on the CCIE, not knowing what to do with all your spare time after passing, is a strange, but pleasent feeling :-)