L3 intra-controller roam

Hi folks,
I fully understand how Layer 2/3 roam function and role of EoIP in an inter-controller enviornment.L2 intra-controller roaming also pretty straightforward.
However, L3 intra-controller roaming is not very clear to me.Could someone throw some light on the matter pls?Also if you could point me to to a Cisco doco that would be great.
Thanks,
J

Janesh,
     Correct, the client does not need to refresh it's IP, or get a new one.
     The configuration guide and the mobility FAQ should speak to this. As for the mechanism. When you are roaming inside the same WLC it knows that the client hasn't moved off of it, so it just updates the MSCB entry and the client rolls along.
     Now if you roam from WLC-A to WLC-B, the WLC looks at the interface name, and ip address assigned to that interface. If the subnets match, the MSCB entry from WLC-A is moved to WLC-B. The traffic for the client will ingress and egress on WLC-B. This is a Layer 2 roam.
     Now the client roams from WLC-A to WLC-B, the WLC looks at the interface name, and ip address assigned to that interface. The subnets do not, WLC-A copies the MSCB entry to WLC-B, then they pass the client traffic between them for the client. The traffic will ingress on WLC-A, be sent accross the mobility tunnel to WLC-B, and then to the client. The inverse is true for traffic from the client. It flows from the client to WLC-B, across the mobility tunnel to WLC-A, and then egress to the network there. This is a Layer 3 roam.
HTH,
Steve
Please remember to rate helpful posts or to mark the question as answered so that it can be found later.

Similar Messages

Intra controller roaming and Security

Hi all,
Under the section intra controller roaming, WLC 7.0 config guide states that " When the wireless client moves its association from one access point to another, the controller simply updates the client database with the newly associated access point. If necessary, new security context and associations are established as well"
http://www.cisco.com/en/US/docs/wireless/controller/7.0/configuration/guide/c70mobil.html
Within the phrase "If necessary, new security context and associations are established as well" . Could someone elaborate on what is meant by the new security context ? My understanding is that only an update to the MSCB (with the AP info) is the only requirement as the client is within the same controller and subnet.I just can't think why would the security info needs to be updated.
Thanks in advance.
J

Well if during the roam the users session times out or a re-keying occurs the information has to be passed to the WLC. The AP does all the encrypt/decrypt if using encryption. This doesn't happen if your using open.
Sent from Cisco Technical Support iPhone App

Is it possible to disable intra-controller roaming with 1510AP

Hi all,
Is it possible to disable intra-controller roaming with 1510AP?
Thanks

Intra-controller roaming is enabled by default and cant be disabled.Refer URL
http://cisco.com/en/US/products/ps6366/products_configuration_guide_chapter09186a008063f3b9.html#wp1093741

Intra-Controller roaming and AP Groups

WiSM 2 controllers running 7.3.101.0
All controllers have the same subnets/dynamic interfaces/WLAN
All controllers in same mobility group.
Controller1
AP1 has APGROUP1 applied
APGROUP1 has SSID1 mapped to DynintVLAN1
Controller2
AP2 has APGROUP2 applied
APGROUP2 has SSID1 mapped to DynIntVLAN2
Client associates to AP1 and gets IP from DynintVLAN1
Client roams to AP2. Keeps IP address but connectivity stops.
Client shows in Controller 1 to be Anchored to Controller 1
Client shows in Controller 2 to be mobile client and mapped to Controller 1 but interface shows as DynintVLAN2
My understanding with this configuration is that the client should stay connected via mobility to Controller 1 but it seems to stay authenticated but looses connectivity.
Any thoughts?
Thanks.

