Answers inline below. Hope they clear up your questions. Jason Boyers - CCIE #26024 (Wireless) Technical Instructor - IPexpert, Inc. Mailto: *[email protected] *
On Wed, Mar 2, 2011 at 11:29 AM, Phil Priest <[email protected]> wrote: > Hi Jason/Group, > > > > I am searching for some clarification with regards to some of the elements > of the CPU ACL in the for mentioned task. > > > > · I understand that as the controller relays DHCP traffic, that > that DHCP requests need to be allowed in but what is the reason for the DNS > entry. I am trying to see why this would be required as I can only see a > reason for a client to do a DNS query, is there a reason for the WLC to do a > DNS query? Is this something to do with Web Auth and intercepting the DNS > request? (probably just answered my own question J) > > *** I need to lab that again. The DNS query and resolution would be > between the client and the DNS server directly; the WLC does not proxy the > DNS request and response. As I look at it again, DNS can probably be > removed. There is no place to enter a DNS server for the management (or any > other interface.) Therefore, the WLC would not be able to send (and > therefore receive) a DNS query. The places where hostnames or FQDNs can be > entered (Virtual Interface, Web Login Redirect URL) are items that the WLC > would send to the client, and not something that the WLC would resolve > itself. So, I'm going to reserve the right to have entered too much > information. > *** As a side note, it is unlikely that a strict CPU ACL will be required on the lab (though not impossible.) The length of time that it takes to build it is fairly significant. And, it would be fairly difficult to test (the proctor is not going to look through all of the lines and check to make sure that every one is there.) This example was given for the sake of understanding CPU ACLs better. > · There are different directions defined (some inbound only and > some any), as the CPU ACL only works inbound to the CPU, what is the reason > for this? (if any) > *** No specific reason. As you said, both can be used (with the same effect) for CPU ACLs. > · Does the ACL have an effect on LWAPP control traffic. ( as > according to this guide it does not) > http://www.cisco.com/en/US/products/ps6366/products_tech_note09186a0080a7c988.shtml#console > ) > > *** Actually, under > http://www.cisco.com/en/US/products/ps6366/products_tech_note09186a0080a7c988.shtml#t4 > it > states that LWAPP data traffic (and CAPWAP control and data traffic) is not > impacted by the CPU ACL. However, LWAPP control traffic is affected and > needs to be included. And, yes, there are lines allowing LWAPP data in the > DSG. Refer to my comments under DNS :) > > · Finally, please could you expand on why there is a statement for > the WLC allowing all traffic to itself, and is this always required?? > > *** If there is a "deny all" at the end (either explicitly or implicitly,) > then this statement should be entered. The particular situation mentioned > at > http://www.cisco.com/en/US/products/ps6366/products_tech_note09186a0080a7c988.shtml#Strict > is > where the WLC is proxying DHCP traffic (which is what it does by default.) > > Many Thanks > > > > Phil >
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
