Powered by Squarespace
Popular Categories
Blog Posts
Discussion Activity
Cisco Live 365
« Cisco Embedded Event Manager (EEM) Config Diff Generator | Main | Cisco WLC (Wireless LAN Controller) Series - Building Blocks »

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

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

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.


No network can be designed in a vacuum without consideration of the services and devices for which it is to support.  The needs of a brick-and-mortar’s network can be substantially different from those of an e-commerce pure play, although the lines are blurring between the two as both types of networks use common building blocks in network design and both usually have some requirements that may be light in one and heavy in the other.  Brick-and-mortar businesses may have heavy corporate needs and light Internet Data Center (IDC) requirements, but e-commerce is heavy in IDC and usually lighter in corporate needs.

Much has been written on good IP Planning which won’t be repeated here in any detail.  Those plans consider a global IP space broken into regions, metro areas, campuses, buildings, floors, etc., so any one of those areas can be expanded without much additional planning and without creating problems between the boundaries. 

Routing summarization is a key requirement of a supportable IP Plan 

Allowance is to be given to squeeze unforseen subnets into their proper place without reworking the entire plan.  As new requests come up to build out another floor, building, etc., it should be a bit of a no-brainer to pick off the proper networks to deploy.  Finding yourself redesigning your IP Plan (each time a new request for space comes) is a symptom of a poor plan.


Flexiblity is really just a deeper level of supportability.  Whereas supportability allows you to expand to expected types of networks, flexibility allows you to grow into unexpected ones.  While summarization is a key design goal, this does not mean all your network or subnets need to be absolutely contiguous, precluding some flexbility.

As an example, if the IP Plan for a building dictates a /24 for users on each wired floor in a 4-story structure, you don’t need to have your floors numbered x.y.0.0/24, x.y.1.0/24, x.y.2.0/24, and x.y.3.0/24 to allow for a summary route of x.y.0/22.  Why not use a larger block for the building with some flexibility to grow in an unexpected way such as a wireless overlay.  I prefer to use /24s for floors when possible and use the third octect to indicate floor number.  So my first floor gets numbered x.y.1.0/24.  By the way, x.y could be the region (x) and metro (y) areas with campuses just a summary of buildings.  The second floor is x.y.2.0/24, etc.  I retain x.y.0 for aggregation or core links.

At this point, you probably wondering about the VLAN planning.  This naturally follows the IP Plan at a local level given that VLANs are L2 concepts with usually building- or site-specific relevance.  For floor x.y.1.0/24, I could assign VLAN 10.  Why not VLAN 1 for the 1st floor?  Best practice stipulates to not use VLAN 1 for security reasons.  And doing so here would imply that VLAN 2 is used for the 2nd floor.  But now you would have exactly zero spare VLAN IDs between 1 and 2.  Hence, VLAN 10 for the first floor progresses to VLAN 20 for the second floor, given you spares.  On certain floors where a corporate data center may exist, I prefer the subnet to be in a different summary route from the users for security application.  I could do the same for the VLAN, but as I rarely have VLAN ACLs (VACLs) that I need to worry about, so I could use VLAN 11 for a data center on the first floor after VLAN 10 for the users.

Wireless often augments or supplants existing wired networks.  We’ll assume both wired and wireless will parallel one another.  Where marketing users today, for example, have wired access, we’ll assume they’ll be getting a wireless network along side of that.  Within the existing IP Plan, you may be tempted to just tack on wirless subnets to the end of your existing blocks without additional thought.  Will you be able to summarize all wireless networks for a given building or campsus with a single ACL to make management less burdensome?

Now where should the wireless overlay be placed?  Since the wireless network is predominatly for users, we look further into the different use-cases driven by either mulitple SSIDs or dynamic VLAN assignment with one SSID for internal or Internet-only networks.  As the desire is to be able apply ACLs or VACLs with ease, we need some logical grouping that fits into the wired plan.  This now really becomes a question of security requirements to dictate one direction over another.


Do you prefer to logically group all users together regardless of their wired or wireless connections?  Or do you prefer to separate wired users from wireless users?  Or perhaps some combination?  In my environment, multiple SSIDs are deployed for the different use-cases.  We’ll discuss just two of them.  One SSID is used for full internal access and another for Internet-only access.

Since full internal access from both the wired and wireless networks can have the same treatment, the wireless VLAN on the first floor gets assign ID 19 — using the last of the first floor VLANs (10-19).  I can now deploy VACLs to cover all 1st floor VLANs if needed.  For the IP assignments, it’s more important to me that we can apply ACLs to cover all wireless space regarless of where it is in a building, so wireless subnets are taken out of a higher block of building addresses.  If a building was assigned a /19, we have 32 networks that could be deployed as /24s.  We already used 4 of them for the floors. A /21 CIDR block could summarize those (x.y.0/21).  Earlier a data center network was described which could come out of the next /21, starting at x.y.8/21 and going up to x.y.15/21.  And for wireless, I would deploy x.y.16/20, and segregate internal wireless from Internet-only wireless further with x.y.16/21 for internal wifi and x.y.24/21 for Internet-only. 

The table below shows sample IP and VLAN assigments to address supportibility, flexibility, and security.

  • Building x.y.0/19
    • Wired x.y.0/20
      • Agg/Core x.y.0/24
      • Users x.y.0/21
        • Floor x.y.<floor>/24    [IP x.y.1-4] [VLAN 10, 20, 30, 40]
      • Other x.y.8/21
        • DC x.y.<floor+8>/24    [x.y.9-12] [VLAN 11, 21, 31, 41]
    • Wireless x.y.16/20
      • Internal x.y.16/21
        • Floor x.y.<floor+16>/24    [x.y.17-20] [VLAN 19, 29, 39, 49]
      • Internet-only x.y.24/21
        • Floor x.y.<floor+24>/24 [x.y.25-28] [VLAN 119, 129, 139, 149]

I know the network purists will be bent a bit out of shape with these subnets not starting at the top of each CIDR block, but this method make it easy to calculate the third octect (and hence the entire IP subnet) from just knowing the floor.

In subsequent sections in this series, we’ll touch topics on:

  1. DHCP Proxy
  2. AP Groups
  3. Guest wireless (without an auto-anchor)
  4. Mobility Group & Domain


Sections in this series (completed):

  1. Introduction
  2. Building Blocks
  3. IP & VLAN Planning (this article)



Reader Comments

There are no comments for this journal entry. To create a new comment, use the form below.

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
All HTML will be escaped. Textile formatting is allowed.