I checked eping and mping between these controllers and no problem
When roamed to controller 2 I even tried a dhcp release and renew and that worked! I got my same IP address so I think the mobility parts are working since I was able to get back to the original VLAN. I just cant ping my gateway or off network.
After the roam here are the "sh client detail"
Controller 1 (Anchor)
(Controller1) >show client detail 00:24:D7:37:B7:48
Client MAC Address............................... 00:24:d7:37:b7:48
Client Username ................................. **************deleted
AP MAC Address................................... 00:00:00:00:00:00
AP Name.......................................... N/A
Client State..................................... Associated
Client NAC OOB State............................. Access
Wireless LAN Id.................................. 1
Hotspot (802.11u)................................ Not Supported
BSSID............................................ 00:00:00:00:00:00
Connected For ................................... 1060 secs
Channel.......................................... N/A
IP Address....................................... 172.17.137.241
Gateway Address.................................. Unknown
Netmask.......................................... Unknown
Association Id................................... 0
Authentication Algorithm......................... Open System
Reason Code...................................... 1
Status Code...................................... 0
Client CCX version............................... 4
Client E2E version............................... 1
Re-Authentication Timeout........................ 1583
QoS Level........................................ Silver
--More-- or (q)uit
802.1P Priority Tag.............................. disabled
CTS Security Group Tag........................... Not Applicable
KTS CAC Capability............................... No
WMM Support...................................... Enabled
APSD ACs....................................... BK BE VI VO
Power Save....................................... ON
Current Rate..................................... m15
Supported Rates.................................. 18.0,24.0,36.0,48.0,54.0
Mobility State................................... Anchor
Mobility Foreign IP Address...................... 172.17.12.5
Mobility Move Count.............................. 2
Security Policy Completed........................ Yes
Policy Manager State............................. RUN
Policy Manager Rule Created...................... Yes
Audit Session ID................................. ac110c0e0011541752570af9
IPv4 ACL Name.................................... none
IPv4 ACL Applied Status.......................... Unavailable
IPv6 ACL Name.................................... none
IPv6 ACL Applied Status.......................... Unavailable
Client Type...................................... SimpleIP
PMIPv6 State..................................... Unavailable
Policy Type...................................... WPA2
Authentication Key Management.................... 802.1x
--More-- or (q)uit
Encryption Cipher................................ CCMP (AES)
Management Frame Protection...................... No
EAP Type......................................... PEAP
Interface........................................ zone5dynint743
VLAN............................................. 743
Quarantine VLAN.................................. 0
Access VLAN...................................... 743
Controller2
(Controller2) >show client detail 00:24:D7:37:B7:48
Client MAC Address............................... 00:24:d7:37:b7:48
Client Username .................................**************deleted
AP MAC Address................................... 00:23:eb:81:ec:20
AP Name.......................................... AP2
Client State..................................... Associated
Client NAC OOB State............................. Access
Wireless LAN Id.................................. 1
Hotspot (802.11u)................................ Not Supported
BSSID............................................ 00:23:eb:81:ec:20
Connected For ................................... 212 secs
Channel.......................................... 11
IP Address....................................... 172.17.137.241
Gateway Address.................................. Unknown
Netmask.......................................... Unknown
Association Id................................... 10
Authentication Algorithm......................... Open System
Reason Code...................................... 1
Status Code...................................... 0
Client CCX version............................... 4
Client E2E version............................... 1
Re-Authentication Timeout........................ 1584
QoS Level........................................ Silver
--More-- or (q)uit
802.1P Priority Tag.............................. disabled
CTS Security Group Tag........................... Not Applicable
KTS CAC Capability............................... No
WMM Support...................................... Enabled
APSD ACs....................................... BK BE VI VO
Power Save....................................... ON
Current Rate..................................... m15
Supported Rates.................................. 18.0,24.0,36.0,48.0,54.0
Mobility State................................... Foreign
Mobility Anchor IP Address....................... 172.17.12.14
Mobility Move Count.............................. 3
Security Policy Completed........................ Yes
Policy Manager State............................. RUN
Policy Manager Rule Created...................... Yes
Audit Session ID................................. ac110c05008392c65257ede8
IPv4 ACL Name.................................... none
IPv4 ACL Applied Status.......................... Unavailable
IPv6 ACL Name.................................... none
IPv6 ACL Applied Status.......................... Unavailable
Client Type...................................... SimpleIP
PMIPv6 State..................................... Unavailable
Policy Type...................................... WPA2
Authentication Key Management.................... 802.1x
--More-- or (q)uit
Encryption Cipher................................ CCMP (AES)
Management Frame Protection...................... No
EAP Type......................................... PEAP
Interface........................................ zone1dynint732
VLAN............................................. 732
Quarantine VLAN.................................. 0
Access VLAN...................................... 743

4404 Controller roaming - retaining IP

