wireless mobile cart with static ip

gnijs · ‎05-21-2011

Hello,

I am having a design problem: we are having a mobile cart with a device sitting on it. This device is configured and only supports a static IP (no DHCP support). The device is connected to a bridging AP and this AP associates to the WLAN infrastucture that is using two WISMs in two C6500 chassis.

The problem is redundancy. The two C6500 chassis only have a Layer3 routed link between them (no extended VLANs), so the Wifi network is using one VLAN in chassis A and another VLAN in chassis B, both VLANs are associated with the same WLAN SSID and controllers are put in a mobility group for roaming. For DHCP clients , this works great. However, the mobile cart has problems: since the ip can only belong to one VLAN (for example VLAN A), if the bridging AP associates to an AP on the second controller (VLAN B), it does not work. Also, when one of the two WISMs or C6500 controllers needs to be booted, we have a problem.

What are my options here ?

1) Converting the link between C6500 to trunk and extending a single Wifi VLAN across controllers just for this single device, i would like to avoid.

2) Can i bridge two Wifi VLANs on the two C6500 using:

- a GRE tunnel between C6500 with a bridge group for example ? Will this work ?

- an L2TP (xconnect) between the C6500 chassis ?

3) Putting a router on the cart in between the device and the AP, then let the router run DHCP on its connection to the brdiging AP. This looks easy, however, how am i going to route traffic to the mobile device, if i don't know to which WLAN the bridge has associated. I think the server sitting on the LAN also has the static ip programmed, it does not use DNS. I will have to use a routing protocol (ie RIP/OSPF) across the Wifi network to communicate the mobile VLAN. And if the bridge AP re-authenticates or re-associates, it will have to bounce the Ethernet interface to force the router to re-new its ip address. Feasible ? Recomended ?

NOTE: The APs in the mobile cart region are mixed and some are joined to WISM1 in C6500-1, other are joined to WISM2 in C6500-2.

regards,

gn

CCIE #13729

Surendra BG · ‎05-21-2011

Hmmm.. On top of my head this is wat i understood.. please correct my imagination is incorrect..

Topology

======== VLAN 2

------------------- AP3 ))))))))) (((((((((((( ----------------- 6500 WISM 2

| |

| | Single VLAN allowed

CART - AP1----- |

| |

|

--------------------- AP2)))))))) (((((((((((( ----------------- 6500 WISM 1

VLAN 1

if the cart associates to AP2 ( WISM 1) then, To VLAN 2 we do not have the connectivty and if gets associated to AP 3 WISM 2 then VLAN 1 wont be able to reach..

In this case, we need the VLAN to span around the network and this will help.. We shoulf have both the VLANs on both the switch to get this issue resolved. (Getting the network connectivity).

I guess Option 1 will be more easier approach but you wanna avoid it.. may i know why u wanna avoid??

Lemme know if this answred ur question!!

Regards

Surendra

Regards
Surendra BG

gnijs · ‎05-21-2011

Thanks for your reply. Your drawing is correct, if you assume the device on the cart has an ip address in either VLAN1 or VLAN2, but not both.

I know that creating an extended VLAN is the out-of-the-box solution, but since our infrastructure is completely Layer3 based, i like to avoid extended vlans as much as possible. Second, the link between the C6500 is a L3 Portchannel and a core network link. Converting this to a trunk is going to bring downtime and getting this through the change and validation process is not going to be easy :-) but i will try it anyway...Therefore , i was looking for solution (?) to bridge two vlans across a L3 link, so that i would not have to touch the inter-core link.

regards,

gn

John.Gerlach · ‎05-23-2011

One additional option to research consider is potentially making use of an anchor to home your SSID/vlan to one of your controllers and then tunneling from the other. In this way they can make use of the same IP scheme/segment on both controllers because they are truly running on the same controller.

We have had this solution proposed to us for some very specialized wireless devices that require static address. We have not implemented it (yet?), however, so I am unable to speak to how well it works. But for us it has a certain appeal since we have a multi-story facility and each floor actually homes to alternating data centers/controllers. Then we can set up a separate SSID/VLAN for the specialty devices, anchor it to one of our campuses and then tunnel the connections from the other campus over to the anchor. That should allow us to use the static IP address no matter which floor the device is on, and if the device is restarted on one of the floors we should not have an issue with an IP address conflict because of the floor we happen to be on.

I do see us doing this in the future for a limited number of devices with static IP requirements.

gnijs · ‎05-24-2011

John,

That is a great idea. Didn't think about that. We are already using Anchor controllers for Wifi Guest services. And indeed, it would fit the solution.

The only problem: we only have two controllers on our site and the solution needs to be redundant. I cannot Anchor these controllers to each other

for redundancy i guess. I might require two new small Anchor controllers that will be connected to redundant switches.

A bit like this document:

http://www.cisco.com/en/US/docs/wireless/technology/guest_access/technical/reference/4.1/GAccess_41.html

Thanks,

gnijs