cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
882
Views
8
Helpful
10
Replies

WiSM Design and Testing Issues / Questions / Queries etc......

sull
Level 1
Level 1

Hi all. Heres hoping you can help........

I hope you can grasp the following description of the test network I have. I admit a diagram would have been better but it's hard to send a whiteboard over the web : )

I am currently in the process of designing and testing out a wireless solution and am having a few issues / queries. I have a 6509 with a Wireless Services Module (WiSM) installed in slot 3, one Cisco 1240 AP on a remote LAN and a DHCP server on a remote LAN (not the same as the AP)

I am using LAG on controller 1 with port channel 1 and native VLAN 20.

VLAN 20 is 10.1.1.0 / 24

The management interface has IP address of 10.1.1.10

The AP-manager interface has IP address of 10.1.1.11

VLAN 11 is 128.88.1.0 / 24

The service port has IP address of 128.88.1.10

The Cisco 1240 AP on the remote LAN is picking up a IP address via DHCP (from a remote DHCP server) OK and can route to both the aforementioned VLANs 20 and 11.

Issue/Question 1

----------------

I can ping the management interface locally on the 6509 and also remotely from the AP so all looks OK there however I cannot ping the AP-manager locally or remotely.

Is this expected behaviour? I would expect that if I can ping one I should be able to ping the other or is the AP-manager interface not routed and only used in some way to create the LWAPP tunnel>

Issue/Question 2

----------------

As previously stated the AP is picking up and IP address but it is not being passed the Option 43 parameter from the DHCP server (not yet ruled out the DHCP server as the cause of this). Due to this I have amended the DNS entry of the management interface (10.1.1.10) to CISCO-LWAPP-CONTROLLER as a last resort. With a console on the AP I can see that the AP tries to join by the "%LWAPP-5-CHANGED: LWAPP changed state to JOIN" output but then get;

LWAPP_CLIENT_ERROR_DEBUG: spamHandleJoinTimer: Did not recieve the Join response

LWAPP_CLIENT_ERROR_DEBUG: No more AP manager IP addresses remain.

Is this related to the fact that I cannot see the AP-Manager interface on the network?

Issue/Question 3

----------------

I have chosen to hard code the IP address of the Service port rather than leave it to DHCP. I am more comfortable having static addresses for management. However, there is no option for a default gateway for the service port.... If I try to get round this by applying a static route via the CLI on the WiSM controller to point traffic out via 128.88.1.1 on VLAN 11 this seemingly overrides all routing on the controller and causes my management interface (10.1.1.10) to fall off the network. Is the routing table applied "en masse" to the Controller? If so this surely means that to use the Service Port you have to be on the local LAN segement?!?!

Thanks for reading my ramble and heres hoping you can shed some light on my "niggles" !

10 Replies 10

ethiel
Level 3
Level 3

I'll give this a shot:

1. You should not be able to ping the AP-Manager IP. That is expected.

2. This should not have anything to do with not being able to ping AP-Manager. For the DNS entry, can you confirm that you added a FQDN. For instance it should be cisco-lwapp-controller.mydomain.com and then the DHCP scope must hand the APs a valid DNS server and a DNS suffix of mydomain.com. If you have already done so, please reply and I will see what else I can think of.

3. Hard-coding is fine. DHCP is just how to boot it up the first time. However, they do not intend for you to route the service interface after deployment. After that, you can use the Management IP for management. The service IP is primarily for local access from the 6500 as I understand it.

-Eric

Please remember to rate all helpful posts.

Hi. Thanks for the post.

>1. You should not be able to ping the AP-Manager IP. That is expected.

Good that confirms that for me

>2. This should not have anything to do with not being able to ping AP-Manager. For the DNS entry, can you confirm that you added a FQDN. For instance it should be cisco-lwapp-controller.mydomain.com and then the DHCP scope must hand the APs a valid DNS server and a DNS suffix of mydomain.com. If you have already done so, please reply and I will see what else I can think of.

Yes. The DNS is a FQDN but still no avail.

>3. Hard-coding is fine. DHCP is just how to boot it up the first time. However, they do not intend for you to route the service interface after deployment. After that, you can use the Management IP for management. The service IP is primarily for local access from the 6500 as I understand it.