Hi again guys!
I have this scenario:
We are using a 4404 controller with 3 different subnets (interfaces), all using the same SSID (using AP Groups VLANS). The thing here is that when a client roams from one AP to another AP of different subnet, the IP remains the same, even after resetting the interface on the client. I think this is a normal behavior, I mean, layer 3 roaming. But I want to make sure, and also I would like to know if this behavior can be disabled.
Also, the client doesn't go from one AP to another immediately, I mean, the client stays some time without signal, so I think it should get an IP from the new subnet, not the one it had.
The DHCP server is external, I dont know if this behavior has something to do with lease times on the server or something like that.
Thanks in advance!!

The default session timeout for a WLAN using authentication is 1800 seconds (30 minutes). I think the controller may be considering this client as still having an active session and not timing out their entry, although I would expect it to do so if it loses connectivity. In the IOS days there was a station timeout whereby the controller would send keepalives to verify activity before disassociating the client. I'm not sure what the equivalent keeplive mechanism is now, if there is one.
If the client is on a new subnet the (old) DHCP renew request should be rejected as it would not be served by the (new) interface its sourced on. This should be in a different scope, so the client should obtain a new address sepecific to the scope served by the new source interface (router interface). Unless the client itself is holding onto the address, regardless of the DHCP process.

DEBUG for roaming?

Hi!
I'm currently making some roaming tests with a 2504 WLC and two 2602 APs. I'm just a beginner with wireless technologies.
Which DEBUG commands can be used on the controller to watch the roaming process information?
I've tried the debug client {client MAC} but it seems that the client disassociates from one AP and then reassociates with the other.
Which subject should I read to learn about this process?
Thanks.

First is there any particular goal you have by doing this? So as a beginner let's see if I can help you understand a couple things, I will try to keep it high-level.
So there are several types of roaming, there is Layer 2 intra-controller, and inter-controller and layer 3 roaming. When 2 AP's are connected to the same controller this is called intra-controller roaming. When AP's are connected to multiple controllers in a Mobility Group or Domain, that's inter-controller roaming. When a user roams in all of these scenario's, much of the decision to do so is typically on the client i.e. the WLAN client is always looking for a better signal strength (RSSI) for the same SSID he is connected to. The roaming thresholds vary by client, but generally if a client see's an AP with a much better RSSI, the client will attempt to roam. There are new features which the infrastructure can help the client make better decisions but that's more time than i have.
To visualize this process simply, you can force this to occur on your WLC, by starting a continuous ping on your client ping 8.8.8.8 -t, then go to your WLC and disable the AP the client is currently associated to. You can see which AP the client is connected to on the monitor page-clients and viewing client properties.
If you want to witness the client roaming the best way is above, if you want to see it on a debug try the following.
(Cisco Controller) >debug client 00:00:00:00:00:00 - your clients MAC
(Cisco Controller) >debug mobility handoff enable
(Cisco Controller) >show debug - verify the debug's are running
If this doesn't work let me know, good luck!
~Please rate helpful post~

Load-Balancing between Foreign and two Anchors

Hi, we have two foreign controllers (one active, one standby) and two anchor controllers. All APs are connected to the active foreign controller. The layer 3 networks for the wlan clients on both anchors are different for the same SSID. SSID: Internet, anchor 1: Subnet A, anchor 2: Subnet B. So when a client is getting anchored to Anchor 1, the clients will get an ip from subnet A and when the client is getting anchored to anchor 2, the client will get an ip from subnet B.
This is so far not a big problem because we only have a few accesspoints in some rooms. But what will happen, when we have a full covered wlan and the client roams from one AP to the other AP? Is there a possibility, that the client will anchored to a different anchor while roaming? I think this will result in a lack of connectivity because without a real disconnect the client will not ask for a new IP address.
Other question: Is it possible to disable this load-balancing between anchor controllers? Or can i make a client sticky to only one anchor as long as an access-session is established?
All controllers are 5760 with 3.3.3 software.

