Cisco WLC (Wireless LAN Controller) Series - IP & VLAN Planning

In part III of this Cisco WLC Series, we’ll discuss IP and VLAN Planning, an unexceptional area in network design that often doesn’t get the level of treatement it deserves, in the context of wireless. 

Any good IP and VLAN design needs to accomplish three goals.

1. Able to support current needs
2. Permits some degree of flexibility 
3. Creates a framework for security

These goals are no different for wireless.  In the corporate network I support, the IP and VLAN Plan was established many years before wireless was given a serious seat at the table.  Only by meeting the second goal that allows for flexibility, wireless was able to be overlayed with the wired network with enough degrees of separation to continue to meet the third goal of maintaining a security framework.  Some of the decisions that go into a sustainable IP and VLAN Plan don’t require more than a few extra cycles of thought that readily pays for itself in unforseen ways.

To jump to the beginning of this series, see the Introduction.

Click to read more ...

Cisco WLC (Wireless LAN Controller) Series - Building Blocks

In this section on the Cisco WLC Series, I’ll attempt to show the relationships between the basic building blocks in a concise and meaningful way.  We’ll cover:

1. Ports
2. Interfaces (Service, Management, Dynamic)
   
3. Interface Groups
4. WLANs

To jump to the beginning of this series, see the Introduction.

Click to read more ...

Cisco WLC (Wireless LAN Controller) Series - Introduction

After many late nights and pouring over countless sources of documentation, including the voluminous docs found at Cisco.com, all the concepts and design elements that comprise a Cisco WLC (Wireless LAN Controller) architecture have finally “clicked”.  I’ve somehow managed to escape enterprise wireless until now.  Learning a new platform is simultaneously exciting and challenging, particularly on day 1.  For any seasoned network engineer, jumping into the depths of enterprise wireless for the first time presents a steep learning curve that quickly needs straightening out.

Image (c) 2012 FoundTheTimeDesigns.com - used with permission

Tackling a new GUI/CLI is initially a series of exercises and tests in attaining enlightenment of not only the overarching architecture of the platform, but in understanding subtle nuances and hierarchical relationships.  Sample walk-thrus of configuration rarely explore these nuances in any meaningful way; that takes frequent help-searches and reference materials.  The process of reaching your “light bulb” moment is akin to having a pile of multicolored marbles that you can finally begin to order in a meaningful way.

Click to read more ...

Cisco CSS 11500 HTTP-to-HTTPS (SSL) Redirection

A simple approach to handle sites that require SSL (HTTPS) encryption is to not allow plain-text HTTP, but that’s not very user-friendly and no one likes having to type extra characters into the browser to indicate HTTPS as the URI scheme.  So the elegant solution for the client-side request is to allow HTTP, but then to redirect all such requests over to SSL.  If you’re doing SSL Acceleration on your CSS 11500 load-balancer anyway, and you have public facing sites, you should also be doing HTTP-to-HTTPS (SSL) redirection.

Assuming you already have SSL termination configured, you’ll already have SSL and HTTP VIPs that work together.  The trick is to add a different VIP (virtual IP adddress) for the SSL proxy and convert the existing HTTP rule to a redirect rule.  Optionally, you could use a redirect service in the rule instead.  Entire config snippets available here.

Click to read more ...

Cisco ACE Module HTTP-to-HTTPS (SSL) Redirection

A simple approach to handle sites that require SSL (HTTPS) encryption is to not allow plain-text HTTP, but that’s not very user-friendly and no one likes having to type extra characters into the browser to indicate HTTPS as the URI scheme.  So the elegant solution for the client-side request is to allow HTTP, but then to redirect all such requests over to SSL.  If you’re doing SSL Acceleration on your ACE load-balancer anyway, your configuration will become simpler in the long-run since you won’t have to maintain as much duplicate configuration to handle different load-balance policies for plain-text HTTP and SSL.

The solution is to create a generic redirect rserver and serverfarm that can be used for any  SSL loadbalance policies.  For web applications that may build absolute paths, the web server may need to know that the client protocol has switched over to SSL so you don’t have needless redirects.  A HTTP Header can be sent in the request toward the web server to inform it of the protocol using the de facto standard header called X-Forwarded-Proto — using the standard Via header is another alternative and will be shown in an example.

Click to read more ...