Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

Query on WLAN interfaces with Failover

The queries I are based on the  network setup represnted in the attached drawing.

As there will be no layer 2 links between the router1 and router2 we cannot implement HSRP for the WLAN interfaces.

Option 1

Configure WLAN interfaces 5.5.5.2 and 5.5.5.3 on each WLCwith G.W -5.5.5.1 (IP on L3 switch atremote site) and VLANID 4 (as capwap traffic will come up on this vlan) .Thenconfigure both WLCs under the sameMobility group so failover will work. This method enables us to have separatesubnets for each site at a cost of configuring interfaces for each site. I’mnot 100% whether configuring VLAN ID 4 under WLAN interfaces is the recommendedapproach.

Option 2

This is easiest to implement. We configure something like a /20 for WLAN client IPs for all sites and configure L3 interfaces and advertise them under IGP on routers-with a sightly higher metric on router2 .(will provide failover if router1 is out of action). Then configure them on thesame Mobility group so WLC failover will also work though EoIP. The disadvantage of having a huge subnet for WLAN clients can make it vulnerable forany attacks that could be initiated within the WLAN.

Is there a better approach to achieve this goal?Any feedback is much appreciated.

cheers,

Janesh

1 ACCEPTED SOLUTION

Accepted Solutions

Re: Query on WLAN interfaces with Failover

If the buildings are far apart, mobility groups are a non factor even for roaming. I've never attempted what you are proposing. I would lab this if you can to make sure nothing bits you in the rear during deployment. I always say, "There is something to be said about layer 2 and 3 layer boundaries". Something tells me this will be an issue as there will be concerns with broadcast that will be dropped by the router.

If these are 2 different buildings i would roll with the simple plan. Keep the controllers separate like you have them. Point the APs to the (other) controller as secondary backup should the primary controller fails.

Yes the clients would need to re-IP. And yes the clients may see a blip for 10 - 30 seconds as the AP joins the new controller and the clients have to get a new IP. Also if you lose the cloud gateway you lose both controllers in your orginal design. If you keep the gateways local they will still service inside clients on the network (traffic not going across the cloud).

__________________________________________________________________________________________ "Satisfaction does not come from knowing the solution, it comes from knowing why." - Rosalind Franklin ___________________________________________________________
4 REPLIES

Re: Query on WLAN interfaces with Failover

Hi Janesh,

It has been a long day for me .. My daughter just gave birth to my first grand child. So let me take a stab at this for you ...

First i think there is confusion with FAILOVER and MOBILITY, but lets dive in ...

1) Can a user in (data center 1) walk to (data center 2) or are these physically far enough apart that wireless does not exist for roaming between the buildings?

2) Mobility has little to do with failover and everything to do with mobility roaming between controllers. Whereby a client can roam from controller 1 to controller 2 without the need for a new IP when different subnets are used as in your case. This is called intra subnet mobility roaming. When a client roams from controller 1 to controller 2 a mobility message is sent from WLC1 to WLC2. The message is the goods about the client. This is the main purpose of mobility groups.

3) If you want to provide proper fallover we need to consider a few factors:

     A. Ive always kept my managment interfaces on the same layer 2 adjacency. However i dont think that you need to keep the managment IPs in the           same layer 2. So long as the controller can route and still see each other nothing comes to mind why layer 2 would be factor for the      management interfaces. (((Now watch, im going to hit send, lay down to bed and a bolt of lightening will hit me and say "dam i forgot about X"))

     B. (More Importantly) Your client vlans need to be on a layer 2 adjacency and here is why!

            When WLC#1 dies the APs move to WLC#2. These APs will now tunnel traffic to WLC#2. WLC#2 has a different subnet. So now  your                            clients will need to re-IP. Something i dont think you want to do ...

Normally, the pratice is to provide layer 2 between the management and the client subnets. This provides the normal failover we would expect. Im not sure what your layer 3 cloud is made up of, however you can add your GW there as you mentioned for the management and clients subnets and call it a day. Just keep in mind, your cloud will be the in-between location for ALL wireless traffic.

Im not some much a R/S guy, but MPLS could be a play here.

I hope this helps a little and not add more confusion.

Ok im hitting send ... lets see if i edit this  ..

__________________________________________________________________________________________ "Satisfaction does not come from knowing the solution, it comes from knowing why." - Rosalind Franklin ___________________________________________________________
New Member

Re: Query on WLAN interfaces with Failover

Hi George,

Congrats for getting the grandpa status .Hope the baby and the mother are in good health.

Thanks heaps for your reply midst of all the family commitments .

Here we go with the responses:

1) No roaming is required between each building.They are far apart.

2) Thanks for clearing that out.I was under the impression having mobility enabled will provide controller failover which is not the case.

3)

A) At this stage , as you pointed out  layer 2 should not be a factor in regards to AP management VLANs

B) I totally agree with you on having layer 2 adjacency for client vlans and the previous firm I worked for had L2 links and HSRP for gateways and it worked fine.This is what the normal people would do

Cloud is running OSPF for MAN links (between data centres) and BGP on the WAN links.

If I go with option 2 , clients will not need to re-IP as both routers will have same IP subnet but will be advertised with different OSPF metrics (Router2w with a higher metric) so there won't be any complications with routing.So when WLC1 goes down, WLC2 route will become active and there will be connectivity for the  clients as it will be same subnet.

Thanks again  for taking time to reply.I really appreciate it.

cheers,

Janesh

Re: Query on WLAN interfaces with Failover

If the buildings are far apart, mobility groups are a non factor even for roaming. I've never attempted what you are proposing. I would lab this if you can to make sure nothing bits you in the rear during deployment. I always say, "There is something to be said about layer 2 and 3 layer boundaries". Something tells me this will be an issue as there will be concerns with broadcast that will be dropped by the router.

If these are 2 different buildings i would roll with the simple plan. Keep the controllers separate like you have them. Point the APs to the (other) controller as secondary backup should the primary controller fails.

Yes the clients would need to re-IP. And yes the clients may see a blip for 10 - 30 seconds as the AP joins the new controller and the clients have to get a new IP. Also if you lose the cloud gateway you lose both controllers in your orginal design. If you keep the gateways local they will still service inside clients on the network (traffic not going across the cloud).

__________________________________________________________________________________________ "Satisfaction does not come from knowing the solution, it comes from knowing why." - Rosalind Franklin ___________________________________________________________
New Member

Re: Query on WLAN interfaces with Failover

Hi Geroge,

Thanks heaps for the advice and poitning out potentail pitfalls that I might run into.

The attached drawing is almost identical to the test lab setup  where the 6500s will be replaced with 3560s.

I will test this and shall let you know how it goes.

cheers,

janesh

262
Views
0
Helpful
4
Replies