Configuration Guide for RFMS 3.0 Initial Configuration [WiNG 5.1] How-To Guide [1 Hop Mesh] [July] 2011 Revision [Rev 2] XXX-XXXXXX-XX MOTOROLA and the Stylized M Logo are registered in the US Patent & Trademark Office. Symbol is a registered trademark of Symbol Technologies, Inc. All other product or service names are the property of their respective owners. © 2009 Motorola, Inc. All rights reserved. Table of Contents: 1. 2. 3. Introduction: ........................................................................................................................ 4 1.1 Overview: ..................................................................................................................... 5 1.2 DATA PATH................................................................................................................. 6 1.3 SECURITY .................................................................................................................. 7 1.4 RADAR HANDLING IN MESH ..................................................................................... 7 1.5 STATUS AND TROUBLESHOOTING.......................................................................... 7 Pre-Requisites: ..................................................................................................................10 2.1 Requirements: ............................................................................................................10 2.2 Components Used: .....................................................................................................10 Configuration: ....................................................................................................................11 3.1 Feature 1: Portal AP ...................................................................................................11 3.2 Feature 2: Client AP....................................................................................................13 3.3 AP-650 Setup is Identical as 7131 with one exception: ...............................................15 3.4 Configuration-Persistance GUI....................................................................................17 4. RF Switch Running Configuration: .....................................................................................18 5. Reference Documentation: ................................................................................................22 How-To-Guide for Single Hop Mesh 1. Introduction: WiNG 5.1 allows AP‟s to operate wirelessly, connecting to other access points for data backhaul, in a mesh topology. This feature offers a cost-effective way to extend the network outdoors or in remote areas, relying on a highly resilient, self-configuring system. Taking advantage of the dual-radio architecture and the easy-to-use configuration interface, it becomes a simple task to deploy a wireless network of access points connected securely via 802.11a/n, providing enterprise-class 802.11b/g /n service WiNG 5.1 supports single-hop mesh. The mesh node that has connectivity to the wire will be referred to as a ‟Portal‟ to use the term from 802.11s. The node that is ‟wireless‟ will be referred to as a ‟client‟. In comparison with WiNG 4.x AAP Mesh a ‟Portal‟ is analogous to a ‟Base Bridge‟ and a ‟client‟ is analogous to a ‟Client bridge‟. One difference is that a client is also a portal by default once its link is up (in releases past 5.0) while in AAP client-bridge was not automatically a base bridge. Two other differences from AAP mesh are, instead of STP and standard bridge forwarding, MiNT will be used as the data path forwarding algorithm; and there is no requirement of a ‟mesh wlan‟ if there is another wlan being used on the same radio. This feature will be supported on all platforms supporting a radio in 5.0: AP650, AP7131, and RFS4000 Radio SKU. How-To-Guide for Single Hop Mesh 5Ghz Mesh Client AP 5Ghz Mesh Portal AP Client AP 1.1 Overview: Support for wireless meshing will be enabled/disabled on a per radio basis with the following options: no mesh – default value mesh portal – turns the radio into a mesh portal mesh client – turns the radio into a mesh client The mesh IE will be included in the beacon of any existing WLAN on that radio. So if the mesh radio also supports a data-wlan the IE is piggybacked on it. In the event that the mesh radio does not How-To-Guide for Single Hop Mesh include a wlan, the administrator needs to create a ‟service wlan‟. The ‟service-WLAN‟ is needed ONLY if there are no other WLANs on the radio (pure-backhaul case). If there are other WLANs, then there is no need to create a service-WLAN. **Note also that the service-WLAN (if-any) MUST be mapped to the first BSS of the radio. All mesh association and data packets use the first BSS of the radio. ** The „service-WLAN‟ is a regular‟ wlan and is created and mapped as such. However the ‟client-access‟ configuration on this wlan will be set to OFF, this will not allow clients to associate on this wlan. An SSID will not be included in the beacons (as if secure-beacon is ON); probe-responses will not be sent for this wlan, and all incoming management frames will be ignored (unless they are an association request from a mesh peer). In real-life an MU should not even send an association request as all identifying features of this wlan (primarily the SSID) have been disabled. Each mesh client will only have support for one link to a portal; however a portal will include links for multiple clients. The maximum number of links per portal will be configurable from 1..6. The default value will be 3. Once a link comes up the client can tear down the link if it is no longer ‟useful‟. Without a multi-link mesh the main use-case for teardown is if a portal or client has gone down or the link is so noisy that it is difficult to pass traffic on it. Link quality and cost are not criteria at this point as in any case only one link will be supported at a time. Two criteria that will be supported for taking a mesh link down are: missed beacons - if any mesh peer stops hearing beacons from its peers for a while it assumes the link has been lost. The time for which missed beacons are tolerated will be configurable from 1 to 10 seconds, with a default of 2 seconds. transmit failures - if any mesh peer faces a certain number of successive transmit failures for a peer it assumes the link is extremely bad, tears it down and tries other nodes. Since this is disruptive and there is potential for flapping if there are no other candidate mesh nodes the teardown criteria is fairly strict at a default of 10 successive failed packets. For reference for wireless clients (MUs) we currently use a value of 6 successive failed packets. In addition to the automatic discovery of peer nodes the administrator can choose to select a number of APs as the peers for certain mesh nodes ensuring that connection is only allowed among those peer nodes. Up to 6 preferred-peers can be configured on a per radio basis. If a radio has a preferred-peer configured it will only allow configuration from/to that peer. Note that unlike AP5131/AP7131 these static links are configured using the wired MAC address of the device (same MAC that is used in configuration and is printed on the AP itself), instead of the BSSID (which is not known unless the AP is powered up and adopted). 1.2 DATA PATH Mesh forwarding will utilize MiNT routing and discovery for forwarding of data frames across the meshed network. As soon as the wireless link is complete the Radio Interface Module (rim) will send a mint-link-add message to the Data path Daemon (dpd). This link will start to show up in ’show mint links’, initially with 0 adjacencies, and then MiNT will exchange Hello and LSP packets to ‟bring up‟ the link. At the point where the link comes up the nodes will show up in the CLI under ’show mint neighbors’ and the link will also show up in ’show mint lsp’ and ’show mint lsp-db’. From that point on data frames will be forwarded across this link. **Note that the mesh link is a point-to-point link from a MiNT perspective (much like L3 links) so any VLAN that is served up across the mesh will need to be extended across it using the standard MiNT configuration for extended VLANs (bridge vlan).** Once the MiNT link is up mint routing will ensure that all nodes in the network are aware of this How-To-Guide for Single Hop Mesh node and can reach it and forward frames from it. 1.3 SECURITY MiNT security will be the backend security mechanism for the mesh nodes. Please refer to the MiNT security specification for all details. The only difference being that on this link instead of the AESSHA256 encryption used in general for MiNT security AES-CCMP will be used. The keys will still be derived from the MiNT security mechanism, just for encryption the radio crypto support will be leveraged. 1.4 RADAR HANDLING IN MESH One of issues with mesh has been handling of Radar when the mesh has been formed on a DFS channel(s). It‟s been a major concern on the ability of the mesh to quickly reform in the event of Radar as seen by one or more mesh peers. To address this issue a simple mechanism has been incorporated. The behavior of the mesh will be as follows: Once one or more mesh node sees a radar it brings down the mesh connection with its peers by sending deauth frames. It is followed by the transmissions of beacons with channel-switch announcement IE. Mesh nodes on receiving the beacons with channel-switch announcement IEs from peers shall mark their primary (and extension channel if operating in 40MHz mode) channels as radar interfered which will make the channel(s) unusable for the next 30 minutes. After 30 mins the mesh portal resumes the operation in the home channel. It leads to mesh reformation once again 1.5 STATUS AND TROUBLESHOOTING The status of the mesh links on a particular node can be seen by the "Show wireless mesh links" CLI command. On a client node in 5.0 there will only be one mesh link as only a single hop to a portal is supported. On the portal all mesh clients connected with this portal will be displayed. Syslogs will be generated for link bring up and tear-down: How-To-Guide for Single Hop Mesh 1.5.1 Feature 1: Portal AP (Radio) How-To-Guide for Single Hop Mesh 1.5.2 Feature 2: Client AP (Radio) How-To-Guide for Single Hop Mesh 2. Pre-Requisites: 2.1 Requirements: The following requirements must be met prior to attempting this configuration: One (or more) RF Switches are installed and operational on the network. A Windows XP workstation is available with Microsoft Internet Explorer or Mozilla Firefox to perform Web UI or CLI configuration. The reader has read the Motorola RFS Series Wireless LAN Switches - WiNG System Reference Guide. 2.2 Components Used: The information in this document is based on the following Motorola hardware and software versions: 1 x RFS4000 or RFS7000 Version 5.1.  Registered users may download the latest software and firmware from the Motorola Technical Support Site http://support.symbol.com. How-To-Guide for Single Hop Mesh 3. Configuration: The following section outlines the configuration steps required to create a single hop Mesh with 2 AP7131‟s 1) Feature 1 [Portal AP]: 2) Feature 2 [Client AP]: 3.1 Feature 1: Portal AP 3.1.1 Web UI Configuration Example: 1) On the GUI interface- Configuration, Devices, APxxx-, interface, Radios, Radio2 2) MeshConnex Tab 3) Select Portal from drop down window How-To-Guide for Single Hop Mesh 3.1.2 CLI Configuration Example: 1) RFS4000# configure terminal Enter configuration commands, one per line. End with CNTL/Z. 2) rfs4000-22D070(config)#ap71xx 00-23-68-97-00-10 rfs4000-22D070(config-device-00-23-68-97-00-10)#interface radio2 rfs4000-22D070(config-device-00-23-68-97-00-10-if-radio2)# mesh portal 3) rfs4000-22D070(config-device-00-23-68-97-00-10-if-radio2)#com wr ap71xx 00-23-68-97-00-10 use profile default-ap71xx use rf-domain default hostname ap71xx-970010 interface radio2 mesh portal ! ! end How-To-Guide for Single Hop Mesh 3.2 Feature 2: Client AP 3.2.1 Web UI Configuration Example: 1) On the GUI interface- Configuration, Devices, APxxx-, interface, Radios, Radio2 2) MeshConnex Tab 3) Select Client from drop down window How-To-Guide for Single Hop Mesh 3.2.2 CLI Configuration Example: 1) Configuration Terminal RFS7000# configure terminal Enter configuration commands, one per line. 2) End with CNTL/Z. Connect to Client AP rfs4000-22D070(config)#ap71xx 00-23-68-93-11-34 rfs4000-22D070(config)#ap71xx 00-23-68-93-11-34# bridge vlan 1 rfs4000-22D070(config-device-00-23-68-93-11-34)#interface radio2 rfs4000-22D070(config-device-00-23-68-93-11-34-if-radio2)# 3) mesh client Commit and Write rfs4000-22D070(config-device-00-23-68-93-11-34-if-radio2)#com wr ap71xx 00-23-68-93-11-34 use profile default-ap71xx use rf-domain default hostname ap7131-931134 How-To-Guide for Single Hop Mesh bridge vlan 1 interface radio1 wlan MD-RFS4000 bss 1 primary interface radio2 mesh client wlan mesh bss 2 primary no use dhcp-server-policy 3.3 AP-650 Setup is Identical as 7131 with one exception: 1. Configuration-persistence needs to be turned on for the Portal AP 1) Login as self ap650-3185CD88#self ap650-3185CD88(config-device-00-23-68-85-CD-88)#configurationpersistence ap650-3185CD88(config-device-00-23-68-85-CD-88)#com wr 2) Radio 2 Setup ap650-3185CD88(config-device-00-23-68-85-CD-88)#interface radio 2 ap650-3185CD88(config-device-00-23-68-85-CD-88-if-radio2)#mesh client 3) Commit and Write ap650-3185CD88(config-device-00-23-68-85-CD-88-if-radio2)#com wr ap650 00-23-68-85-CD-88 use profile default-ap650 use rf-domain default hostname ap650-85CD88 interface radio1 rf-mode 2.4GHz-wlan channel smart power smart data-rates default no preamble-short radio-share-mode off interface radio2 rf-mode 5GHz-wlan channel 149+ power smart data-rates an mesh portal How-To-Guide for Single Hop Mesh wlan test bss 3 primary no preamble-short radio-share-mode off lock-rf-mode configuration-persistence 2. Configuration-persistence has to be “Enabled” on the Client AP-650 1) ap650-313088#self ap650-313088(config-device-00-23-68-31-30-88)#configuration-persistence ap650-313088(config-device-00-23-68-31-30-88)#com wr 2) ap650-313088(config-device-00-23-68-31-30-88)#interface radio 2 ap650-313088(config-device-00-23-68-31-30-88-if-radio2)#mesh client ap650-313088(config-device-00-23-68-31-30-88-if-radio2)#com wr 3) ap650 00-23-68-31-30-88 use profile default-ap650 use rf-domain default hostname ap650-313088 interface radio1 rf-mode 2.4GHz-wlan channel smart power smart data-rates default no preamble-short radio-share-mode off interface radio2 rf-mode 5GHz-wlan channel smart power smart data-rates an mesh client wlan test bss 1 primary no preamble-short radio-share-mode off lock-rf-mode configuration-persistence How-To-Guide for Single Hop Mesh 3.4 Configuration-Persistence GUI 1) On the GUI interface 2) Configuration,AP-650-xx-xxx 3) Management, Persist configuration across reloads, “Enable” How-To-Guide for Single Hop Mesh 4. RF Switch Running Configuration: The following shows the running configuration of the RFS4000 switch used to create this guide: RFS4000# show running-config ! ! Configuration of RFS4000 version 5.2.0.0-032D ! ! version 2.1 ! ! ip access-list BROADCAST-MULTICAST-CONTROL permit tcp any any rule-precedence 10 rule-description "permit all TCP traffic" permit udp any eq 67 any eq dhcpc rule-precedence 11 rule-description "permit DHCP replies" deny udp any range 137 138 any range 137 138 rule-precedence 20 rule-description "deny windows netbios" deny ip any 224.0.0.0/4 rule-precedence 21 rule-description "deny IP multicast" deny ip any host 255.255.255.255 rule-precedence 22 rule-description "deny IP local broadcast" permit ip any any rule-precedence 100 rule-description "permit all IP traffic" ! mac access-list PERMIT-ARP-AND-IPv4 permit any any type ip rule-precedence 10 rule-description "permit all IPv4 traffic" permit any any type arp rule-precedence 20 rule-description "permit all ARP traffic" ! firewall-policy default no ip dos smurf no ip dos twinge no ip dos invalid-protocol no ip dos router-advt no ip dos router-solicit no ip dos option-route no ip dos ascend no ip dos chargen no ip dos fraggle no ip dos snork no ip dos ftp-bounce no ip dos tcp-intercept no ip dos broadcast-multicast-icmp no ip dos land no ip dos tcp-xmas-scan no ip dos tcp-null-scan no ip dos winnuke no ip dos tcp-fin-scan no ip dos udp-short-hdr no ip dos tcp-post-syn no ip dos tcphdrfrag no ip dos ip-ttl-zero no ip dos ipspoof no ip dos tcp-bad-sequence no ip dos tcp-sequence-past-window no ip-mac conflict no ip-mac routing conflict no stateful-packet-inspection-l2 ! igmp-snoop-policy default no igmp-snooping no querier unknown-multicast-fwd ! ! mint-policy global-default ! wlan-qos-policy default qos trust dscp qos trust wmm ! radio-qos-policy default ! aaa-policy mdlab authentication server 1 onboard self mac-address-format pair-colon case upper attributes all accounting server preference auth-server-number How-To-Guide for Single Hop Mesh ! captive-portal cp access-type no-auth server host 192.168.2.100 server mode centralized terms-agreement ! wlan MD-RFS4000 ssid MD-RFS4000 vlan 1 bridging-mode tunnel encryption-type ccmp authentication-type none wpa-wpa2 psk 0 george01 no ip arp header-mismatch-validation ! wlan cp ssid cp vlan 1 bridging-mode local encryption-type ccmp authentication-type eap use aaa-policy mdlab use captive-portal cp ! wlan mesh ssid mesh vlan 1 bridging-mode tunnel encryption-type none authentication-type none no broadcast-ssid no answer-broadcast-probes ! smart-rf-policy MD-Lab group-by area assignable-power 5GHz max 8 assignable-power 2.4GHz max 8 ! radius-group onboard-ap policy day mo policy day tu policy day we policy day th policy day fr policy day sa policy day su ! radius-user-pool-policy ap-users user pete password 0 miller group onboard-ap ! radius-server-policy on-ap-radius use radius-user-pool-policy ap-users authentication eap-auth-type peap-gtc ! dhcp-server-policy vlan1 dhcp-pool pool1 network 192.168.2.0/24 address range 192.168.2.200 192.168.2.240 default-router 192.168.2.100 ! ! management-policy default no http server https server ssh user admin password 1 d33cd505a9f0f040022a95c135da53fdeda5e09764f3e54887847d01bc8073f4 role superuser access all user operator password 1 20e0dc7ded6f5deaaec5f3dc9cf71b690b2faaa52bceed16f645f5ac98c5a555 role monitor access all no snmp-server manager v2 snmp-server community public ro snmp-server user snmptrap v3 encrypted des auth md5 0 motorola snmp-server user snmpoperator v3 encrypted des auth md5 0 operator snmp-server user snmpmanager v3 encrypted des auth md5 0 motorola ! profile rfs4000 default-rfs4000 autoinstall configuration autoinstall firmware crypto isakmp policy default How-To-Guide for Single Hop Mesh crypto ipsec transform-set default esp-aes-256 esp-sha-hmac interface radio1 interface radio2 interface up1 ip dhcp trust qos trust dscp qos trust 802.1p interface ge1 ip dhcp trust qos trust dscp qos trust 802.1p interface ge2 ip dhcp trust qos trust dscp qos trust 802.1p interface ge3 ip dhcp trust qos trust dscp qos trust 802.1p interface ge4 ip dhcp trust qos trust dscp qos trust 802.1p interface ge5 ip dhcp trust qos trust dscp qos trust 802.1p interface wwan1 use firewall-policy default logging on service pm sys-restart ! profile ap71xx default-ap71xx autoinstall configuration autoinstall firmware interface radio1 preamble-short interface radio2 wlan MD-RFS4000 bss 1 primary interface radio3 interface ge1 ip dhcp trust qos trust dscp qos trust 802.1p interface ge2 ip dhcp trust qos trust dscp qos trust 802.1p interface vlan1 ip address dhcp ip dhcp client request options all interface wwan1 use firewall-policy default logging on service pm sys-restart ! profile ap6532 default-ap6532 autoinstall configuration autoinstall firmware interface radio1 interface radio2 interface ge1 ip dhcp trust qos trust dscp qos trust 802.1p interface vlan1 ip address dhcp ip dhcp client request options all use firewall-policy default logging on service pm sys-restart ! profile ap650 default-ap650 autoinstall configuration autoinstall firmware interface radio1 interface radio2 interface ge1 ip dhcp trust qos trust dscp How-To-Guide for Single Hop Mesh qos trust 802.1p interface vlan1 ip address dhcp ip dhcp client request options use firewall-policy default logging on service pm sys-restart ! profile ap6521 default-ap6521 autoinstall configuration autoinstall firmware interface radio1 interface ge1 ip dhcp trust qos trust dscp qos trust 802.1p interface vlan1 ip address dhcp ip address zeroconf secondary ip dhcp client request options use firewall-policy default logging on service pm sys-restart ! profile ap621 default-ap621 autoinstall configuration autoinstall firmware interface radio1 interface ge1 ip dhcp trust qos trust dscp qos trust 802.1p interface vlan1 ip address dhcp ip address zeroconf secondary ip dhcp client request options use firewall-policy default logging on service pm sys-restart ! profile ap6511 default-ap6511 autoinstall configuration autoinstall firmware interface radio1 interface up1 ip dhcp trust qos trust dscp qos trust 802.1p interface fe1 ip dhcp trust qos trust dscp qos trust 802.1p interface fe2 ip dhcp trust qos trust dscp qos trust 802.1p interface fe3 ip dhcp trust qos trust dscp qos trust 802.1p interface fe4 ip dhcp trust qos trust dscp qos trust 802.1p interface vlan1 ip address dhcp ip address zeroconf secondary ip dhcp client request options use firewall-policy default logging on service pm sys-restart ! rf-domain default country-code us use smart-rf-policy MD-Lab control-vlan 1 ! rfs4000 00-23-68-22-D0-70 use profile default-rfs4000 use rf-domain default all all all all How-To-Guide for Single Hop Mesh hostname rfs4000-22D070 license AP DEFAULT-6AP-LICENSE license ADSEC DEFAULT-ADV-SEC-LICENSE ip default-gateway 192.168.2.100 interface vlan1 ip address 192.168.2.100/24 ip dhcp client request options all use dhcp-server-policy vlan1 logging on logging console warnings logging buffered warnings ! ap71xx 00-23-68-93-11-34 use profile default-ap71xx use rf-domain default hostname ap7131-931134 bridge vlan 1 interface radio1 wlan MD-RFS4000 bss 1 primary interface radio2 mesh client wlan mesh bss 2 primary no use dhcp-server-policy ! ap71xx 00-23-68-96-FD-34 use profile default-ap71xx use rf-domain default hostname ap71xx-96FD34 interface vlan1 ip address 192.168.2.190/24 ! ap71xx 00-23-68-97-00-10 use profile default-ap71xx use rf-domain default hostname ap71xx-970010 ip default-gateway 192.168.2.100 use radius-server-policy on-ap-radius interface radio1 wlan cp bss 2 primary interface radio2 mesh portal wlan mesh bss 1 primary interface vlan1 description vlan1 no use dhcp-server-policy ! ! end 5. Reference Documentation: Description Location Motorola RFS WiNG 5.1 System Reference Guide http://support.symbol.com Motorola WiNG 5.1 CLI Reference Guide http://support.symbol.com