cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2020
Views
0
Helpful
5
Replies

Guest N+1 redundancy & load balancing in seperate data centers

481567
Level 1
Level 1

I need assistance in aquiring documentation to setup N+1 redundancy & load balancing between two seperate guest anchor controllers installed in seperate data centers. Can you explaing how it should be setup or point me in the right direction for documentation? If you can't point me in the right direction to aquire documentation; can you answer the following questions?

1) How do I setup my mobility groups on my guest anchor controllers installed in the DMZ? Should both guest anchor's be in the same mobility group.

2) Do both guest anchors share the same virtual IP or do they need to be seperate (DMZ01 - 1.1.1.1 / DMZ02 - 2.2.2.2)? I think seperate!

3) Are there any configuration parameters on the guest anchors for load balancing?

4) Do either on of the guest anchors need to be setup as a master controller? I'm not sure?

5) Are there any configuration parameters on the foreign controllers for load balancing?

6) How do I setup my foreign controllers? Should both guest controllers be added to the mobility group on the foreigh controller? I would think both of them would be added to the foreign controller mobility group.

7) Should both guest anchors be added as an anchor on the WLAN? I would think both controllers would need to be added as anchors under the WLAN!

Am I missing anything here? This is how I think it should logically work?

Thanks,

Gordon

1 Accepted Solution

Accepted Solutions

weterry
Level 4
Level 4

Here is my $.02 on how it works

1) Typically, the Anchor WLC is in a different Mobility Group than the Foreign. I'd think that having both Anchors in the same mobility group (different than foreign) might be preferred. (I'd go with Example #1)

2) 1.1.1.1 should be sufficient across all controllers. If your DNS server limits what IP addresses you can actually define, then you'll have a problem. But generally speaking, the virtual interface should be something that does not exist in your network, and using the same IP/Name/Cert on multiple controllers should work fine.

3) No...?

4) No...

5) No.... I believe load-balancing is round-robin, but I could be wrong.

6) Just make sure all controllers in defined in the mobility domain (different groups, but in the mobility management list on each WLC)

7) Yes... See #5

8) No...

9) No...

The above answers may not be factual. They are how I would set this up, and I'm fairly certain it would work.

The key point is that each controller needs to be mobility aware of the others.

Your foreign WLC should list both anchors as an auto-anchor (I think it round-robins the associations)

Each Anchor WLC should only list itself as the anchor (I assume).

I'd suggest opening a TAC case. However, you may want to get it all set up first. If it is configured but isn't working when you open the case, it is easier to troubleshoot what is broken. If you open a case now, you'll just have to configure it and see if it works before anyone can see what is wrong.

View solution in original post

5 Replies 5

481567
Level 1
Level 1

An update to question #7. Should both guest controllers be added as an Anchor of the WLAN on the foreign controllers in question.

George Stefanick
VIP Alumni
VIP Alumni

I dont think you can load balance your wireless traffic with 2 anchor controllers. They will share the same mobility group. You can do N+1 failover. Interesting question. You take your guest traffic seriously.

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

I have to take it seriously. Why? We offer it as a service to very large customers that lease sections of our mainenance facility to perform their needed tasks. It would be nice if I could load balance. This would give me an end around with the network group. They want to rate limit the guest traffic in each data center. I could double my pipe to the internet if I could load balance. The wireless guy would have the last laugh. I've run into some Cisco documentation that mentions load balancing, but again its very vague. I have searched and search for documentation outlining N+1 guest redundancy, but most of the documentation I've found is very vague. Its getting frustrating and I have to schedule a change request next week to implement N+1. I really don't want to spend most of the night doing the trial and error thing. It sure would be nice if I could find a docment that outlines the N+1 setup on my two DMZ anchors and foreign controllers.

I bet TAC has a document!

Gordon Shelhon

481567
Level 1
Level 1

I need to elaborate on my questions:

1) Do both of my guest DMZ anchors need to be in a seperate mobility group on their own or can the guest anchors be in completely seperate mobility groups? All 100 + foreign controllers are in seperate mobility groups.

I) Example #1: Guest anchor number 1 (Mobility group: DMZ) / Guest anchor number 2 (Mobility group: DMZ)

II) Example #2: Guest anchor number 1 (Mobility group: DMZ01) / Guest anchor number 2 (Mobility group: DMZ02)

2) Do both guest anchor controllers have to be configured with seperate virtual IP's or do they share the same address?

I) Follow up to this question: I want to register the DMZ controllers with our DNS servers so that my clients receive a name when authenticating through my customized webauth. I am currently using 1.1.1.1 as the virtual address and I'm pretty sure this is the address I need to register with my external DNS server. My question is this. Does the address I use for the virtual interface matter? 1.1.1.1 is not a valid address with my network. Do I need to assign a valid address registered with my network if I'm going to add this address to my external DNS servers?

3) No change to my original question.

4) No change to my original question.

5) No change to my original question. I have run into Cisco documentation that mentions guest anchor load balancing, but the documentation is very vague. I'd love to be able to load balance as the network group wants to limit my guest traffic to the internet. I could double my pipe if I could load balance the guest anchors.

6) No change to my original question, but the answer to question one is key to the setup of my foreign controllers.

7) Elaboration: Should both guest controllers be added as an anchor under the WLAN on the foreign controllers? I would think both of them would be added.

8) No change:

9) Should my secondary guest controller be added as an anchor on the WLAN of the primary guest DMZ controller and visa versa?

Can my Cisco expert answer this or do I need to open a TAC case?

Thanks,

Gordon Shelhon

SR. Wireless Services Engineer

Company: Not specified

weterry
Level 4
Level 4

Here is my $.02 on how it works

1) Typically, the Anchor WLC is in a different Mobility Group than the Foreign. I'd think that having both Anchors in the same mobility group (different than foreign) might be preferred. (I'd go with Example #1)

2) 1.1.1.1 should be sufficient across all controllers. If your DNS server limits what IP addresses you can actually define, then you'll have a problem. But generally speaking, the virtual interface should be something that does not exist in your network, and using the same IP/Name/Cert on multiple controllers should work fine.

3) No...?

4) No...

5) No.... I believe load-balancing is round-robin, but I could be wrong.

6) Just make sure all controllers in defined in the mobility domain (different groups, but in the mobility management list on each WLC)

7) Yes... See #5

8) No...

9) No...

The above answers may not be factual. They are how I would set this up, and I'm fairly certain it would work.

The key point is that each controller needs to be mobility aware of the others.

Your foreign WLC should list both anchors as an auto-anchor (I think it round-robins the associations)

Each Anchor WLC should only list itself as the anchor (I assume).

I'd suggest opening a TAC case. However, you may want to get it all set up first. If it is configured but isn't working when you open the case, it is easier to troubleshoot what is broken. If you open a case now, you'll just have to configure it and see if it works before anyone can see what is wrong.

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: