Wireless Deployment

Unanswered Question
Jan 9th, 2008

Hello everyone,

I need some help here. I am currently working on a project with Centralized WLC deployement at a Co-Location Centre.

My WiSMs are located in my co-location switches. The Co-location network is different from the corporate network (MAN/WAN) and traffic between the two is routed (Layer 3)via MPLS connections.

The Access Points will be deployed in the corporate network. With DHCP option 43 and Layer 3 LWAPP, I don't think communication between the WiSMs and APs will be a problem. However, I am a little concerned about the user VLAN. How will I perform the dynamic interface/VLAN mapping configuration on the WiSMs since it is not on the same Layer 2 infrastructure as the APs? The WiSMs and APs do not share any VLAN information.

Thanks in anticpation,

Ade

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
SHANNON WYATT Wed, 01/09/2008 - 15:13

You are correct that the VLANs for clients are not going to be local to the clients. You can still make this work by using AP Groups and assigning access points in certain locations to certain AP groups. Another option if HREAP.

aadeoye Wed, 01/09/2008 - 17:19

Thanks a lot.

I have heard of those mechanisms but I am not too sure how they will work.

Can you just briefly explain this solution?

Best regards,

Ade

SHANNON WYATT Wed, 01/09/2008 - 17:27

AP Group VLANs are a way of defining VLANS that are used by specific access point. I recently used this with a customer where we put all of the access points connected to a specific IDF to it's own VLAN. This way we had for networks in the particular building versus one. Of course the VLANs existing in the core, so all trafic comes back out of the core and on to the network.

Hybrid REAP (Remote Edge Access Point) is a way that you can have a few access points at a remote location that bridge some of the traffic locally. This is intended as a remote location solution to eliminate the need for a controller in a small remote office.

aadeoye Wed, 01/09/2008 - 18:40

Thanks so much. I think Hybrid REAP may be the option for me. Our centralized deployment is pretty much WAN based. The controllers, WCS, ACS etc are at the co-location datacenter (a separate network) while all the APs are at the separate offices each with their own networks.

Will I need multiple subnets (i.e. WLANs/SSIDs) or can I still have the same WLAN span the APs? Since the APs are remote, does it matter what interface (AP Manager or Management) is used for the controller IP address?

SHANNON WYATT Thu, 01/10/2008 - 05:33

You can have the same SSID across all of the access points. You can also do AP Groups so that the access points in one location would have a subnet for the clients that is different then another. You are limited on the number of HREAP clients per remote. I want to say that it is three APs. It has been a while since I had an HREAP setup, so I don't remember off the top of my head.

Is the data that the users are accessing in the co-lo? If that is the case you could just leave them as is (no HREAP).

The address that is advertised to the access point is the management IP address, but they need to be able to talk to both management and AP Manager, so watch your ACLs. My understanding is that the access point communitcates to the Management inface to detirmine the AP Manager IP address.

aadeoye Thu, 01/10/2008 - 06:09

Thanks so much for your help on this. I truly appreciate it.

I do believe the bulk of the network resources are located in the co-lo and the corporate locations contain the user subnets and a few network resources. I will confirm in a separate post. As I understand it, H-REAP appears to be some sort of business continuity feature available in the Cisco Wireless infrastructure (more like SRST for IP Telephony).

The reason I asked about the Management IP is that the documentation appears rather conflicting and I wanted to ensure I was using the right IP address in DHCP option 43 (Management or AP Manager) as I was having some issues with the APs registering. The LWAPP JOIN process does not work.

SHANNON WYATT Thu, 01/10/2008 - 06:14

Well, HReap is more useful when you have resources that are local to that subnet, or potentially a guest SSID that would go out an internet connection that is local to the facility. You are limited to the authentication methods as EAP would have to go through the controller.

You definately need the DHCP option. DNS works well too. You can hard code the access point's with the IP, but that is a pain.

aadeoye Thu, 01/10/2008 - 06:31

I will get the DHCP option working. I guess that HREAP may not be the way to go then.

In that case, here's my question:

Based on the way I understand it, the WiSM will map the SSID/WLAN to a VLAN. I guess this assumes that the WiSM is within the same Layer 2 domain as the users. In my deployment, this is not the case.

How will this mapping work? Is there a means to use a dummy VLAN at the co-lo?

SHANNON WYATT Thu, 01/10/2008 - 06:51

SSIDs map to interfaces, either physical (management interface) or virtual (just a VLAN).

The client VLANs need to be local to the WiSM. They would have to be real VLANs, with routing, ACLs, etc. The client traffic is encapsulated at the Access Point and dumped out of the interfaces on the WiSM. So if the client is directly printing to a printer plugged into the same switch as the access point the traffic will go to the WiSM and then back to the printer. If most of the resources are local to the WiSM (at or near the core or distribution) this is not an issue. But if the majority of the stuff is at the edge (File/Print/Internet) this can create a lot of traffic. If the resources are at the edge (close to the client) you should look at 2106's or the Network module options and then manage them with a central WCS.

