Wireless Access

Hello,

I am asked to assist with a controller migration for a client of ours and am reviewing the current AOS 8 design. I found some things that I can't really make sense of, curious to get people's opinion.

I understand that it is probably a good idea to separate the interface that terminates the IPSEC tunnels from interfaces that carry the decrypted data. In this case,

VLAN 66 is used to terminate IPSEC tunnels for the mobility conductors and access-points. VLAN 66 is also the default gateway, and controller-IP.

There are also VLANs 300-304 configured, some of these VLANs have IP addresses configured on it.

Here's where it get's interesting, VLAN 300 has VRRP configured on it and is also the VLAN that contains the Mobility Conductors and most of the access-points. Interestingly enough VLAN 66 does not have VRRP.

This is where it gets really confusing for me, it works  but why would configure it like that? I see IPSEC tunnels with source VLAN 66 and destination IP addresses in VLAN 300.

I would think it is more intuitive if either of these were true:

A. You would not have access-points, or conductors in a direct data VLAN, and all access-points and conductors are upstream from the controller IP/IPSEC tunnel Interface

B. Have all access-points and conductors in the VLAN that connects directly to the controller-IP/IPSEC tunnel VLAN (66)

C. Your controller-IP/IPSEC tunnel VLAN (66) has VRRP configured

Below a visual representation? Curious what people think, I wasn't able to find this type of implementation in a reference guide but I could have missed it.

Hi Herman,

Thanks for your repsonse.

Yes, I think I understand it, I see now that a drawing I created for some kind of reason did not copy over to my post. I add it for additional detail.

You mentioned that the APs create a tunnel with their system IP, I assume in a redundant setup the APs will point to a VRRP address right?

Below the setup, I hope it is clear, pretty much all SVIs have IP addresses, and as explained even in the same VLAN as the APs are terminating in. The tunnel is however with a different VLAN. I depicted it below, the APs are duplicated to show IPSEC tunnel and where they actually reside.

APs will discover the controller cluster initially, for that they need to be pointed to one of the controllers or a VRRP on those controllers. Standard methods, DHCP, DNS, ADP, static. Once they are connected, the controller cluster will share the 'bucket map' with the controller-ip of each of the controllers. The APs will then pick an anchor controller and a standby anchor for the 'control' and distribute the clients over the controllers in the cluster.

You probably want to prevent asymmetric routing. If the APs will follow the routing as given from DHCP. That means if controller has IP in VLAN66 and 300 and L3 is on your core-switch (blue box in the diagram), if the controller IP is in VLAN66, the APs in 66 will communicate directly because they are directly connected. If the controller IP is in VLAN300, they will follow the default route to the core out of VLAN300, but the return will go direct to VLAN66 as the controller has an IP. Not recommended. Also, be aware the the controller has a single routing instance. So what I see most times is only have an controller L3 for the AP and management. Client VLANs are L2, so you don't care about routing there. If APs and Mobility Conductor (MCR) are in separate VLANs, route them outside of the controller so you only need 1 IP/route on the controllers and prevent asymmetric routing, and don't need to care too much on where to place the APs and MCR.

Based on the diagram, I still don't fully understand where your question is, but that may be because for me it's clear how it works. Hopefully with the description you are able to figure out where your missing link is.

Hi Herman,

Thanks for your repsonse.

Yes, I think I understand it, I see now that a drawing I created for some kind of reason did not copy over to my post. I add it for additional detail.

You mentioned that the APs create a tunnel with their system IP, I assume in a redundant setup the APs will point to a VRRP address right?

Below the setup, I hope it is clear, pretty much all SVIs have IP addresses, and as explained even in the same VLAN as the APs are terminating in. The tunnel is however with a different VLAN. I depicted it below, the APs are duplicated to show IPSEC tunnel and where they actually reside.

Hi Herman,

Thanks for your response it helps, the reason for reaching out has to do with a controller migration on AOS 8. I suspect that the current setup is not according to best practices, but it works. The question is: Should I just replace the 7205 controllers with 9240 controllers following the configuration 'as is' or should I update the configuration with more best practice configuration? If I choose to conform with best practices I potentially will be preventing future issues/bugs which are more likely to happen when you steer away from 'standards' and best practices.

Below a configuration snippet showing what I think in this context is relevant. As you can see datapath sessions show that IPSEC tunnels are using interface G0/0/0 while all decrypted user traffic is using interface G0/0/4. I noticed that Clearpass is configured with CoA addresses in VLAN 300. AP discovery is also pointing to an IP address in Vlan 66.

My gut feeling says:

Remove all IP addresses from the Vlan 300-304 change clearpass to point to VLAN 66 and set up VLAN 66 with VRRP and use this for clustering. If I do go this route it will be harder doing a graceful migration where I add the new controllers to the existing network. Curious to see what your opinion would be.

 

 

controller-ip vlan 66 

!

interface gigabitethernet 0/0/0

    description "controller port"

    switchport access vlan 66

    no spanning-tree

    trusted                                                                 

    trusted vlan 66

!

interface gigabitethernet 0/0/4

    description GE0/0/4       

    switchport access vlan 300

    switchport mode trunk     

    switchport trunk allowed vlan 300-305

    switchport trunk native vlan 300

    no spanning-tree          

    trusted                   

    trusted vlan 300-305 

!

interface vlan 66

    ip address 10.66.x.40 255.255.255.0                                       

!

interface vlan 300                                                             

    ip address 10.5.x.20 255.255.255.0                                         

    ip helper-address 10.x.x.x                                               

    ip helper-address 10.x.x.y                                                

!

interface vlan 302                                                             

    ip address 172.16.x.x 255.255.254.0                                        

!