Hi acontes,
It's an interesting question.
In this case, if all AP's are on WLC-A and there is no possibility that an L3 inter-subnet roam will occur between WLC-A and WLC-B, I would just forward WLC-A to Anchor A and WLC-B (in the event of fail over) to Anchor B (if Anchors reside on different subnets). If you must specify Anchor A and Anchor B on each WLC for redundancy purposes, it's important to understand the guidelines and limitations with regard to Foreign / Anchor Design.
As Scott mentioned, the limitation with Anchoring design is that there is no primary / secondary configuration for an Anchor on the Foreign WLC.
If WLC-A has two entries (1) for Anchor-A and (2) for Anchor-B, the EoIP tunnels are establish and load-balancing occurs in a round robin fashion.
Keep in mind the following with regard to guest N+1 redundancy:
•A given foreign controller load balances wireless client connections across the list of anchor controllers configured for the guest WLAN. There is currently no method to designate one anchor as primary with one or more secondary anchors.
•Wireless clients that are associated with an anchor WLC that becomes unreachable are re-associated with another anchor defined for the WLAN. When this happens, assuming web authentication is being used, the client is redirected to the web portal authentication page and required to re-submit their credentials.
Since traffic is transported at Layer 2 via EoIP, the first point at which DHCP services can be implemented is either locally on the anchor controller or the controller can relay client DHCP requests to an external server. Since the IP address directly correlates to the DMZ subnet or the interface where the traffic egresses, it is possible for some clients to get IP's from both Subnet A or Subnet B in the event that WLC-A is building EoIP to both anchors.
1) What happens if my clients roam?
Nothing... since all AP's are on WLC-A, it's Intra-Controller Roaming
Each controller supports same-controller client roaming across access points managed by the same controller. This roaming is transparent to the client as the session is sustained, and the client continues using the same DHCP-assigned or client-assigned IP address. The controller provides DHCP functionality with a relay function. Same-controller roaming is supported in single-controller deployments and in multiple-controller deployments.
Would it be better to choose the same DHCP Pool on both anchors?
It's probably better to have redundant anchors on the same subnet, but it's not required.
3) How would you design this :-)
WLC-A <--EoIP--> Anchor A (DHCP Pool A)
WLC-A <--EoIP--> Anchor B (DHCP Pool A)
It's important to remeber what Scott mentioned about the lack of a primary / secondary relationship. If multiple controllers are added as mobility anchors for a particular WLAN on a foreign controller, the foreign controller internally sorts the controller by their IP address. The controller with the lowest IP address is the first anchor. For example, a typical ordered list would be 172.16.7.25, and 172.16.7.28. If the first client associates to the foreign controller's anchored WLAN, the client database entry is sent to the first anchor controller in the list, the second client is sent to the second controller in the list, and so on, until the end of the anchor list is reached. The process is repeated starting with the first anchor controller.
If any of the anchor controller is detected to be down, all the clients anchored to the controller are deauthenticated, and the clients then go through the authentication/anchoring process again in a round-robin manner with the remaining controller in the anchor list. This functionality is also extended to regular mobility clients through mobility failover. This feature enables mobility group members to detect failed members and reroute clients.

2500 series support mobility groups?

Do you know if the new 2500 series controller supports things like mobility groups? Could I use 2 of these and do inter-controller roaming.
Also do you know if this would work with a 2106 controller and a 2505 controller or are they 2 completely independent controllers only knowing about their own APs??

Hi smailmilak,
no mobility and roaming is not the same. You need for roaming between controllers a mobility configuration.
If you have only one 2500 WLC and 25 or more or less AP roaming between the AP on the one WLC will work well.
This calls Intra-Controller roaming
If you have 2 or more WLCs you need a proper mobility config for roaming between APs located on differen WLC.
This Calls Inter-Controller roaming.
More informations are here:
http://www.cisco.com/en/US/docs/wireless/controller/7.0/configuration/guide/c70mobil.html

Caching for Web Portal Authenticated clients

Reading CUWN documentation, Sticky Key Caching works only on WPA2-enabled WLANs. Is it possible to enable a caching to help Web Portal Authenticated clients perform intra-controller roaming faster?

