Extending VLAN across remote WAN sites

[spfister336]

We have several remote sites in a hub-and-spoke arrangement (central site: 9500 pair, remote sites: 4500X pair). Remote sites are connected back to the central site via the AT&T ASE on demand service.

For each remote site, there is exactly one VLAN we need to extend back to the central site for the next several months (i.e., a different VLAN per remote site; each VLAN is not being used at more than one remote site). This involves AT&T learning MAC addresses from us from one end to pass to the other end. This is working as is, but we've been told there may be a limited capacity (and very high fee) to increase the number of MAC addresses they learn (from the default 250). We would like to look at alternatives, maybe a GRE tunnel. Just something where AT&T doesn't have to learn individual MACs. What is the best and simplest solution? We may need to implement something in the very near future.

[spfister336]

Yes, the WLC is doing CAPWAP tunnels out to the APs. That's why the issue of MAC address learning hasn't been an issue before the current Meraki installs.

And we are trying to use the same VLANs and SSIDs for both systems. I thought that's what was needed to prevent issues during the transition period. I'm extending the VLAN back to the central site because that's where the default gateway is.

I'd still like to use the same SSID for both systems, but what if:

- I came up with a new VLAN for Cisco AP users, at least for sites still in transition?

- or, alternatively, I remove the VLAN extension across the WAN, and have the same VLAN with the same subnet and VLAN number at both central and remote sites? We are using EIGRP as our routing protocol, so we would need to keep it from being advertised. I was considering something like this in the beginning, but it seemed kind of messy.

[Giuseppe Larosa]

Hello @spfister336 ,

thanks for having explained in more detail your network scenario.

Meraki APs act as bridge because their  "WLC" is in the Cisco Meraki public cloud so it would make no sense to tunnel traffic to/from the cloud.

However, you can allocate new SSIDs for Meraki APs and what is more important you can use per site IP subnet / VLAN associated to each SSID.

Your multilayer switch can act as default gateway for new VLAN/ IP subnet and they can route to the central site the new subnets and the central site configuration of routers or firewall need to be updated to perform NAT also for the new IP subnets.

Routing  on the central site has to be updated too. You can consider using a dynamic routing protocol for this like EIGRP or OSPF.

By doing this you can solve the MAC scalability issue.

As suggested by @Joseph W. Doherty you should move to use the VPLS service for a transit VLAN and to use IP routing in this way the only MAC addresses that would be seen are those of the multilayer switches regardless of how many WIFI users are active in each site.

Hope to help

Giuseppe

[spfister336]

Just thinking over what I posted.... that second idea doesn't really make sense, does it?

[Joseph W. Doherty]

I don't see a need to not have different wireless VLANs beyond it might simplify any ACL rules you have in place now.

Hmm, would need to really think about using the same SSID, for two different wireless topologies.  It might work, but if it does "roaming" might be problematic, as the wireless host would likely assume moving to a different wireless AP, using the same SSID, doesn't impact wireless host IP.

I would suggest, using different SSIDs and different VLAN networks.  Existing SSID could be changed with adding an "old-/-old" prefix/suffix, new wireless would use existing SSID, and people using wireless would need to know one or the other, or both, SSIDs might be found active, but network resource access (privilege) is the same for either.

With this new information, you might not need to bridge any L2 across WAN, at all.

[spfister336]

Unfortunately, in this environment, I don't think multiple SSIDs would work at all. The vast majority of our users are students, some of whom are rather young. Plus, a lot of our teachers and staff aren't the most tech-savvy. They are used to receiving devices that have the correct wireless network pre-selected, and most wouldn't know how to select a different network, if that is even an option for users the way most of our devices are locked down. And I'm not sure I could explain to them when to select the "new" SSID and when to select the "old" SSID. We're really just supporting a small handful of old Cisco APs in each location. It would make things really easy for IT, but everyone else would hate it.

Would having the same SSID, but different VLANs be a problem? Most of our users don't really roam while using wireless devices, but the principals sometimes take iPads and visit different classrooms.

What would need to be updated in particular on our EIGRP? Just the new subnet? I wasn't clear on that. We've always been EIGRP-based.

[Joseph W. Doherty]

Again, not 100% sure about using the same SSID, on different APs, that connect to different networks.  But, I think the result would be much like having a wired client you connect to a switch hosting two different VLANs/networks, where you connect to one port and then, decide to reconnect to another port (that's on the different VLAN).

For a wired client, its host would "see" the link drop and restart, and should check its IP, and if it finds it's no longer valid, pull a new IP.  That would should allow client to resume operations, but changing an IP if there are any open network sessions, will very likely drop them.  The whole ideal of wireless "roaming" moving to another AP doesn't break any open sessions.

For a wireless client, that doesn't "move" after getting on-line, I suspect they will work fine.  I.e. their host will connect to the "best" AP and use it.  Again, though, if they start to roam, and the host tried to reconnect to another AP offering the same SSID, but it's not the same network, then that's when I suspect problems may arise.

Of course, much of this might be mitigated by how you deploy.  Only use the existing wireless APs, at any one location, until all the new APs are installed and ready to be activated.  (Difficult to do, tough, if you intend to use the same physical connections.)  Then, say 3 AM on Sunday morning, deactivate the location's old APs and activate the new.  If all works, remove the old APs at your convenience.

[MHM Cisco World]

if the AT&T provide you H-VPLS then I think it will work 

""The big advantages for the service provider in deploying dot1q tunneling are saving VLANs and transporting customer VLANs transparently, so that the service provider does not know which VLANs need to be transported and to which remote sites.""

[spfister336]

I've contacted our AT&T rep to see if VPLS is something we can look into

[MHM Cisco World]

it not VPLS it H-VPLS 
Knowledge Base - Hierarchical VPLS (google.com)

[spfister336]

I didn't know there was a big difference. I'll make sure I'm asking about the right thing.