interface vlan 303                                                             

    ip address 172.16.y.x 255.255.255.0                                        

    ip helper-address 10.x.x.x                                               

!

interface vlan 304                                                             

    ip address 172.16.z.x 255.255.254.0                                        

!

ip default-gateway 10.66.x.1

!

lc-cluster group-profile 7205-local-cluster

    controller 10.66.x.40 priority 250 mcast-vlan 0 vrrp-ip 10.5.x.21 vrrp-vlan 300 group 1 rap-public-ip 0.0.0.0

    controller 10.66.x.41 priority 100 mcast-vlan 0 vrrp-ip 10.5.x.22 vrrp-vlan 300 group 1 rap-public-ip 0.0.0.0

    active-client-rebalance-threshold 50

    standby-client-rebalance-threshold 75

vrrp 2                                  

    ip address 10.5.x.20                

    description 7205-vIP                

    authentication ******               

    priority 250                        

    advertise 1                         

    vlan 300                            

    no shutdown                         

 

Show datapath session info

10.ab.0.46       10.66.x.40     17   8209  8515   0/0     0    0   1   tunnel 2659 c    0          0          FYCI            11

10.5.x.95         10.66.x.40     17   4500  4500   0/0     0    0   0   0/0/0       19   11         6720       FC              12

10.66.x.40       10.a.1.129    17   4500  4500   1/0     0    0   0   local       4    1          29         FC              11

10.66.x.40       10.a.1.205    17   8222  8211   0/0     0    0   1   local       c    1          134        FCI             11

10.66.x.40       10.ab.0.11     17   8222  8209   0/0     0    0   0   tunnel 613  9    0          0          FYI             13

10.66.x.40       10.5.x.147      17   8999  8209   0/0     0    0   1   tunnel 1289 13   0          0          FYI             11

10.5.x.55         10.66.x.40     17   4500  4500   0/0     0    0   0   0/0/0       1a6  212        155504     FC              11

10.5.x.91         10.66.x.40     17   8209  8209   0/0     0    0   0   tunnel 975  91   134        73387      FCI             13

10.66.x.40       10.a.1.50     17   8222  8209   0/0     0    0   1   tunnel 838  13   0          0          FYI             15

10.ab.0.212      10.66.x.40     17   8209  8494   0/0     0    0   1   tunnel 2933 11   0          0          FYCI            11

10.66.x.40       10.a.1.231    17   8222  8209   0/0     0    0   0   tunnel 2245 2    0          0          FYI             14

10.a.1.209      10.66.x.40     17   8211  8494   0/0     0    0   1   local       b    0          0          FYI             11

10.5.x.143        10.66.x.40     17   4500  4500   0/0     0    0   1   0/0/0       f    1          464        FC              13

10.5.x.113        10.66.x.40     17   8209  8419   0/0     0    0   1   tunnel 2733 1a   0          0          FYCI            12

10.5.x.51         10.66.x.40     17   8209  8209   0/0     0    0   1   tunnel 1574 1b   5          3329       FCI             14

10.66.x.40       10.5.x.81       17   8419  8209   0/0     0    0   1   tunnel 1557 b    0          0          FYI             12

10.66.x.40       10.5.x.66       17   4500  4500   0/0     0    0   0   0/0/0       1f   1          29         F               11

10.66.x.40       10.a.1.11     17   8494  8211   0/0     0    0   1   local       14   2          258        FCI             11

10.5.x.97         10.66.x.40     47   0     0      0/0     0    40  0   0/0/0       480e 1257268    301376735  FC              13

10.66.x.40       10.5.x.132      17   8419  8209   0/0     0    0   1   tunnel 534  10   0          0          FYI             12

10.66.x.40       10.5.x.151      17   4500  4500   0/0     0    0   0   0/0/0       298  3          87         F               11                                             

Martijn van Overbeek Architect Work 800-886-5369 Email mvanoverbeek@blueally.com

 

APs will discover the controller cluster initially, for that they need to be pointed to one of the controllers or a VRRP on those controllers. Standard methods, DHCP, DNS, ADP, static. Once they are connected, the controller cluster will share the 'bucket map' with the controller-ip of each of the controllers. The APs will then pick an anchor controller and a standby anchor for the 'control' and distribute the clients over the controllers in the cluster.

You probably want to prevent asymmetric routing. If the APs will follow the routing as given from DHCP. That means if controller has IP in VLAN66 and 300 and L3 is on your core-switch (blue box in the diagram), if the controller IP is in VLAN66, the APs in 66 will communicate directly because they are directly connected. If the controller IP is in VLAN300, they will follow the default route to the core out of VLAN300, but the return will go direct to VLAN66 as the controller has an IP. Not recommended. Also, be aware the the controller has a single routing instance. So what I see most times is only have an controller L3 for the AP and management. Client VLANs are L2, so you don't care about routing there. If APs and Mobility Conductor (MCR) are in separate VLANs, route them outside of the controller so you only need 1 IP/route on the controllers and prevent asymmetric routing, and don't need to care too much on where to place the APs and MCR.

Based on the diagram, I still don't fully understand where your question is, but that may be because for me it's clear how it works. Hopefully with the description you are able to figure out where your missing link is.

Hi Herman,

Thanks for your repsonse.

Yes, I think I understand it, I see now that a drawing I created for some kind of reason did not copy over to my post. I add it for additional detail.

You mentioned that the APs create a tunnel with their system IP, I assume in a redundant setup the APs will point to a VRRP address right?

Below the setup, I hope it is clear, pretty much all SVIs have IP addresses, and as explained even in the same VLAN as the APs are terminating in. The tunnel is however with a different VLAN. I depicted it below, the APs are duplicated to show IPSEC tunnel and where they actually reside.