Controllerless Networks

When you VC assigns he client addresses, they are being NAT'ed behind the AP IP as far as I understand it. A customer is having roaming issues because of this, and a network assigned design would sort this. However I thought I ask if you can NAT clients behind the VC IP address rather than the actual IAP IP when you are running Virtual controller assigned addresses.

When you select "virtual controller assigned" for the IP addressing, all client traffic on this SSID will be sent to the VC and src-NAT'ed from the VC.  

 

You can also select a local VLAN for DHCP assignment and have the VC function there as well.  This would require 

 

1. The VLAN set to static with the appropriate VLAN ID as well as trunking/tagging at the IAPs uplinks

2. The DHCP settings configured in the DHCP options on the cluster set to Local, L3.

HI John,

Could you give more details about the roaming issue that you are having?

Thanks,

Yan

Hello.

The roaming issue is simply that they move in the office and loose the ongoing citrix session. They need to restart it. However, it looks like the IAP cluster is unstable (IAP's reboots), so I have raised a TAC case for this to investigate the reason. THe master IAP had an uptime of 4 hours, and the IAP had been installed for 2 weeks. No power outages.

 

The customer hadn't specified any VC adress, so I set an IP for the VC, but still it picked the master IAP ip as source rather than the VC IP.

With no VC IP, and AP's rebooting that will explain why people loose citrix sessions since it will be sourced from a new IP everytime the current master changes. It also means that it necesarly don't have to do with roaming.

 

Can you confirm that the sourced IP should be the VC one, and not the current master AP IP?

Sorry, just a bit curious on this source address still. WHat I am seeing in our deployment is that the traffic is indeed sent to the VC for source NAT, but it's source is the IAP DHCP address, and not the static address assigned to the VC.

I don't know if this is intentional, but I assume it is ment to be like this, and it is important to keep in mind when working with an IAP cluster since a change of master IAP will disrupt sessions as the source IP will change with the IAP.

Yes the source IP after the NAT is the VC AP?s local IP and not the VC IP, this is intentional. It is also true that a VC failover event will have some disruption to NATTed traffic. In fact, even If the NATTed IP is set to the VC IP, the fail-over scenario would still have disruption due to the fact that the mapping between the VC IP and its associated MAC address has changed. There are things that we can do to solve that as well, but right now we have decided not to do it.

Does this limitation place an undue burden on this network?

What code are you on?  I know there are some enhancements to DHCP in 4.0

Hello, and thanks for the reply. No it doesn't cause any undue limitation, it's merely for knowledges sake and understanding on what to expect when masters change. This issue could easily be solved by changing design of the solution to network assigned addresses.