Thanks for confirming this too.

As an update we have installed a standalone 4404 as a test to see if this makes any difference and alas it does. The AP can quite happily associate with the Controller so the investigation goes on with regards WiSM.....

UPDATE: We finally solved why we were having these issues with the AP associating with the Controller. It was due to the fact we didnt have NTP configured on our test bed.

NTP is required for certificate validation between the WiSM and the access point.

koeppend
Level 4
Level 4

Hi

I am having exactly the same problem.

Getting the same error message "No more AP manager IP addresses remain."

I'm deploying 200 AP's that will connect to 2x WiSM (4 controllers) in 2 seperate C6k Chassis

(Controller 1a & 1b = wism 1, 2a & 2b = wism 2)

I have had 1 out of the first 5 AP's physically connected, come online and register with Controller 2b (btw: this was not the master controller, it should not have registed with 2b). All others fail with the same error message as above.

I have all Management and AP-Manager interfaces in the same vlan/subnet as my AP's.

I place a console cable onto the failed APs and see the AP cycle though the motions of trying to find the controllers, download new software code from a random controller, then it reboots, gets DHCP assigned, then get the "No more AP manager ip addresses remain" and then issues a "Reload requested by LWAPP CLIENT.

Then the AP does the whole cycle all over again.

Not sure why the AP's don't register with the controllers when they are all in the same vlan.

I have a couple of extra questions.

1. what address do you bind to the dns entry cisco-lwapp-controller.localdomain, is it the management address or AP-Manager address ?

I have bound it to the Management address for WiSM 1a.

Also I have 4x controllers (2x WiSMs, 2 controllers per WiSM). Do I just bind controller 1a's address or do I have to put 4x DNS entries into my DNS server for all my controllers?

2. DHCP option 43, Do I place all 4x management ip addresses in the option or do I put in the AP-Manager Ip address?

I followed this guide but was still a little unsure http://www.cisco.com/en/US/products/hw/wireless/ps430/prod_technical_reference09186a00804fc3dc.html#wp125304

2. This final question is more around Dynamic Interfaces for my 4 controllers once I get the AP's resisted,

Do I have to set up a dynamic interface ip address on every controller?

e.g.

Ssid = data, VLAN=10, VLAN10=10.0.0.0/24, I will bind AP's 1-8 to VLan group 10.

Do I have to setup 1 dynamic interfaces per controller in the 10.0.0.0 subnet, taking up 4 addresses ?

And if I only have to set up 1 or 2 dynamic interface, how does this work if the controller fails?

Cheers

Dale, I'll see if I can answer...

Make sure all 4 controllers are in the same mobility group. Each controller should peer with the other 3 controllers. Configure NTP and make sure all 4 controllers have the same time. I've seen access points not join and get the "No more AP manager ip addresses remain" because of NTP sync.

Both DHCP option 43 and the FQDN cisco-lwapp-controller.localdomain should point to the management address of the master controller. I prefer OPT 43 as it allows me to use DHCP vendor class and have a unique address and controllers for each campus. Access points are supposed to round robin JOIN all members of a Mobility group unless you select a master controller. Cisco recommends setting a Master initially and then manually configuring the primary/secondary/tertiary controller for each access point. You'll need to use the controller name here and not the IP address. To reduce inter-controller roaming events, configure all access points on a floor or area to use the same primary controller. That way, roaming down a hall or room to room stays on a specific controller.

The management and dynamic interfaces should be pretty much identical on each controller, just vary the IP address. For example lets say the management and ap-manage subnet is 10.10.1.0/24 and the dynamic is 10.20.1.0/24. Then...

Controller 1

manage 10.10.1.1

ap-man 10.10.1.2

dynamic-1 10.20.1.1

Controller 2

manage 10.10.1.3

ap-man 10.10.1.4

dynamic-1 10.20.1.3

Controller 3

manage 10.10.1.5

ap-man 10.10.1.6

dynamic-1 10.20.1.5

Controller 4

manage 10.10.1.7

ap-man 10.10.1.8

dynamic-1 10.20.1.7