If this traffic is mostly destined to the core you can further break out the clients based on additional VLANs by using AP groups. With AP Groups you create additional VLANs and then you associate the access points with the AP groups for a particular VLAN. This way you can create a client VLAN that is specific to an office or area, versus having everyone lumped into one VLAN. Be default the access point would just use the default settings for the SSID, but you can apply AP groups as necessary for issolation. This is also usefull if you have additional tools to track things on the network. You would be easily able to tell the remote location with the issue based on the subnet, versus having to track down the individual clients.

If you would like you can e-mail me directly on this. My e-mail is my login.

aadeoye Thu, 01/10/2008 - 07:18

My client wants everything to be centrally managed - no controllers at the corporate sites. Like you suggested, a typical deployment like this should use multiple controllers at the remote sites but they want to leverage their co-lo investment and IT resources by centralizing everything.

From the Cisco documentation, we could use an unlimited number of HREAP-enabled APs. Unfortunately, I am not experienced with this type of deployment so I am not sure how the WLAN to VLAN mapping will work.

I do not mind the APs locally switching traffic in a local VLAN while getting information via LWAPP from the controllers. Is this possible ?

I found this note somewhere:

""HREAP supports visibility into VLAN tagging, providing enterprises with the flexibility to determine which SSIDs will have data bridged locally and which will have data tunneled

back to a controller."

Thanks and best regards,

Ade

SHANNON WYATT Thu, 01/10/2008 - 07:24

HREAP is limited in the authentication methods. Unless they have changed it, the only authentication option on an HREAP SSID is WPA-PSK and WEP (or open). Again, I could be wrong on that one, you should probably look at the docs to check that. You are also limited to something like 3 access points per location.

If the resources are centrally located than this is not an issue. You mentioned the customer would like central management. Placing a controller at the edge would still allow central management. Again, if the servers and what not are at the co-lo then this wouldn't be an issue. The exception would be for stuff like printing.

aadeoye Thu, 01/10/2008 - 07:28

I understand what you mean but they do not want to invest in controllers at the remote sites.

I will check the docs again to see if I am missing something.

Scott Fella Mon, 02/25/2008 - 14:33

I have implemented 4.2.61 and H-REAP with authentication centrally switched (802.1x) and users locally switched. Works well.

aadeoye Mon, 02/25/2008 - 14:38

So, if I understand correctly, the remote RADIUS server (if it is configured as primary) is used for all authentication.

The local RADIUS (if configured as secondary) will only be used if the primary RADIUS is unreachable e.g. if the WAN link is down, right?

Scott Fella Mon, 02/25/2008 - 14:47

If you plan on having a radius server on the remote and on the central location, then you would have the remote radius server (authentication localy switched) as the primary and the central radius server (authentication centrally switched)as the secondary. You can have one or both centrally in your HQ to authenticate users at your remote offices if you like. You don't need a remote radius server for this unless this is what you want.

What you have to look at is if traffic (Internet, email, shares, etc) is centrally located, then if your WAN link goes down, they will still complain... you know... users! haha

Scott Fella Mon, 02/25/2008 - 14:50

If you plan on having a readius server on the remote and on the central location, then you would have the remote radius server (authentication localy switched) as the primary and the central radius server (authentication centrally switched)as the secondary. You can have one or both centrally in your HQ to authenticate users at your remote offices if you like. You don't need a remote radius server for this unless this is what you want.

What you have to look at is if traffic (Internet, email, shares, etc) is centrally located, then if your WAN link goes down, they will still complain... you know... users! haha

Scott Fella Mon, 02/25/2008 - 15:01

To be honest, what you have is your WiSM's centrally located (co-location)and your ap's going to be installed at HQ. Why go H-REAP? You can have your ap's on different layer 3 networks and have uses associate on a different network that is configured on the co-location side. Then it is just routing.

aadeoye Mon, 02/25/2008 - 15:08

You have a point.....that configuration works.

However, depending on how heavily the WLAN is used (in this case, it is going to be as it is a major business driver), you become exposed to major application latency issues since all traffic (whether remote or local) has to traverse the WAN through the LWAPP tunnel. In an extreme case, you may be looking at a bandwidth upgrade simply due to unnecessary traffic traversing the WAN from the WLAN.

I currently have one deployment with this issue and I want to avoid it in this installation.

Scott Fella Mon, 02/25/2008 - 15:15

I understand, then h-reap is what you will need to look at. Usually when you have the WiSM's centrally located, you also have email, application servers, etc located and have the bandwidth required. I have had multiple deployments in which having traffic run back to a central location was not an issues at all. These included multiple WiSM and or the 4400 WLC. Even with H-REAP you must make sure your users have available bandwidth to perform their work. what you will have to look into is implementing some type of QoS on both the LAN & WAN.

aadeoye Mon, 02/25/2008 - 15:20

Thanks. I will definitely have to look into QoS for the LWAPP traffic at least.

I am pretty certain that there is enough bandwidth for remote enterprise applications. However, the file and print servers are local and large file downloads are usually cached using local appliances. This type of traffic could wreak havoc on the current WAN infrastructure we have.

Scott Fella Mon, 02/25/2008 - 17:27

Well you do have options... don't leave h-reap out of it. There are also appliances that can help save your wan like WAAS.

Actions

This Discussion