Frequently Asked Questions

Following is a list of frequently asked questions and answers relating to per user tunnel node.

In a controller cluster, how does the switch determine which controller to send the user traffic to?

The SAC sends a bucket-map to the switch during the switch bootstrap process. This map is an array of 256 entries with each entry containing the active and standby controller to use. A user’s MAC address is hashed into this table to get the controller to tunnel the user traffic to.

When is the heartbeat started to SAC and s-SAC?

Heartbeat is over a GRE tunnel with a specific GRE key (0xDEED). This is initiated with SAC and s-SAC immediately after a switch bootstrap is complete.

What happens when heartbeat to SAC fails?

A heartbeat failure triggers the switch to:

  • Remove users anchored to the SAC.

  • Fail over to the s-SAC (Example: s-SAC now becomes the new SAC).

What happens when the keepalive to a UAC fails?

The users anchored to the UAC are removed and a message is logged to the same effect in the event log.

Why should jumbo frames be enabled at the switch?

Jumbo frames have to be enabled at the controller uplink VLAN as well as the client VLAN. The GRE tunnel adds an effective 46 bytes to every user packet. The effective tunnel MTU = uplink VLAN MTU -46 bytes for a 1500 MTU, the tunnel MTU gets to be 1454 bytes. This means that a user can send up to only 1,454 bytes of frames. For users to send up to 1500 (default) MTU, jumbo frames need to be enabled.

What happens when a UAC controller goes down?

A node list update is sent by the SAC to the switch to inform that a controller went down. All users anchored to that controller are removed (unbootstrapped). After some time, the controller sends a bucket map update to the switch. The switch then processes the bucket map update and anchors users to the respective controller (standby) as per the bucket map. The users will then be switched over to s-UAC. The s-UAC becomes the new UAC, and is assigned after the bucket map update from SAC.
NOTE:

It is important to verify that the bucket map on switch and controller is the same. Also, it should be verified that users are anchored to the right controller identified in the bucket map on both the switch and controller.

What happens when a SAC controller goes down?

A node list update is sent by s-SAC to switch. Since the node list is received from the s-SAC and not the SAC, the switch considers that SAC is down and initiates a failover to s-SAC. Also, the switch removes all users anchored to SAC. Once s-SAC acknowledges the failover request, the s-SAC becomes the new active SAC. The new Active SAC then sends a node list update and bucket map update. In the node list update, the new s-SAC will be provided. The switch will then bootstrap and initiate a heartbeat with new s-SAC. The switch then processes the bucket map update and anchors users to respective controllers.
NOTE:

It is important to verify that the bucket map on switch and controller is the same. Also, it should be verified that users are anchored to the right controller identified in the bucket map on both the switch and controller.

What happens when the s-SAC controller goes down?

A node list update is sent by the SAC to the switch. The switch stops the heartbeat with the s-SAC which has gone down and removes all users anchored to it. The switch then initiates a bootstrap to a new s-SAC provided in the node list update. Once a bootstrap acknowledgment is received, the switch starts a heartbeat to the new s-SAC. After some time, the SAC will send a bucket map update. The switch then processes the update and anchors users to their respective controllers.
NOTE:

It is important to verify that the bucket map on the switch and controller is the same. Also, it should be verified that users are anchored to the appropriate controller according to the bucket map on both the switch and controller.

What do the states in show tunneled-node-server state mean?

  • Registering - Bootstrapping

  • Registered - Bootstrapped

  • Unregistering – Unbootstrapping

What happens when user-role attributes change?

A rebootstrap is initiated for users applied within that role containing updated role attributes in the bootstrap packet. These users move to registering state. Once an acknowledgment is received from the controller, users then move to registering state. This applies only to VLAN and secondary role changes.

What happens on a client “MAC address move”?

A rebootstrap is initiated for the client. Only after an acknowledgment from the controller is received, the client traffic begins to be tunneled.

What is the recommendation for Per User Tunnel Node client VLAN configuration?

  • Tunneled user client VLAN has to be present at the per user tunneled node switch.

  • There is no need to specifically add tunneled user ports to this VLAN. Switch AAA takes care of this through MAC-Based VLANs.

  • The uplink to the controller port should NOT be part of this VLAN.

  • The uplink to the controller VLAN and the tunneled users VLAN cannot be same.

A user is registered at the switch but does not respond to a ping. How do I debug?

  • Check that the user roles and VLANs are correctly configured at the switch as well as the controller.

  • Check that the IP MTU is set to >= (1500+46) at all the switches in the path from User-Based Tunneling switch to the controller.

There are two parts to the solution, and the part that is failing should be identified.

  • To check if the switch is tunneling the traffic, run the show tunneled-node-server statistics command to check if the user traffic is being received and transmitted. If the counters do not increment, then the switch configuration needs to be investigated.

  • To check if the Mobility Controller is tunneling traffic, run the show datapath tunnel to see if the Encaps and Decaps counters increase.

A packet trace of traffic sent from and received at the switch uplink to the controller can also be useful, GRE encapsulated packets are what will be of interest.