Ok, so here's how it works:
When the client gets on the network, the controller contacts the DHCP server and hands the client back its IP (as with any helper address).
In order for web auth to work, you need to open a browser on the client.
When you go to a page (say www.google.com) your browser does a DNS query for the IP address of the site (www.google.com), the controller intercepts the query.
Since you have not been authenticated yet, the controller does not allow the query directly, but it proxies the query to the DNS server you were trying to resolve against. It sources this query from its interface that is on the VLAN the SSID your client is on maps to.
That reply is proxied back to your computer, and then your browser does its normal request to Google?s IP.
The controller then intercepts that request, and sends a reply back redirecting the browser to the controller login page (usually https://1.1.1.1).
Once you log into the web page, you will be redirected back to your original page (www.google.com).
I hope I explained it well. If I wasn't clear, please let me know.
-Eric

Cisco 7925G phones

We have about 50 Cisco Wireless IP phones where I work, I have set up are WLAN according to document that came with it for the default settings. We are mainly using it for Wireless Voice, but we have alot of computers on it to.
The problem i am having and cant seem to get right is the the phones "Leave Service Area" in the middle of calls or when people are walking around with them.
We have the Wireless coverage needed to support the phones everywhere on are shop floor.
I was wondering if there is a setting i can change so that the phones dont leave the service area when they have the wireless coverage.
Or is there a setting that i can boost to help this from happening.

It depends on your existing power levels/coverage/etc. If you have adequate coverage at -65 with 12Mbps as mandatory then I would not set 6 or 9 to mandatory unless you're still having issues with intra-controlle roaming between APs. The "lowest" mandatory data rate is what the APs will send management traffic on, beacons, probes, etc.
Setting up a lower mandatory data rate may allow your phones to more quickly locate adjacent cells for roaming, but then you can also end up reducing your AP power levels via RRM due to the "APs" hearing each other too well.
Stick with the suggestions made thus far of 12Mbps mandatory, all lower than this disabled. You can "tweak" from there. The 792x deployment guides are not always turn key, but they should be your baseline. Start by configuring your WLC exactly as the config guide suggests. If you're environment still needs changes to data rates/power so be it, but start with the guide and "then" start troubleshooting.

5508 WLC HA pair and layer 3 roaming

Hey,
We have a pair of 5508 WLC's configured in HA (primary/standby). We have a single SSID that we're broadcasting across each floor of our head office. The AP's are in flexconnect mode so users pickup an IP address from the DHCP range for that building level and that's all working well.
The problem I have is that users cannot roam between floors without losing access to the network. They roam to the AP's on the different floors, and maintain wireless connection throughout the building, but they cannot connect to anything on the network when outside of the floor that contains an IP range that matches the client's IP. I was told by a number of technical consultants that this sort of layer 3 roaming should work in this configuration. When users go to a different floor, they retain their original IP and the traffic is tunneled (EOIP) back to the controller to maintain network connectivity, however this does not appear to be happening.
Firstly I'm wondering if this is possible with a HA pair configured in active/standby. All of the documentation around layer 3 roaming seems to involve at least 2 controllers, the foreign and the anchor. In this case as they're a HA pair their is technically only a single controller.
If it is possible to do layer 3 roaming on a single controller (intra-controller), if anyone can provide some guidance on things I should be checking or looking out for that would be appreciated.
Thanks.

Still though, I had a number of technical consultants from a very large system integrator design this setup and despite my asking a number of times how this roaming could work I was simply told it would.
ROFL!
We contracted a consulting company/implementors to do a wireless job (back in 2011) for a particular project (politics dictate I keep stay away from it). They had one "wireless expert".
Then one day, I got a call from the "wireless expert" and the phone conversation went like this, "It's me. I am doing another wireless project for another agency. But I would like to know how do you convert an autonomous AP to controller-based IOS". <FACEPALM>
Long story short: They won't know. Not all of them know. Their main concern is YOUR MONEY in their hands. That's all. But I can tell you this: I am the end user. I configure stuff. Roaming works if you get the basics correct. Roaming works if you know what you want and you get it done right. Scott Fella and Steve Rodriguez, two regular in this forum, (and works for CDW) and they are good. There's another "mad Texan" by the name of George Stefanick is another one. An Aussie by the name of Rasika is also around.
The most basic item is roaming is how you space your APs. Unless you've got wireless antennas coming out of your ears, you need to organize a wireless site survey. And when you want to do the a "good" wireless site survey, you "future proof" your requirements. Right now, my wireless site survey is aimed at "wireless VoIP" requirement.

Mobility group -without layer 3 roaming

Hi all,
With a N+1 WLC deployment, is it possible to disable layer 3 roaming while enabling Mobility group feature on the backup controller ?
based on the network setup layer 3 mobility is not required.However, we need to both controllers to exchange all security related parameters so that excluded clients info etc will be in sync during a failover scenario.
I do not intend to use ACLs as such.
Any thoughts much appreciated.
cheers,
Janesh

Hi Nicolas,
Many thanks for the reply.
Let me throw some light on the matter
-Why exactly do you want to block layer 3 roaming ?
Buildings are miles apart so roaming will only happen within a building and it will be intra controller.
Also I have seen on cisco doco that Layer 3 roaming is not preferred.
How does it impact you as anyway it's transparent for the network ?
As I mentioned layer 3 roaming is not required so I don't see a point enabling it.Why tax the controller unnecessarily?
One controller serves all the APs at one data centre and the other is the backup.No salt and pepper scenario.
-Does that mean that you're ok with layer 2 roaming ? If yes, just configure all WLCs to serve the same subnets for the clients
Layer2 roaming will happen within the controller as primary and backup controllers are Layer -3 separated.
There is no layer 2 adjacency between the controllers.
over to you
cheers,
Janesh

WLC 7.4.100.60 and roaming problems on 8500

Hello,
After installing an 8500 controller on 7.4.100.60 and migrating 1000 APs do this controller, we have the following problems:
[1] clients get disconnected and loose sessions (note: client is mobile gun and is heavily mobile). I have the impression there are more coverage holes. This might be due to bug CSCue13108, but says fixed in 7.4.100.60, we wil be upgrading to 7.4.110.0 anyway shortly.
[2] we have lots of L3 roaming problems between clients, especially when clients roam between old WISM controller and new 8500 controller. They don't roam, they get disconnected and reconnected, resulting in ip address change, resulting in sessions loss. Old controller still runs 7.0.230.0 but compatibility matrix says these two versions are L3 roaming compatible.
However, the release notes of 8500 mention this: "Cisco 8500 Series Controller cannot be configured as a guest anchor controller. However, it can be configured as a foreign controller to tunnel guest traffic to a guest anchor controller in a DMZ"
Because Layer 3 roaming is similar to guest traffic tunneling, does this mean that the 8500 can be the initiator of a L3 roam tunnel, but cannot be the endpoint of a L3 roam tunnel ?
We have done a test that seems to confirm this: client starts on 8500 in state "local", goes to AP on old controller (7.0.230.0), but roam doesn't work. Client gets re-associated with ip address change. Then when moving back to the 8500 controller, the client does roam successfully, keeps its ip address in the 7.0.230.0 vlan and gets status "foreign" on 8500 controller. controllers are in same mobility group and mobility connections are all up.
In the 7.5 release notes, this limitation is not mentioned anymore. Does it mean it is solved and 8500 can be used as guest anchor controller in 7.5 ??
regards,
Geert

[2] we have lots of L3 roaming problems between clients, especially when clients roam between old WISM controller and new 8500 controller. They don't roam, they get disconnected and reconnected, resulting in ip address change, resulting in sessions loss. Old controller still runs 7.0.230.0 but compatibility matrix says these two versions are L3 roaming compatible.
Roaming from one AP to another that shares the same controller is totally different with inter-controller roaming, which you have now. I believe WiSM-1 has 180 ms compared to the 90 ms on a 5508. And this time difference means alot.
So when your client goes from one controller to another, they actually have to do a full re-authentication to the new controller.
I presume both the old and new controller are in the same Mobility Group?
However, the release notes of 8500 mention this: "Cisco 8500 Series Controller cannot be configured as a guest anchor controller. However, it can be configured as a foreign controller to tunnel guest traffic to a guest anchor controller in a DMZ"
Pffft! That'll be the most expensive Guest Anchor Controller if I follow this solution.

Client handoff and Roaming

Hi all,
I've installed four WLC 5.1.151.0 and the clients have roaming issues. When a client roams i can see it as "Mobility Role: Anchor" on the first WLC it connected and as "Mobility Role: Foreign" on the WLC it roamed to. The problem is after the roaming the client can't reach the network, no ping, no communication. I can ping the client from the controller it roamed to, but not from the first controller it connected (the anchor). Mobility groups are configured correctly, "Symmetric mobility tunneling mode" and "AP Groups VLAN Feature Enable" are disabled. I've configured all the controllers as DHCP with different scopes on the same subnet, so its a inter-controller roaming, not inter-subnet. I can't upgrade the controller software soon because its a production environment. To fix the problem I remove the client from the first controller, refresh its Wifi interface so it connects directly to the second controller and the network works again. Any help is welcome. Thank you.
Gian Paolo

Maybe I've fixed. All the WLCs wireless interfaces associated to the SSID have address in 10.110.0.0/16 subnet but from the first controller I can't ping anything above 10.110.0.0/24 network. I've changed the netmask of all WLCs some days ago but looks like WLC_01 didn't accepted the new netmask (I've used the web interface). It's odd, maybe a problem of browser caching or something, reviewing the saved configuration of yesterday the netmask is definitely wrong. I've changed the netmask from command line and now roaming works, I can ping any client in 10.110.0.0/16 subnet.
What confused me was checking eping and mping that worked all the time because WLCs have addresses 10.110.0.x.
Thank you all for the support.

Config DHCP service on AIRONET 1040 autonomous

Hello,
I tried to configure DHCP service that will supply addresses for the wifi users.
I configured:
ip dhcp pool sefi
network 192.168.42.0 255.255.255.0
dns-server 8.8.8.8
default-router 192.168.42.1
How can I connect this DHCP service to the Dot11Radio0 interface or to the dot11 SSID??
Thanks

Configuring DHCP
WLANs can be configured to use the same or different Dynamic Host Configuration Protocol (DHCP) servers or no DHCP server. Two types of DHCP servers are available: internal and external.
Internal DHCP Server
The controllers contain an internal DHCP server. This server is typically used in branch offices that do not already have a DHCP server. The wireless network generally contains 10 access points or fewer, with the access points on the same IP subnet as the controller. The internal server provides DHCP addresses to wireless clients, direct-connect access points, appliance-mode access points on the management interface, and DHCP requests that are relayed from access points. Only lightweight access points are supported. When you want to use the internal DHCP server, you must set the management interface IP address of the controller as the DHCP server IP address.
DHCP option 43 is not supported on the internal server. Therefore, the access point must use an alternative method to locate the management interface IP address of the controller, such as local subnet broadcast, DNS, priming, or over-the-air discovery.
Note See the Chapter 8 "Controlling Lightweight Access Points," or the Controller Deployment Guide at this URL for more information on how access points find controllers:
http://www.cisco.com/en/US/products/ps6366/prod_technical_reference_list.html
Note A internal DHCP server pool will only serve the wireless clients of that controller, not clients of other controllers. Also, internal DHCP server can only serve wireless clients and not wired clients.
Note DHCP required state can cause traffic to not be forwarded properly if a client is deauthenticated or removed. To overcome this, ensure that DHCP required state is always in disabled state.
External DHCP Servers
The operating system is designed to appear as a DHCP Relay to the network and as a DHCP server to clients with industry-standard external DHCP servers that support DHCP Relay, which means that each controller appears as a DHCP Relay agent to the DHCP server and as a DHCP server at the virtual IP address to wireless clients.
Because the controller captures the client IP address obtained from a DHCP server, it maintains the same IP address for that client during intra-controller, inter-controller, and inter-subnet client roaming.
DHCP Assignment
You can configure DHCP on a per-interface or per-WLAN basis. The preferred method is to use the primary DHCP server address assigned to a particular interface.
Per-Interface Assignment
You can assign DHCP servers for individual interfaces. The management interface, AP-manager interface, and dynamic interfaces can be configured for a primary and secondary DHCP server, and the service-port interface can be configured to enable or disable DHCP servers.
Note See the Chapter 10 "Managing Controller Software and Configurations," for information on configuring the controller's interfaces.
Per-WLAN Assignment
You can also define a DHCP server on a WLAN. This server will override the DHCP server address on the interface assigned to the WLAN.
Security Considerations
For enhanced security, we recommend that you require all clients to obtain their IP addresses from a DHCP server. To enforce this requirement, all WLANs can be configured with a DHCP Addr. Assignment Required setting, which disallows client static IP addresses. If DHCP Addr. Assignment Required is selected, clients must obtain an IP address via DHCP. Any client with a static IP address is not be allowed on the network. The controller monitors DHCP traffic because it acts as a DHCP proxy for the clients.
Note WLANs that support management over wireless must allow management (device-servicing) clients to obtain an IP address from a DHCP server. See the "Using Management over Wireless" section for instructions on configuring management over wireless.
If slightly less security is tolerable, you can create WLANs with DHCP Addr. Assignment Required disabled. Clients then have the option of using a static IP address or obtaining an IP address from a designated DHCP server.
Note DHCP Addr. Assignment Required is not supported for wired guest LANs.
You are also allowed to create separate WLANs with DHCP Addr. Assignment Required disabled; then define the primary / secondary DHCP server as 0.0.0.0 on the interface assigned to the WLAN. These WLANs drop all DHCP requests and force clients to use a static IP address. Note that these WLANs do not support management over wireless connections.
Note See Chapter 4 "Configuring Controller Settings," for instructions on globally configuring DHCP proxy.
Note If you want to specify a static IP address for an access point rather than having one assigned automatically by a DHCP server, see the "Configuring a Static IP Address on a Lightweight Access Point" section for more information.
This section provides both GUI and CLI instructions for configuring DHCP.
Using the GUI to Configure DHCP
To configure DHCP using the GUI, follow these steps:
Step 1 Follow the instructions in the "Using the GUI to Configure the Management, AP-Manager, Virtual, and Service-Port Interfaces" section or "Using the GUI to Configure Dynamic Interfaces" section to configure a primary DHCP server for a management, AP-manager, or dynamic interface that will be assigned to the WLAN.
Note When you want to use the internal DHCP server, you must set the management interface IP address of the controller as the DHCP server IP address.
Step 2 Choose WLANs to open the WLANs page.
Step 3 Click the ID number of the WLAN for which you wish to assign an interface. The WLANs > Edit (General) page appears.
Step 4 On the General tab, unselect the Status check box and click Apply to disable the WLAN.
Step 5 Re-click the ID number of the WLAN.
Step 6 On the General tab, choose the interface for which you configured a primary DHCP server to be used with this WLAN from the Interface drop-down list.
Step 7 Choose the Advanced tab to open the WLANs > Edit (Advanced) page.
Step 8 If you want to define a DHCP server on the WLAN that will override the DHCP server address on the interface assigned to the WLAN, select the DHCP Server Override check box and enter the IP address of the desired DHCP server in the DHCP Server IP Addr text box. The default value for the check box is disabled.
Note The preferred method for configuring DHCP is to use the primary DHCP address assigned to a particular interface instead of the DHCP server override.
Note DHCP Server override is applicable only for the default group.
Step 9 If you want to require all clients to obtain their IP addresses from a DHCP server, select the DHCP Addr. Assignment Required check box. When this feature is enabled, any client with a static IP address is not allowed on the network. The default value is disabled.
Note DHCP Addr. Assignment Required is not supported for wired guest LANs.
Step 10 Click Apply to commit your changes.
Step 11 On the General tab, select the Status check box and click Apply to reenable the WLAN.
Step 12 Click Save Configuration to save your changes.
Using the CLI to Configure DHCP
To configure DHCP using the CLI, follow these steps:
Step 1 Follow the instructions in the "Using the GUI to Configure the Management, AP-Manager, Virtual, and Service-Port Interfaces" section or "Using the GUI to Configure Dynamic Interfaces" section to configure a primary DHCP server for a management, AP-manager, or dynamic interface that will be assigned to the WLAN.
Step 2 Disable the WLAN by entering this command:
config wlan disable wlan_id
Step 3 Specify the interface for which you configured a primary DHCP server to be used with this WLAN by entering this command:
config wlan interface wlan_id interface_name
Step 4 If you want to define a DHCP server on the WLAN that will override the DHCP server address on the interface assigned to the WLAN, enter this command:
config wlan dhcp_server wlan_id dhcp_server_ip_address
Note The preferred method for configuring DHCP is to use the primary DHCP address assigned to a particular interface instead of the DHCP server override. If you enable the override, you can use the show wlan command to verify that the DHCP server has been assigned to the WLAN.
Step 5 Reenable the WLAN by entering this command:
config wlan enable wlan_id

L3 intra-controller roam

Similar Messages

Maybe you are looking for