Wireless Access

Hello all;

 

I am in the process of replacing a pair of 7240 6.x controllers in master/standby configuration with a pair of 7240XM running 8.6.x in a cluster. This is in a university environment.

 

What I would like to do is split my physical network so that the residence network is connected to one controller interface, and the campus network to another.  If this was a single controller environment, I believe I could point the APs to the loopback (with appropriate routing of course) to accomplish this, but you can't assign a VRRP to loopbacks.

 

Has anyone successfully implemented a cluster with loopbacks in this manner?

 

Andrew

Two Different interfaces on the same controller?

What are you trying to do?

Student residence APs (~750) all come to their own core switch. That core switch is connected directly to the existing controllers.

 

Campus network APs (~800) come through normal LAN to the campus core, then to the resnet core, then to the controller.

 

A separate interface on each controller goes to the firewall, and the resnet and campus VLANs are in separate security zones.

 

What I want to do is get rid of the resnet <=> campus network connection. These are otherwise completely independent networks.

 

I can easily route traffic to and from the loopback addresses on both sides correctly.  My thought is to use the loopback as the controller IP, and also the aruba-master and LMS IP.

 

Just had a thought typing this.  Since I can't do VRRP with loopbacks, could I just return both loopbacks in the aruba-master DNS entry?

 

I tried this with 6.x code using a different VLAN IP for each side, but it didn't work since all tunnels are built against the controller IP. That's how I wound up with the connection between the two networks.

 

I can post a network diagram if that would help.

Just thinking out loud, but what if you put the same loopback IP on both systems and set your route for the loopback through the VRRP?

 

Not sure if it works or is recommended.

No, that wouldn't work.  The controllers will both be active at the same time.

If you post a diagram, that might help.

OK, this is what I want to build. The drawing got a little busy, but hopefully I captured enough.

This is to only support wireless user traffic, right?  This is not to support any wired traffic, correct?

Mostly correct. All campus wired traffic goes to the firewall directly. There are a handful of wired gaming consoles on resnet that get tunneled into the controllers (through pre-HP Aruba switches) as well.

Okay.

 

I don't see anything special with your configuration.  The general rule is to put your controllers near or close to your core or distribution routers so that (1) Any access points can reach them and (2) You can easily trunk user traffic to them.  

 

User traffic goes from access points to the controller.  The controller then puts them onto your LAN via its connection to some router.  Ultimately, ip addressing doesn't matter; an ip address is just a way for your infrastructure to send traffic to/from an wired or wireless endpoint.

 

With that being said, your access points just need to be able to connect to a controller.

 

With regards to your routes, just make your layer 3 switches the default gateway for your user VLANs, so that you don't have to do any static routing to controllers.  Your layer 3 switches, or routers would just propagate reachability to the user vlan as "directly connected routes", so that you don't have to have statics everywhere.

 

I hope any of that makes sense.

OK.  I can use the loopback IP as the controller IP, I can route traffic to and from that IP via separate physical interfaces for the two networks, and the APs can use that as their LMS. So far so good.

 

The purpose of the static routing is just to advertise the loopback addresses without running OSPF on the controllers themselves. Within each network the route would be propagated normally as you suggest.

 

The more interesting part will be the clustering configuration. It's scenario 2 in the user guide, so should be fairly straight forward.  We'll see.

Why do you need a loopback ip address again?  

 

Let's do this: How many access points and how many controllers do you have?

 

2 controllers, approximately 700 APs on each network (1400 total).

 

The 8.6 user guide (pg 51) says the loopback must be configured in a "multiple subnets [...] scenario". It goes on to say that if you don't then the first configured VLAN IP will be used instead. I assume that the logic here is that by configuring a loopback IP explicitly you get to override that automatic selection.

 

As I understand it, an AP always builds its tunnel to the controller IP address, not to a VLAN IP.  So if the controller IP is an interface VLAN IP, then all APs, from both networks, have to have a path to that interface.

 

With correctly configured routing, there's no reason that path couldn't be from a different interface on the same controller, which solves the problem of eliminating the external connection between the campus and residence networks.

I think you mentioned this, but just to make sure

You are able to use a VLAN-IP as the controller-IP (controller-ip vlan xyz)

From what I understand (and if I'm wrong someone please correct me) but I don't think you'll be able to manually specify the LMS while running a cluster. I believe the master in the cluster is going to override it and spread the APs between members in the cluster based on load-balancing. (I think this thread explains it better) 

If you have 2 separate controllers, and use LMS and backup LMS, I think what you are trying to do should work, as long as you setup the controller-ip as needed

---

@Andrew Bell wrote:

2 controllers, approximately 700 APs on each network (1400 total).

 

The 8.6 user guide (pg 51) says the loopback must be configured in a "multiple subnets [...] scenario". It goes on to say that if you don't then the first configured VLAN IP will be used instead. I assume that the logic here is that by configuring a loopback IP explicitly you get to override that automatic selection.

 

As I understand it, an AP always builds its tunnel to the controller IP address, not to a VLAN IP.  So if the controller IP is an interface VLAN IP, then all APs, from both networks, have to have a path to that interface.

 

With correctly configured routing, there's no reason that path couldn't be from a different interface on the same controller, which solves the problem of eliminating the external connection between the campus and residence networks.

---

 

"You must configure a loopback address if you are not using a VLAN ID address to connect the managed device
to the network" - That is an overstatement.  A controller's management ip address is on a VLAN and that VLAN has an ip address.  You don't "need" a loopback.  In your situation, it would be complicating a rather simple network.  If your controller's management ip address is on VLAN 100, you would simply do:

 

config t

interface vlan 100

ip address 192.168.1.20 255.255.255.0

controller-ip vlan 100

 

And you would be done.  No loopback needed.  A controller, even in the most complicated networks, only requires a single ip address on a VLAN.  The client VLANs do not require an ip address if the client's default gateway is the layer 3 switch (router) instead of the controller.

 

A controller needs an ip address for (1) Management and (2) for access points to send their traffic to.  The only other circumstance where a controller would need an ip address is if you have a captive portal network, and you don't want to host that captive portal on the management ip address of the controller.  Please don't get hung up on the loopback interface.  It is not necessary....

Thanks.  Now perhaps we should lock the technical writers in a room with the engineers for a few months...

..and we should add the customers that ACTUALLY read the user guide(s).

To be fair, I do have a lot of time on my hands in quarantine.