Wired Intelligent Edge

Good Morning,

     When using the S3500 Mobility Access Switch in tunnel mode in conjunction with ClearPass.  What IP Address is used as the source and destination from the Mobility Access Switch to the Mobility Access Controller?

     I'm trying to understand the affects of tunnel mode on up stream core data switches when either MC-LAG or normal LAG is used in the Distribution or Leaf and the Core.  Typically, these load sharing protocols use source/destination IP, MAC, and Protocol to hash out load sharing.

     My concern is that when 48 devices plug into a S3500 switch, they are all tunneled to the 7200 controller, how does that really effect things.  

     Thank you!  Regards,

Jamie

Jamie,

The Mobility Access Switch will use the "controller-ip" address under "ip-profile" as the source of the GRE tunnel to the Mobility Controller. You can verify the IP by using "show switch ip". The destination address is defined by the Tunneled Node profile:

!
interface-profile tunneled-node-profile "TUNNEL-TO-CTRL"
   controller-ip 172.16.50.60
!

We establish a single GRE tunnel from the Mobility Access Switch to the Mobility Controller so the L2/L3/L4 information will end up being the same.

As a side note, since you do have ClearPass, you could use its downloadable role/ACL capability to centralize the policy in CPPM but have the switches themselves do the actual authentication instead of the Mobility Controller.

Best regards,

Madani

Couple of things.  Each port that you have tunneled node enabled is a separate tunnel.  As far as the IP goes, the source IP is the "controller" ip or switch ip set on the MAS.  

To verify on the controller, use the following command:

Small correction to Seth's email, from the Mobility Access Switch's perspective, only a single GRE tunnel is established to the Mobility Controller regardless of the number of TN ports. However from the perspective of the Mobility Controller, each Tunneled Node port from a single switch/Arubastack will appear as an individual tunnel and consume tunnel resources as such. But again, if you were to sniff the traffic egressing the MAS, it would just be one tunnel.

Best regards,

Madani

Thanks to everyone that commented.

To be honest, the will really make life hard in the Core and Distribution.  As it stands, each Mobility switch stack will be sending traffic to the controller through only one stream making it difficult to load share across LAG ports.

Jamie,

Not sure I follow. Each Mobility Access Switch would have its own IP address and MAC address so from the distribution and core side, they're should be loadbalancing there.

Additionally, we typically recommend redundant controllers for these environments and so you could point one set of stacks to one controller and another set of stacks to another (via VRRP Groups or backup-controller-ip option). I would be concerned with a single controller deployment because if that goes down, so does all your wired users.

Best regards,

Madani

It sounds like you are concerned about the flow of traffic across the port-channel members because the source and destination is essentially static for every packet and can't be balanced with the normal src-ip, dst-ip, src-port, dst-port algorithms.

Is that your concern?

Is there a particular reason why you want to use tunneled node instead of enforcing the policy on the stack itself (as Madani mentioned)? This would definitely be the best route if you don't have redundant controllers upstream (tunneled-node termination points). You can rely on routing protocols or STP for secondary paths.

Depending on the switch, you can always change the LAG hash algorithm to something that would be a better distribution.  I know Brocade/Foundry supports this.