From the CLI on the other hand, there is an easy command to change your management user password:
config mgmtuser password username new_password
For example:
config mgmtuser password admin2 mynewpass.
Easy and useful...
.
Monday, August 10, 2009
Controller Admin password
When you create a WLC Management User, you define a password. What if you want to change this password later on? From the controller Web interface, the answer is... you can't. There is no option to "change" a local management user's password. You can delete the user, and re-create it with another password. Not always very handy.
From the CLI on the other hand, there is an easy command to change your management user password:
config mgmtuser password username new_password
For example:
config mgmtuser password admin2 mynewpass.
Easy and useful...
.
From the CLI on the other hand, there is an easy command to change your management user password:
config mgmtuser password username new_password
For example:
config mgmtuser password admin2 mynewpass.
Easy and useful...
.
Sunday, August 9, 2009
Configure your LWAPP AP from the AP CLI
I had this case a couple of times and thought it might be useful for all of us... you know that the AP, upon booting, will try hard to discover a controller, using broadcast, pre-configuration (AP priming as they say) DHCP option 43, DNS, OTAP, etc.
Now my friend has an AP at home, and wants to use it to connect to its corporate network over his VPN link (my friend's router to the company VPN concentrator).
The AP is new, so there is no controller IP address the AP could remember from a previous life (AP priming).
There is no other AP around, so forget about OTAP.
My friend's network is small, so no option 43 or DNS that you can dream of.
Okay. Time to be creative... but Cisco thought about this case!
You can configure your AP directly from the CLI to provide information to it... boot the AP, get yourself a console connection, and try:
AP0023.0410.4aea#lwapp ap ?
controller lwapp primary controller
hostname Configure ap hostname
ip lwapp ap ip command
log-server Configure the syslog server where all LWAPP errors will be logged
As you can see, you can give your AP, in LWAPP mode, information about a controller:
AP0023.0410.4aea#lwapp ap controller ?
ip lwapp primary controller ip
AP0023.0410.4aea#lwapp ap controller ip
AP0023.0410.4aea#lwapp ap controller ip ?
address Configure primary Controller IP address
AP0023.0410.4aea#lwapp ap controller ip add
AP0023.0410.4aea#lwapp ap controller ip address ?
A.B.C.D Controller IP address
AP0023.0410.4aea#lwapp ap controller ip address 10.1.1.10
Done. You AP knows how to get to a controller (careful, if your AP is already connected to a controller, using this command does not make any sense anymore, and you get a nice "ERROR!!! Command is disabled" when you issue it).
You can also give some other information to your AP, such as AP hostname, or syslog IP address where to dump all issues that the AP might encounter while trying to get to your controller. A useful one is the AP IP address:
AP0023.0410.4aea#lwapp ap ip ?
address Configure ap static IP address
default-gateway Configure Default-gateway IP address
Configure both! The AP needs both to get out of the local network.
Once the AP is configured, you can use the show lwapp family of commands to check what is going on, such as the show lwapp ip config to check your AP IP details, or the show lwapp client config to check controller config and friends:
AP0023.0410.4aea#show lwapp client config
configMagicMark 0xF1E2D3C4
chkSumV2 46073
chkSumV1 17487
swVer 4.2.130.0
adminState ADMIN_ENABLED(1)
name AP0023.0410.4aea
location default location
group name
mwarName
mwarName
mwarName (these are the primary, secondary, tertiary controllers)
<.../...>
ApMode Local
Discovery Timer 10 secs
Heart Beat Timer 30 secs
Led State Enabled 1
<.../...>
Configured Switch 1 Addr 10.1.1.10
<.../...>
With this command, no more AP lost in the dark, far from its controller!
Now my friend has an AP at home, and wants to use it to connect to its corporate network over his VPN link (my friend's router to the company VPN concentrator).
The AP is new, so there is no controller IP address the AP could remember from a previous life (AP priming).
There is no other AP around, so forget about OTAP.
My friend's network is small, so no option 43 or DNS that you can dream of.
Okay. Time to be creative... but Cisco thought about this case!
You can configure your AP directly from the CLI to provide information to it... boot the AP, get yourself a console connection, and try:
AP0023.0410.4aea#lwapp ap ?
controller lwapp primary controller
hostname Configure ap hostname
ip lwapp ap ip command
log-server Configure the syslog server where all LWAPP errors will be logged
As you can see, you can give your AP, in LWAPP mode, information about a controller:
AP0023.0410.4aea#lwapp ap controller ?
ip lwapp primary controller ip
AP0023.0410.4aea#lwapp ap controller ip
AP0023.0410.4aea#lwapp ap controller ip ?
address Configure primary Controller IP address
AP0023.0410.4aea#lwapp ap controller ip add
AP0023.0410.4aea#lwapp ap controller ip address ?
A.B.C.D Controller IP address
AP0023.0410.4aea#lwapp ap controller ip address 10.1.1.10
Done. You AP knows how to get to a controller (careful, if your AP is already connected to a controller, using this command does not make any sense anymore, and you get a nice "ERROR!!! Command is disabled" when you issue it).
You can also give some other information to your AP, such as AP hostname, or syslog IP address where to dump all issues that the AP might encounter while trying to get to your controller. A useful one is the AP IP address:
AP0023.0410.4aea#lwapp ap ip ?
address Configure ap static IP address
default-gateway Configure Default-gateway IP address
Configure both! The AP needs both to get out of the local network.
Once the AP is configured, you can use the show lwapp family of commands to check what is going on, such as the show lwapp ip config to check your AP IP details, or the show lwapp client config to check controller config and friends:
AP0023.0410.4aea#show lwapp client config
configMagicMark 0xF1E2D3C4
chkSumV2 46073
chkSumV1 17487
swVer 4.2.130.0
adminState ADMIN_ENABLED(1)
name AP0023.0410.4aea
location default location
group name
mwarName
mwarName
mwarName (these are the primary, secondary, tertiary controllers)
<.../...>
ApMode Local
Discovery Timer 10 secs
Heart Beat Timer 30 secs
Led State Enabled 1
<.../...>
Configured Switch 1 Addr 10.1.1.10
<.../...>
With this command, no more AP lost in the dark, far from its controller!
Thursday, August 6, 2009
Wireless Guest Access common issues
You probably know the Wireless Guest Access feature, by which wireless clients use a Web interface to enter credentials before being allowed to access the network. There are several common issues that you may be facing, and here a re a few suggested solutions...
First, let's verify the process:
Client detects the guest SSID, sends a Authentication request and receives an authentication success reply (authentication is typically open in this type of network).
Client sends an association request, and receives the association reply with AID, nothing special here.
At this stage, the client is associated and can send two types of traffic: DHCP and DNS (warning: except if you setup a preauthentication ACL! In this case, make sure that your ACL does allow DNS and DHCP traffic!). So the client can get an IP address, obtain DNS server information, open a Web browser and try to open an URL. Upon doing so, the DNS server is queried to resolve the URL IP address. Upon seeing the DNS answer, the controller redirects the browser to the authentication page.
In a real or lab network, you may face several issues:
1. No DNS server. Your network is internal, and not DNS server is available to resolve the URLs. Of course, if no DNS server can be queried by your client, the process stops and the Web browser returns a "Cannot open page" message, as the browser does not know how to get to the URL you ask.
Two solutions here:
- Ask your clients to open directly the Web authentication page, typically in the form https://1.1.1.1/login.html.
- Play with your client hosts file! If your client is a Windows client, this file is located under %windir%\system32\drivers\etc\. In Linux, it is typically under /etc. The hosts files contains the DNS entries that your client can know without asking an external DNS server. Insert a line in this file in the form "1.1.1.1 https://mynicepage.com", then ask your clients to use mynicepage.com/login.html as their default page.
2. Special port: you want to authenticate your clients on your WLC, but not on the default port 80. By default, the controller redirects queries on port 80 to the Web Authentication page, but all other ports (apart from DNS and DHCP) are blocked. What if you need to redirect them when they open, say, port 5000?
Go to your controller CLI, and enter: config network web-auth-port 5000.
Then ask your clients to open their browser with the relevant port, in the form http://www.cisco.com:5000 (this supposes of course that you solved the "no DNS" issue).
3. Default proxy: this is a classic one. Many clients say "hey, all of my clients are configured to use the proxy 10.10.10.10. When I open the browser, they are redirected to the proxy, no matter what, and they never get the Web Authentication page.
Just configure their browser not to proxy for 1.1.1.1... this configuration is commonly under the options of the browser, in the section where you configure proxy settings. There is often an "Exceptions" or "Advanced" button where you can say that when the address is 1.1.1.1, do not use the default proxy.
Feel free to add other issues you see in your deployments/labs!
First, let's verify the process:
Client detects the guest SSID, sends a Authentication request and receives an authentication success reply (authentication is typically open in this type of network).
Client sends an association request, and receives the association reply with AID, nothing special here.
At this stage, the client is associated and can send two types of traffic: DHCP and DNS (warning: except if you setup a preauthentication ACL! In this case, make sure that your ACL does allow DNS and DHCP traffic!). So the client can get an IP address, obtain DNS server information, open a Web browser and try to open an URL. Upon doing so, the DNS server is queried to resolve the URL IP address. Upon seeing the DNS answer, the controller redirects the browser to the authentication page.
In a real or lab network, you may face several issues:
1. No DNS server. Your network is internal, and not DNS server is available to resolve the URLs. Of course, if no DNS server can be queried by your client, the process stops and the Web browser returns a "Cannot open page" message, as the browser does not know how to get to the URL you ask.
Two solutions here:
- Ask your clients to open directly the Web authentication page, typically in the form https://1.1.1.1/login.html.
- Play with your client hosts file! If your client is a Windows client, this file is located under %windir%\system32\drivers\etc\. In Linux, it is typically under /etc. The hosts files contains the DNS entries that your client can know without asking an external DNS server. Insert a line in this file in the form "1.1.1.1 https://mynicepage.com", then ask your clients to use mynicepage.com/login.html as their default page.
2. Special port: you want to authenticate your clients on your WLC, but not on the default port 80. By default, the controller redirects queries on port 80 to the Web Authentication page, but all other ports (apart from DNS and DHCP) are blocked. What if you need to redirect them when they open, say, port 5000?
Go to your controller CLI, and enter: config network web-auth-port 5000.
Then ask your clients to open their browser with the relevant port, in the form http://www.cisco.com:5000 (this supposes of course that you solved the "no DNS" issue).
3. Default proxy: this is a classic one. Many clients say "hey, all of my clients are configured to use the proxy 10.10.10.10. When I open the browser, they are redirected to the proxy, no matter what, and they never get the Web Authentication page.
Just configure their browser not to proxy for 1.1.1.1... this configuration is commonly under the options of the browser, in the section where you configure proxy settings. There is often an "Exceptions" or "Advanced" button where you can say that when the address is 1.1.1.1, do not use the default proxy.
Feel free to add other issues you see in your deployments/labs!
Wednesday, August 5, 2009
7921 Web interface
You can configure the 7921 phone using the phone keypad, or use a comfortable Web interface...
You can get a USB cable that connects your 7921 to your local PC. Installing the driver on your PC creates a virtual network interface on your PC. Give it any address in the 192.168.1.0/24 network (except 192.168.1.100), and you are ready to open an https session to your 7921, which is listening at https://192.168.1.100. Check here for more details on how to install the USB driver, install with Windows is sometimes... interesting...
http://www.cisco.com/en/US/docs/voice_ip_comm/cuipph/7921g/6_0/english/administration/guide/7921cfgu.html
From the Web interface, you can monitor your phone and configure many items such as WLANs and anything else you would configure using the phone keypad... this is "if" you have write access to your phone via the Web interface... how does that work? This is where it gets easy:
1. If the phone is set to factory default, you can access with Read/Write rights without restriction. Use the credentials admin/Cisco to access the phone configuration pages.
2. If the phone has already registered to a Communications Manager (CUCM), the possibility to Write depends on what configuration was sent from the CUCM to your phone. The CUCM admin may have allowed the Read/Write access... or not! The default is not to allow it, because why would your average user access this interface anyway, hey? They are supposed to USE the phone, not to PLAY with its configuration.
On your phone interface, you can verify if you have Web Read/Write access by going to Settings > Device Configuration > Security Configuration, check if Web Access is set to Full, Readonly or Disabled. You can also try to https to the phone, and see how far you go...
Now, what if you do not have the USB cable... and still want to use the Web interface? Well, that's kind of easy too... create a basic cisco WLAN on your controller (open authentication, no encryption), and reset your phone to factory default (go to Settings > phone settings > type **2 > Click yes to accept the reset to factory default)... the phone reboots, looks for the cisco SSID (that's the default behaviour), associates, and gets an IP address through DHCP. Just HTTPS to that IP address and you are on the phone Web Interface, with full read/Write access.
You can get a USB cable that connects your 7921 to your local PC. Installing the driver on your PC creates a virtual network interface on your PC. Give it any address in the 192.168.1.0/24 network (except 192.168.1.100), and you are ready to open an https session to your 7921, which is listening at https://192.168.1.100. Check here for more details on how to install the USB driver, install with Windows is sometimes... interesting...
http://www.cisco.com/en/US/docs/voice_ip_comm/cuipph/7921g/6_0/english/administration/guide/7921cfgu.html
From the Web interface, you can monitor your phone and configure many items such as WLANs and anything else you would configure using the phone keypad... this is "if" you have write access to your phone via the Web interface... how does that work? This is where it gets easy:
1. If the phone is set to factory default, you can access with Read/Write rights without restriction. Use the credentials admin/Cisco to access the phone configuration pages.
2. If the phone has already registered to a Communications Manager (CUCM), the possibility to Write depends on what configuration was sent from the CUCM to your phone. The CUCM admin may have allowed the Read/Write access... or not! The default is not to allow it, because why would your average user access this interface anyway, hey? They are supposed to USE the phone, not to PLAY with its configuration.
On your phone interface, you can verify if you have Web Read/Write access by going to Settings > Device Configuration > Security Configuration, check if Web Access is set to Full, Readonly or Disabled. You can also try to https to the phone, and see how far you go...
Now, what if you do not have the USB cable... and still want to use the Web interface? Well, that's kind of easy too... create a basic cisco WLAN on your controller (open authentication, no encryption), and reset your phone to factory default (go to Settings > phone settings > type **2 > Click yes to accept the reset to factory default)... the phone reboots, looks for the cisco SSID (that's the default behaviour), associates, and gets an IP address through DHCP. Just HTTPS to that IP address and you are on the phone Web Interface, with full read/Write access.
Tuesday, August 4, 2009
7921 boot process
When you reset a 7921 VoIP phone to factory defaults (Toolbox > Phone Settings > **2 > Yes), the phone automatically looks upon rebooting for the SSID cisco, open authentication, no encryption.
Whatever the phone configuration is, it first behaves like a standard 802.11 client, it scans channels and looks for the SSID it is configured to use (cisco and/or any other SSIDs that you may have configured in the different profiles that may be enabled at boot time).
Once it has found a valid SSID, it tries to authenticate/associate. On the phone screen, you see "Locating Network Services".
Once this step succeeds (the phone associated successfully), the 7921 needs to get an IP address, usually through DHCP (you see "Configuring IP").
Along with the IP address, the phone should get the IP address of a TFTP server (this is called option 150 in the DHCP scope). The phone needs this TFTP server to obtain its configuration file and verify that its firmware is the right one. Usually, the TFTP server is directly the Call manager or Call Manager Express, but it could be a standard TFTP server.
Once the phone has its configuration file, it reads from it the list of Call Managers (Express or not) that it is supposed to try to reach. It contacts them one by one (you see "Configuring CM List" on the phone screen).
The nice thing about using the Call Manager (CUCM) or Call Manager Express (CME) as the TFTP is that finding the CUCM or CME is easy!
Once the phone successfully found a CME or CUCM, it registers to it (you see "Registering" on the phone). This is the step where the 7921 gets its extension number.
The phone is then ready to place and receive calls.
When you configure the 7921 from its screen, most features are locked. You unlock them by keying **#. As soon as you key these three keys, a new soft button appears, displaying "Change" or "Edit".
Whatever the phone configuration is, it first behaves like a standard 802.11 client, it scans channels and looks for the SSID it is configured to use (cisco and/or any other SSIDs that you may have configured in the different profiles that may be enabled at boot time).
Once it has found a valid SSID, it tries to authenticate/associate. On the phone screen, you see "Locating Network Services".
Once this step succeeds (the phone associated successfully), the 7921 needs to get an IP address, usually through DHCP (you see "Configuring IP").
Along with the IP address, the phone should get the IP address of a TFTP server (this is called option 150 in the DHCP scope). The phone needs this TFTP server to obtain its configuration file and verify that its firmware is the right one. Usually, the TFTP server is directly the Call manager or Call Manager Express, but it could be a standard TFTP server.
Once the phone has its configuration file, it reads from it the list of Call Managers (Express or not) that it is supposed to try to reach. It contacts them one by one (you see "Configuring CM List" on the phone screen).
The nice thing about using the Call Manager (CUCM) or Call Manager Express (CME) as the TFTP is that finding the CUCM or CME is easy!
Once the phone successfully found a CME or CUCM, it registers to it (you see "Registering" on the phone). This is the step where the 7921 gets its extension number.
The phone is then ready to place and receive calls.
When you configure the 7921 from its screen, most features are locked. You unlock them by keying **#. As soon as you key these three keys, a new soft button appears, displaying "Change" or "Edit".
Monday, August 3, 2009
RRM (Radio Resource Management) deep dive
I has several questions about details on RRM mechanism, so I uploaded 5 videos on Youtube about RRM:
- The first video (http://www.youtube.com/watch?v=gwCxVwmHnRw) describes RRM principles
- The second video (http://www.youtube.com/watch?v=XhmnXeeLQBc) goes deeper into RRM and provides useful information if you are to take a Cisco exam on Wireless related topics! :-)
- The third video (http://www.youtube.com/watch?v=3EnvhxjzEWU) details how RRM controls the AP channel assignment with DCA (Dynamic Channel Assignment).
- The fourth video (http://www.youtube.com/watch?v=32YWzuXTg5M) explains how RRM dynamically reduces AP power with TPC (Transmit Power Control)
- The fifth video (http://www.youtube.com/watch?v=yot63RsKOCg) explains how the Radio Coverage Detection Algorithm works.
Each video is only a few minutes long... hope they are usuful!
- The first video (http://www.youtube.com/watch?v=gwCxVwmHnRw) describes RRM principles
- The second video (http://www.youtube.com/watch?v=XhmnXeeLQBc) goes deeper into RRM and provides useful information if you are to take a Cisco exam on Wireless related topics! :-)
- The third video (http://www.youtube.com/watch?v=3EnvhxjzEWU) details how RRM controls the AP channel assignment with DCA (Dynamic Channel Assignment).
- The fourth video (http://www.youtube.com/watch?v=32YWzuXTg5M) explains how RRM dynamically reduces AP power with TPC (Transmit Power Control)
- The fifth video (http://www.youtube.com/watch?v=yot63RsKOCg) explains how the Radio Coverage Detection Algorithm works.
Each video is only a few minutes long... hope they are usuful!
Sunday, August 2, 2009
WCS Planning mode and VoWLAN
What is a good VoWLAN design?
-67 dBm RSSI at the edge of the cell, aiming for less than 1% packet loss to get a MOS (with G711 codec) of 4.1 or better. Typically speed in the cell would be set to 24 Mbps or more (lower speed disabled) for 802.11a or 802.11g, and 11 Mbps or more for 802.11b/g. This last figure makes that some people would say "12 Mbps or more for 802.11g", to have 802.11g value close to the 802.11b/g value.
The main point is that if RSSI is good at the edge of the cell, and if SNR is good at that point (25 dB or more), then call quality would be good.
Now take the WCS, in planning mode, and ask it for Voice service... the network will be designed with the following predictive RSSI at the edge of the cell:
- Aggressive = Minimum [-78 dBm (802.11a/b/g)]
- Safe = Medium [-75 dBm (802.11a/b/g)]
- Very Safe = Maximum [(-72 dBm (802.11a/b/g)]
- 7920_enabled = [(-72 dBm (802.11a); -67 dBm (802.11b/g)]
All these values are way below all Cisco recommendations... you'll need to manually tune the Planning Mode result to get an acceptable predictive coverage...
-67 dBm RSSI at the edge of the cell, aiming for less than 1% packet loss to get a MOS (with G711 codec) of 4.1 or better. Typically speed in the cell would be set to 24 Mbps or more (lower speed disabled) for 802.11a or 802.11g, and 11 Mbps or more for 802.11b/g. This last figure makes that some people would say "12 Mbps or more for 802.11g", to have 802.11g value close to the 802.11b/g value.
The main point is that if RSSI is good at the edge of the cell, and if SNR is good at that point (25 dB or more), then call quality would be good.
Now take the WCS, in planning mode, and ask it for Voice service... the network will be designed with the following predictive RSSI at the edge of the cell:
- Aggressive = Minimum [-78 dBm (802.11a/b/g)]
- Safe = Medium [-75 dBm (802.11a/b/g)]
- Very Safe = Maximum [(-72 dBm (802.11a/b/g)]
- 7920_enabled = [(-72 dBm (802.11a); -67 dBm (802.11b/g)]
All these values are way below all Cisco recommendations... you'll need to manually tune the Planning Mode result to get an acceptable predictive coverage...
Subscribe to:
Posts (Atom)
Posts
