490 likes | 900 Views
WiNG 5.0 Training. Brocade Networks. WiNG 5 Training. Agenda Based on Wing 5.3. Day 1: Key Concepts Initial Configuration WiNG 5 UI Overview Access Point Adoption VLANs WLAN's. Day 2: Firewall Smart RF Tips & Troubleshooting. Day 3: Best Practices Advanced Features Fluke Demo
E N D
WiNG 5.0 Training Brocade Networks
WiNG 5 Training Agenda Based on Wing 5.3 Day 1: • Key Concepts • Initial Configuration • WiNG 5 UI Overview • Access Point Adoption • VLANs • WLAN's Day 2: • Firewall • Smart RF • Tips & Troubleshooting Day 3: • Best Practices • AdvancedFeatures • Fluke Demo • Performing and Reading a site-survey
Firewall Introduction IP ACLs Role Policy MAC ACLs Device WLAN Profile DoS Detection Firewall Policy ALGs Storm Control DHCP Offer Conversion IP/MAC Conflict Detection • WiNG 5.0 provides a enhanced stateful inspection firewall which is now distributed on all Brocade/Motorola WLAN devices: • Wireless Controllers • AP-650 Access Points • AP-7131 Access Points • The integrated firewall provides: • L2 / L3 Stateful Packet Inspection • Dynamic Firewall Rule Assignments (Roles) • DoS Detection • Storm Control • ARP Spoofing Protection • DHCP Offer Conversion • Application Layer Gateways
Firewall Firewall Policies – Introduction Profiles DoS Detection DHCP Offer Conversion Storm Control Firewall Policy Proxy ARP IP/MAC Conflict Detection ALGs Devices • Firewall policies enable and disable firewall services and configure the firewall features on Wireless Controllers and Access Points • Firewall policies control: • Layer 2 Firewall State • Application Layer Gateways • DoS Detection • DHCP Offer Conversion • Firewall Flow Timeouts • IP/MAC Conflict Detection • Proxy ARP • Storm Controls • A default firewall policy is assigned to all Wireless Controllers and Access Points by default • Only one default or user defined Firewall policy can be assigned per Wireless Controller or Access Point using profiles or device overrides
Firewall Firewall Policies – Application Layer Gateways (ALGs) • Each firewall policy can individually enable one or more ALGs that can inspect and verify application payloads and dynamically open additional ports required for the protocols to function • WiNG 5.0 supports ALGs for: • FTP • SIP • TFTP • ALGs require the protocols to be permitted for the ALG to function • For example the SIP ALG would require UDP port 5060 to be permitted and FTP would requite TCP port 21 to be permitted
Firewall Firewall Policies – DoS Detection • Each Firewall policy can detect 24 different DoS violations • Each violation can be individually enabled or disabled, supports and action that can drop and/or log traffic and provides a user defined log level • All events are enabled by default in the default and user defined firewall policies with default log level defined
Firewall Firewall Policies – DHCP Offer Conversion Broadcast DHCP Offers & ACKs Unicast DHCP Offers & ACKs DHCP Server MAC: 1111.1111.1111 IP: 192.168.10.5/24 DHCP Server MAC: 1111.1111.1111 IP: 192.168.10.5/24 VLAN 10 VLAN 10 VLAN 10 VLAN 10 VLAN 10 VLAN 10 VLAN 10 VLAN 10 Ethernet (IP) Ethernet (IP) Ethernet (IP) Ethernet (IP) Ethernet (IP) Ethernet (IP) Ethernet (IP) Ethernet (IP) S S S S S S S S 2222.2222.2222 0.0.0.0 1111.1111.1111 0.0.0.0 2222.2222.2222 0.0.0.0 2222.2222.2222 0.0.0.0 1111.1111.1111 192.168.10.5 1111.1111.1111 192.168.10.5 1111.1111.1111 0.0.0.0 2222.2222.2222 0.0.0.0 D D D D D D D D ffff.ffff.ffff.ffff 0.0.0.0 ffff.ffff.ffff.ffff 0.0.0.0 ffff.ffff.ffff.ffff 0.0.0.0 ffff.ffff.ffff.ffff 0.0.0.0 2222.2222.2222 0.0.0.0 ffff.ffff.ffff.ffff 0.0.0.0 2222.2222.2222 0.0.0.0 ffff.ffff.ffff.ffff 0.0.0.0 DHCP Offer DHCP Request DHCP Offer DHCP Discover DHCP Discover DHCP ACK DHCP Request DHCP ACK Station 1 MAC: 2222.2222.2222 IP: (DHCP) Station 1 MAC: 2222.2222.2222 IP: (DHCP) • DHCP offer conversion allows the Access Points to convert broadcast DHCP offers and ACKs to unicast reducing the number of Wireless Clients that have to receive and process the DHCP frame • Only applicable when the DHCP server is on the same VLAN as the Wireless Client • Disabled by default in the default user defined firewall policies
Firewall Firewall Policies – IP / MAC Conflict Detection Example DHCP Snooping Table ------------------------------------------------------------------------------- Snoop Binding <192.168.10.1, 00-12-83-93-B0-40, Vlan 10> Type router, Touched 3 seconds ago ------------------------------------------------------------------------------- Snoop Binding <192.168.10.14, 00-15-70-81-7B-0D, Vlan 10> Type switch-SVI, Touched 9 seconds ago ------------------------------------------------------------------------------- Snoop Binding <192.168.10.6, 00-E0-81-2F-DC-BC, Vlan 10> Type dhcp-server, Touched 57 seconds ago ------------------------------------------------------------------------------- Snoop Binding <192.168.10.101, 00-12-79-DE-38-40, Vlan 10> Type dhcp-client, Touched 7175 seconds ago router ip #1 - 192.168.10.1 dnsip #1 - 192.168.10.6 netmask = /24 Lease Time = 691200 seconds ------------------------------------------------------------------------------- Snoop Binding <192.168.10.102, 00-13-02-2E-78-82, Vlan 10> Type dhcp-client, Touched 2229 seconds ago Mint ID: 70.e6.98.1c router ip #1 - 192.168.10.1 dnsip #1 - 192.168.10.6 netmask = /24 Lease Time = 691200 seconds ------------------------------------------------------------------------------- • IP / MAC Conflict Detection allows Wireless Controllers and Access Points to intercept and log packets with IP / MAC bindings • Can detect and prevent man-in-the-middle ARP spoofing attacks • Can detect and prevent devices attempting to steal IP addresses • Can detect and prevent rogue DHCP servers • Valid IP / MAC bindings are learned by snooping DHCP offers and ACKs and building a IP / MAC binding table • The binding table includes the IP Addresses and MAC address for all DHCP servers, routers, and Virtual IP interfaces • Requires Wireless Clients to use DHCP and does not function with Wireless Clients with static IP addresses • Disabled by default in the default and user defined firewall policies
Firewall Firewall Policies – IP / MAC Conflict Detection Trusts • Each physical port and WLAN can be configured to trust or un-trust ARP and DHCP packets and drop suspicious packets • ARP Un-trusted – Wireless Controllers and Access Points will inspect and provide ARP spoofing protection on a port or WLAN • ARP Trusted – Wireless Controllers and Access Points will trust and not inspect ARP traffic on a port or WLAN • DHCP Un-trusted – Implies no valid DHCP server is attached to the port or WLAN and will block DHCP offers and ACKs received on the port or WLAN • DHCP Trusted – Implies a valid DHCP server is attached to the port or WLAN and will forward DHCP offers and ACKs received on the port or WLAN
Firewall Firewall Policies – Proxy ARP Proxy ARP Access Point MAC: 1111.1111.1111 IP: 192.168.10.1/24 Station 1 MAC: 2222.2222.2222 IP: 192.168.10.100/24 VLAN 10 VLAN 10 VLAN 10 VLAN 10 Ethernet (IP) Ethernet (IP) Ethernet (IP) S S S 1111.1111.1111 192.168.10.100 1111.1111.1111 192.168.10.100 2222.2222.2222 192.168.10.101 With Proxy ARP the infrastructure device responds to the ARP request on behalf of the Wireless Client D D D ffff.ffff.ffff.ffff 0.0.0.0 ffff.ffff.ffff.ffff 0.0.0.0 ffff.ffff.ffff.ffff 0.0.0.0 Without Proxy ARP the ARP request is flooded to all Wireless Clients on VLAN 10 Who has 192.168.10.101? Tell 192.168.10.100 192.168.10.101 is at 3333.3333.3333 192.168.10.101 is at 3333.3333.3333 VLAN 10 VLAN 10 Station 2 MAC: 3333.3333.3333 IP: 192.168.10.101/24 DFG: 192.168.10.1 Station 3 MAC: 4444.4444.4444 IP: 192.168.10.102/24 DFG: 192.168.10.1 • Proxy ARP allows Wireless Controllers and Access Points to generate ARP responses on behalf of Wireless Clients • Reduces the need for Wireless Clients to wake up and respond to ARP replies • Enabled by default in the default and user defined firewall policies
Firewall Firewall Policies – Storm Controls • Storm Controls provides as mechanism to protect the network infrastructure from flooding attacks or high-rates of traffic forwarded though Wireless Controllers and Access Points • Storm Controls are defined in firewall policies and may limit: • Broadcast packets / second forwarded through ports and WLANs • Multicast packets / second forwarded through ports and WLANs • Unknown Unicast packets / second forwarded through ports and WLANs • ARP packets / second forwarded through ports and WLANs • Traffic that exceeds the defined threshold will be dropped by the Wireless Controllers and Access Points and an event log message will be generated • Storm Controls are disabled by default in the default firewall policy or user defined firewall policies
Firewall Stateful Packet Inspection – Introduction • Provides stateful inspection for all IPv4 flows being switched or routed by a Wireless Controller or Access Point • Layer 2 inspection disabled by default • Supports stateless packet filtering for non IPv4 flows such as AppleTalk, IPX and IPv6 • Inspects all 802.11 flows typically not visible to wired firewall appliances including: • Wired to Wired Traffic • Wired to WLAN Traffic • WLAN to WLAN Traffic • Maintains state of TCP, UDP and ICMP flows as they traverse the Wireless Controller or Access Points • Once an IPv4 flow is established, bidirectional communications between hosts can occur (no reverse permit rule is required) • All flows are migrated as Wireless Clients roam between Access Points
Firewall Stateful Packet Inspection – Elements Ports Virtual IP Interfaces Profile WLANs Device IP Firewall Rule MAC Firewall Rule Rules Rules • MAC or IP Firewall Rules contain one or more traffic match conditions, actions and logging • Firewall rules can be assigned to Ports, Virtual IP Interfaces, WLANs or Wireless Clients • Each Firewall Rule must contain one or more permit rules for traffic to be forwarded: • Each rule is inspected in order of preference • The first rule to match the flow is used • Each Firewall Rule with one or more permit, deny or mark rules includes an implied deny • A Firewall Rule with no permit, deny of mark rules requires a deny rule for traffic to be dropped
Firewall Stateful Packet Inspection – IP Firewall Rules • IP Firewall Rules can be assigned to traffic paths to permit, deny or mark IPv4 flows • Have been enhanced in WiNG 5.0 to simplify deployments • Standard IP and Extended IP rules have been depreciated and replaced with one IP ACL type • Each Firewall Rule must be assigned a unique name (no more numeric IDs) • IP Firewall Rules can be assigned to WLANs, Physical Ports and Virtual IP Interfaces: • WLANs – One IP Firewall Rule maybe assigned per WLAN for inbound and outbound traffic • Physical Ports – One IP Firewall Rule maybe assigned per Port for inbound traffic • Virtual IP Interfaces – One IP Firewall Rule maybe assigned to each Virtual IP Interface for inbound traffic • IP Firewall Rules can be assigned to Physical Ports or Virtual IP Interfaces on individual devices or multiple devices using profiles • IP Firewall Rules assigned to individual devices will override IP Firewall Rules inherited from a profile
Firewall Stateful Packet Inspection – IP ACL Rule Elements Each IP Firewall Rules can contain up to 500 entries which support the following configuration elements:
Firewall Stateful Packet Inspection – MAC ACLs • MAC Firewall Rules can be assigned to traffic paths to permit, deny or mark IPv4 and non-IPv4 flows • MAC rules matching IPv4 traffic are stateful • MAC rules matching non IPv4 traffic are stateless • MAC Firewall Rules are identical to WiNG 4.0 • WLANs – One MAC Firewall Rule maybe assigned per WLAN for inbound and outbound traffic • Physical Ports – One MAC Firewall Rule maybe assigned per Port for inbound traffic • Virtual IP Interfaces – One MAC Firewall Rule maybe assigned to each Virtual IP Interface for inbound traffic • MAC Firewall Rules can be assigned to Physical Ports or Virtual IP Interfaces on individual devices or multiple devices using profiles • MAC Firewall Rules assigned to individual devices will override MAC Firewall Rules inherited from a profile
Firewall Stateful Packet Inspection – MAC ACL Rule Elements Each MAC Firewall Rule can contain up to 500 entries which support the following configuration elements:
Firewall Stateful Packet Inspection – Wireless Client Denies • Each WLAN allows administrators to defined a threshold for the number of denied packets that are permitted from a Wireless Client before the Wireless Client is mitigated: • Allows the WLAN system to automatically disassociate malicious users attempting to discover vulnerabilities or break through the firewall • After the defined number of Firewall denies / second is exceeded, the user will be dissociated
Firewall Roles – Introduction • Roles allow IP and MAC Firewall Rules to be dynamically assigned to Wireless Clients based on one or more user defined match conditions that include: • Location – AP or Group of APs the Wireless Client is connected to • Authentication Type – The authentication method used • Encryption Type – The encryption type used • Group Membership – The local Group the Wireless Client is assigned obtained from AAA • Hotspot Authentication State – Hotspot Authentication State • MAC Address – MAC address (or range) of the Wireless Client(s) • SSID – The SSID the Wireless Client is associated to • Match conditions strings are flexible and support Any, Exact, Contains, Not Contains operators • When multiple Roles match, the Role with the lowest precedence is assigned to the Wireless Client • Requires an Advanced Security License on each Wireless Controller managing Access Points where Roles are being assigned to Wireless Clients
Firewall Roles – Elements Device Profile Role Policy Role Inbound MAC / IP Firewall Rule Outbound MAC / IP Firewall Rule Match Conditions • Roles consist of the following elements: • Role Policy – Contains one or more user defined Roles which maybe assigned to Wireless Clients • Roles – One or more unique names that defines a role name, match conditions and the inbound / outbound IP/MAC Firewall Rules to assign • Defaults – Defines default inbound and outbound IP/MAC Firewall Rules to be assigned when no Roles have been defined, are matched or no Advanced Security License has been installed • One Role policy can be assigned per RFS4000 with Integrated Access Point, AP-650 or AP-7131 Access Points
Firewall Roles – Assignments • Roles are assigned to Wireless Clients during association: • The Access Point evaluates the context of the Wireless Client against the defined Roles in the Role Profile and selects the appropriate role to assign • The Access Point applies the IP and MAC Firewall Rules to the Wireless Client • Roles are re-evaluated if: • The Wireless Client roams to a different Access Point • The Wireless Client associates to a different SSID • IP flows are maintained during roaming as flow keys are migrated between Access Points: • Traffic flows are re-evaluated with no disruption to the ongoing traffic, if the Firewall Rules assigned to the Role still permits the existing traffic • If the new Role is assigned that denies the traffic, existing flows will be deleted and packets will be dropped
Firewall Roles – Use Cases • Roles can be useful for multiple applications including: • NAP/NAC deployments when network permissions need to be dynamically changed based on the Wireless Clients NAP/NAC compliance state • Captive Portal applications when different classes of users share the same WLAN but each require a level of network permission levels (i.e. Guests vs. Contractors) • Corporate applications when network permissions needs to be dynamically changed based on the corporate users department or location • Wireless deployments that require a common set of default network permissions for un-identified Wireless Clients
Firewall Roles – Deployment Example • Role: Voice • Precedence = 1 • SSID (Exact) = Voice • Encryption (Exact) = CCMP • Auth (Exact) = None • IP ACL (in) = Voice • Role: Guests • Precedence = 1 • SSID (Exact) = Guest • Encryption (Exact) = None • Auth (Exact) = None • Hotspot-Auth = Post-Login • Group (Exact) = Guests • IP ACL (in) = Guests • Role: Sales • Precedence = 1 • SSID (Exact) = Corp • Encryption (Exact) = CCMP • Auth (Exact) = EAP • Group (Exact) = Sales • IP ACL (in) = Sales • Role: Marketing • Precedence = 1 • SSID (Exact) = Corp • Encryption (Exact) = CCMP • Auth (Exact) = EAP • Group (Exact) = Marketing • IP ACL (in) = Marketing • Role: Contractors • Precedence = 1 • SSID (Exact) = Guest • Encryption (Exact) = None • Auth (Exact) = None • Hotspot-Auth = Post-Login • Group (Exact) = Contractors • IP ACL (in) = Contractors • Role: Engineering • Precedence = 1 • SSID (Exact) = Corp • Encryption (Exact) = CCMP • Auth (Exact) = EAP • Group (Exact) = Engineering • IP ACL (in) = Engineering
Firewall ACL Assignments & Traffic Paths Roles Wireless Client Wireless Client Inbound Outbound Inbound Outbound WLANs Radio Radio Inbound Outbound Inbound Outbound WLAN 2 x MAC ACLs 2 x MAC ACLs 1 x MAC ACL 1 x MAC ACL 1 x MAC ACL 1 x MAC ACL 1 x MAC ACL 1 x MAC ACL 1 x MAC ACL 1 x MAC ACL 2 x MAC ACLs 2 x MAC ACLs WLAN 1 x IP ACL 1 x IP ACL 1 x IP ACL 2 x IP ACLs 1 x IP ACL 1 x IP ACL 1 x IP ACL 1 x IP ACL 2 x IP ACLs 2 x IP ACLs 2 x IP ACLs 1 x IP ACL Inbound Inbound Virtual IP Interfaces VLAN 1 192.168.1.1/24 VLAN 2 192.168.2.1/24 Inbound Inbound Physical Ports GE Ports GE Ports Inbound Inbound
Firewall Considerations 1 Each Wireless Controller and Access Point is assigned to a default Firewall Policy which is enabled Dynamic ACL assignments requires an Advanced Security License to be installed on the Wireless Controller 2 Each IP and MAC ACL includes an implied deny and requires one or more permit rules for traffic to be permitted 3 All ARP traffic is considered un-trusted by default 4 All DHCP traffic is un-trusted by default except through physical ports Wireless Clients can be automatically disassociated if they exceed a specified number of firewall denies per second Before enabling storm controls an evaluation of network should be performed to obtain a baseline of Multicast, ARP and Unknown Unicast traffic 5 6 7
Smart-RF Overview Automatically selects optimal channel and power settings for APs across a cluster of switches Creates a channel balanced distribution of AP’s Counters Wi-Fi and Non-Wi-Fi Interference Eliminates dead spots in RF coverage. Insures against loss of coverage due to sudden AP Failure Mitigates Co-Channel Interference so that APs don’t interfere with each other Automatically creates ‘Micro-cell’ for high density deployments Flexible Configuration Knobs so IT doesn’t waste time ‘tuning’ the algorithm Flexible implementation allows locking AP channel, power or role if changes are not desired. Administrators can review SMART-RF actions through SMART-RF History
Smart-RF Operation 1 Smart off Channel scanning ensures Smart-RF dynamically adapts to RF changes Automatically assigns channels and power of radios Seamlessly works with AP650 and AAP7131 2 4 Seamlessly works across a cluster of RF switches 3 Calibration Configuration Off Channel Scanning (OCS) Run Time Monitoring and Recovery • OCS Scanning • Voice Aware • PSP Aware • Interference Avoidance • Neighbor Failure • Coverage Holes • Auto Channel • Auto Power • Auto Calibrate • Scan Parameters
Smart-RF Off-Channel Scanning All AP’s periodically go off-channel (off-channel-duration) They scan a single channel Each channel can be scanned multiple times (sample count) The entire band is only scanned at define intervals (extended-frequency-scan) 1 2 3 4
Smart-RF Neighbor Recovery 12db Normal 15db Rescue 15db Normal 14db Normal 17db Rescue 17db Normal Neighbor radios monitor the Air Neighboring APs change from Normal to Rescue Neighbor radios sense when an AP fails Neighboring APs raise TX power 1 4 3 2 10db Normal 17db Rescue 17db Normal 14db Normal • Defends against Loss of Coverage due to Sudden AP Failure • AP’s with faulty antennas • AP’s with bad Ethernet Connections • AP’s which are faulty • AP’s that are not visible anymore due to obstructions
Smart-RF Coverage Hole Coverage SNR threshold set to 20db As the client moves away from the AP, SNR will drop If SNR drops below set threshold of 20db, the AP raises its TX power If the client SNR is maintained, the AP will reduce its TX power The AP will repeat step 4 until the client SNR is maintained 1 2 3 4 5 SNR: 18db SNR: 30db SNR: 20db • A typical use case for this feature: • In a warehouse there was a vacant spot • During business hours new inventory was stacked high (changes the RF) • Mobile Units in the new aisle do not get adequate coverage • AP detects the fall in SNR (<threshold value) and raises power • Power returns to normal if no client present (dynamically adjusting to changes)
Smart-RF Coverage Hole Parameters SNR Threshold: Threshold value that will trigger the feature Client Threshold: Only if "x" number of clients fall below the SNR threshold value, will the radio trigger coverage hole recovery Interval: Indicates the interval when coverage hole recovery is performed Coverage Interval: Indicates the interval when coverage recovery is performed after a coverage hole is detected
Smart-RF Coverage Hole Parameters Configuration > Wireless > SMART RF Policy ! smart-rf-policy EastCoast enable group-by building sensitivity custom assignable-power 5GHz min 11 assignable-power 5GHz max 15 assignable-power 2.4GHz min 8 assignable-power 2.4GHz max 12 channel-list 5GHz 36,40,44,48 channel-width 2.4GHz 40MHz interference-recovery client-threshold 5 ! smart-rf-policy WestCoast enable group-by floor sensitivity custom assignable-power 5GHz min 11 assignable-power 5GHz max 15 assignable-power 2.4GHz min 8 assignable-power 2.4GHz max 12 channel-list 5GHz 149,153,157,161 channel-width 2.4GHz 40MHz interference-recovery client-threshold 5 !
Smart-RF Why Smart-RF Policies? WiNG 4.X has one flat Smart-RF policy Not optimum since different building AP’s are part of the same RF-Domain In WiNG 5.X every Building CAN be a different RF-Domain Threshold Settings can be different 1 2 3 4 Building 2 Building 3 Smart-RF Policy 2 Smart-RF Policy 3 Smart-RF Policy 1 Flat Smart-RF Network/Domain/Policy Building 1 What is a typical use case for creating policies? A Warehouse building may need sensitive thresholds when compared to a neighboring/remote office building. Smart-RF Policy 4 Building 4 Smart-RF Policy 5 Building 5
Smart-RF What is group by Floor or Building? By Floor By Building Floor 1 Building 1 Building 2 Floor 2 Floor 3 Building 3 Building 4 One RF-Domain & Smart-RF Policy One RF-Domain & Smart-RF Policy • What is a typical use case for these parameters? • By Floor – An office building with different tenants on every floor • By Building – A campus environment with multiple buildings
Smart-RF Smart-RF in WiNG 4.X vs. WiNG 5.X
Smart-RF Is there an easy setup for Smart-RF? Low: Less Spicy (Aggressive/Reactive) Medium: Spicy (Somewhat aggressive/reactive) High: Cant feel my lips (Very aggressive/reactive) Custom: Create your own Enchilada
Smart-RF Considerations 1 DISABLE Smart-RF when running a throughput test Smart-RF is a patch and not a fix When grouping AP’s, recommended practice is to group by building rather than floor 2 4 Yes a site survey is still required. Smart-RF will perform better when AP’s placements are planned 3
Tips & Troubleshooting Troubleshooting Layer 2 Adoption If Layer 2 Access Point adoption fails: Verify the Access Point is connected to a local VLAN that has been extended to the Wireless Controller Verify that no firewall rules have been applied between the Wireless Controller and Access Point or directly to the Wireless Controller and Access Point that will drop EtherType 0x8783 Verify the Gigabit Ethernet port on the Access Point not been previously configured for 802.1Q tagging with a tagged native VLAN Verify that Spanning Tree Protocol has not been enabled on the Ethernet Switch Port connected to the Access Point
Tips & Troubleshooting Troubleshooting Layer 3 Adoption If Layer 3 Access Point adoption fails: Verify the Virtual Interface assigned to the Access Points Native VLAN has DHCP enabled Verify the Access Points DHCP scope has DHCP options 189 or 192 defined Verify the Wireless Controllers Native VLAN has a Virtual IP Interface defined with a valid IP Address Verify the Wireless Controller has a default route assigned Verify that no firewall rules have been applied between the Wireless Controller and Access Point or directly to the Wireless Controller and Access Point that will drop UDP 24576 Verify that a wired client on the Access Point VLAN can ping the management IP Address on the Wireless Controller Verify that Spanning Tree Protocol has not been enabled on the Ethernet Switch Port connected to the Access Point
Tips & Troubleshooting AP Adoption Policies • AP Adoption Policies can only assign user defined RF Domains and Profiles to new Access Points that have not been discovered by a Wireless Controller / Cluster • If an Access Point has been already adopted prior to creating an Adoption Policy, the Access Points will already be assigned to a default RF Domain and Profile • To assign a user defined RF Domain and Profile to an Access Point that has previously been discovered by the Wireless Controller / Cluster: • Disconnect the Access Points from the network • Remove the Access Points device configuration • Commit and Save the changes • When the Access Points are re-connected to the network, they will be automatically assigned to the user defined RF Domain and Profile during the adoption process
Tips & Troubleshooting Profile and RF Domain Assignments group20-rfs4000# show wireless ap configured +---+----------------+-------------------+----------------+------------------+----------------+ |IDX| NAME | MAC | PROFILE | RF-DOMAIN | ADOPTED-BY | +---+----------------+-------------------+----------------+------------------+----------------+ | 1 | group20-ap650 | 00-23-68-31-14-2D | group20-ap650 | group20-rfdomain | un-adopted | | 2 | group20-ap7131 | 00-15-70-C7-8F-F0 | group20-ap7131 | group20-rfdomain | un-adopted | +---+----------------+-------------------+----------------+------------------+----------------+ 1 2 3
Tips & Troubleshooting Sniffer Redirect TZSP Access Point Radio Host with IP Address 172.16.1.100 Each radio on an AP-650 or AP-7131 Access Point can be configured to redirect packets is sees on a specific channel to a Sniffer such a Wireshark over IP using the TaZman Sniffer Protocol (TZSP) All packets on the channel are forwarded as received by the radio When enabled the Access Point radio cannot support Wireless Client traffic Access Point must have an IP Address assigned!
Tips & Troubleshooting Local Packet Captures Each Wireless Controller and Access Point provides a integrated packet capture facility which can be used to capture wired and wireless traffic in real-time Packet captures can be streamed to the console, saved to a file
Tips & Troubleshooting Remote Packet Captures Each Wireless Controller and Access Point provides a integrated packet capture facility which can be used to capture wired and wireless traffic in real-time Packet captures can be streamed to the console, saved to a file or streamed to a Sniffer over IP using TZSP For ease of troubleshooting Wireless Packets can be captured encrypted or unencrypted