This assumes you have L2 between all controllers. L3 between the controllers would be a different story. The controllers can handle a L3 roam, but for me L2 is easier for IP phones and Vocera badges. Also our access points are not in the same subnet as the controllers. Each closet has a unique address range and the access points use L3 LWAPP to talk with the controllers. The Join handshake initially communicates with the management ip address and then the controller sends back all ap-manager addresses in the mobility group. From that point on the access points talk only to the ap-managers.

Hope this helps.

Darren

Thank you for the info.

From the working AP's I have here, the solutions you posted worked fine. So far 4 out of 10 APs worked first go.

For the 6 other AP's that don?t register, raising a TAC case, it doesn?t make sense that some work and some don?t. I did how ever upgrade code on the WiSM, instead of AP?s rebooting, they now just cycle though the discovery process, over and over again.

AP's just constantly cycle due to following error messages:

* LWAPP changed to JOIN

* Found the discovery response from the MASTER Mwar

* Did not receive the Join response

* No more AP manager IP addresses remain.

* Retransmission count for packet exceeded more than max

* GOING BACK TO DISCOVER MODE

Thanks again for your help

*EDIT*

Darren

Thank you for the info.

From the working AP's I have here, the solutions you posted worked fine. So far 4 out of 10 APs worked first go.

For the 6 other AP's that don?t register, raising a TAC case, it doesn?t make sense that some work and some don?t. I did how ever upgrade code on the WiSM, instead of AP?s rebooting, they now just cycle though the discovery process, over and over again.

AP's just constantly cycle due to following error messages:

* LWAPP changed to JOIN

* Found the discovery response from the MASTER Mwar

* Did not receive the Join response

* No more AP manager IP addresses remain.

* Retransmission count for packet exceeded more than max

* GOING BACK TO DISCOVER MODE

Thanks again for your help

*EDIT*

BTW Darren, I'm following your post under the general forums titled

"General: AP's randomly disconnect after upgrade to 4.0.206.0"

I just realised that this is now the same issue

Dale,

How are the port channels configured on the 6509 connecting internally to the WISM (LAG)? I ran into an issue that sounds similar to yours where sometimes the AP would JOIN and sometimes not. I was using a L4 hash (port-channel load-balance src-dst-port) on the Etherchannel instead of the default L3 hash. Basically the JOIN handshake was getting interleaved across multiple links and the WISM does not know how to reassemble. Try shutting down 3 of the 4 GigE ports connecting to the WISM and see what happens. Just a thought.

FYI I've had good luck with 4.0.155.5

Darren

That worked, it is either the channel hash change or a WiSM reboot. (I wish I had not done both) but either the reboot or the command has fixed my problem. All the AP's are now registering with the WiSM on first load.

But this has led me to a new "feature" with the port channel. Firstly my port channel looks like this

interface port-channel200

switchport

switchport trunk encapsulation dot1q

switchport trunk native vlan

switchport trunk allwed vlan <1, mgt, svc, user wifi-vlans>

switchport mode trunk

switchport nonedotiate

no ip address

mls qos trus cos

interface GigabitEthernet7/1 - 4

switchport

switchport trunk encapsulation dot1q

switchport trunk native vlan

switchport trunk allwed vlan <1, mgt, svc, user wifi-vlans>

switchport mode trunk

switchport nonedotiate

no ip address

mls qos trus cos

channel-group 200 mode on

I just discovered that every time I reboot the C6K, the switch does not establish my original port channel 200 and 201 that I saved in the config. Instead it sets up its own etherchannel of 295 and 296. Even when I completely wipe all config off the interfaces, recreate the port channel 200 bind ports 7/1-4 to channel 200 save and reload,... wism interfaces 7/1 - 4 set them selves up in channel-group 295 and 7/5-8 get set up in 296.

Now when I perform a

"show wism module 7 controller 1"

I can see that the port channel number is set to 295 on the wism.

Is there a way to change this ?

Does your Switch maintain its port channel after a reload ? Also when you do a "show ether summary" do you have two other channel numbers that fall outside of the standard 1 - 256 channel range

(I?m using IOS 12.2(18)SXF7 on the sup720)

Got a fix from the TAC.

See attached doc

2 problems solved, ...thx Darren for previous info.

Dale, Where did you get that document? It looks like the WISM guide but is different than the one on Cisco's support site. Email me and we can take this offline.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: