Wireless Access

Hello All,

Just wanted to confirm the Tunneled Node Configuration on the MAS.

If I have the Aruba MAS Switches on the Access/Distribution Layer and also on the Core Layer of which the Aruba Controller terminates on the Core MAS, can I assume that the Tunneled Node Profile configuration will be done on the MAS Switches on the Access/Distribution Layer? Then have that applied to the Physical Interfaces. Nothing built on the MAS Core.

And then just have the aaa authentication wired profile configured on the Aruba Controller?

And if I have APs terminating on the Access/Distribution Layer MAS Switches, is it okay for me to create a VLAN for Employees and also a VLAN for APs? That is what I considered doing. But then have the Server derivation policy push the VLAN for Employees after successful authentication.

Look forward to hearing from you.

Yes, you would only enable tunneled-node on the access-layer ports.

Yes, you would use the aaa authentication wired profile on the controller.

No, you cannot have the APs connected to a tunneled-node port because that would create a tunnel within a tunnel situation which the Mobility Controller cannot support at this time.

Best regards,

Madani

---

@madjali wrote:

Yes, you would only enable tunneled-node on the access-layer ports.

 

Yes, you would use the aaa authentication wired profile on the controller.

 

No, you can have the APs connected to a tunneled-node port because that would create a tunnel within a tunnel situation which the Mobility Controller cannot support at this time.

 

Best regards,

 

Madani

---

Hi Madani,

Thanks for your response.

So you are saying that I just need to create one Access VLAN applied to the Tunneled-Node Ports and then have the APs terminating on those Ports? Didn't quite understand your last comment.

How does that work? The idea was to have Laptops terminating on those Tunneled-Node Ports. isn't it?

Aruba APs establish a GRE tunnel between themselves and their Mobility Controller in the same way that the Mobility Access Switch establishes a GRE tunnel to the Mobility Controller for Tunneled-Node. This creates a problem for when an AP is on a port configured for Tunneled Node. Basically the AP wants to create a GRE tunnel to get to the Mobility Controller and when that traffic hits the Tunneled-Node port, the Mobility Access Switch puts the payload in another GRE tunnel which creates a tunnel within a tunnel.

So for your APs, you need to use a regular access port as opposed to a tunneled-node port.

Best regards,

Madani

Oh yes for sure. That's the plan.

Sorry for the confusion.

What I intended to say was to create an Access VLAN for the Laptops/Users and then associate that VLAN to the Tunneled-Node Ports. But then have a separate VLAN for APs and have a Trusted Port applied to the Physical Interfaces of which the APs will be terminated on. Is this a correct design considertaion or best practice?

Secondly, the Tunneled-Node Ports have to have a Switching-Profile of "No Trusted Port". Correct?

---

@eosuorah wrote:

Oh yes for sure. That's the plan.

 

Sorry for the confusion.

 

What I intended to say was to create an Access VLAN for the Laptops/Users and then associate that VLAN to the Tunneled-Node Ports. But then have a separate VLAN for APs and have a Trusted Port applied to the Physical Interfaces of which the APs will be terminated on. Is this a correct design considertaion or best practice?

 

Secondly, the Tunneled-Node Ports have to have a Switching-Profile of "No Trusted Port". Correct?

 

 

---

Hi Madani,

Can you respond to my above quote/statement?

Thanks!

I've commented inline:

What I intended to say was to create an Access VLAN for the Laptops/Users and then associate that VLAN to the Tunneled-Node Ports. But then have a separate VLAN for APs and have a Trusted Port applied to the Physical Interfaces of which the APs will be terminated on. Is this a correct design considertaion or best practice?

MA> The short answer is yes. The vlan defined in the switching-profile, which ultimately is passed up via Tunneled-Node, must match a VLAN on the Mobility Controller. With respect to best practise, some customers just use the switching-profile VLAN as a landing VLAN if you will but AAA on the Mobility Controller side moves the user over to a different VLAN. Either way is fine. 

Secondly, the Tunneled-Node Ports have to have a Switching-Profile of "No Trusted Port". Correct?

MA> The "[no] trusted port" command only applies to native AAA enabled ports on the Mobility Access Switch. When you are using tunneled-node, all AAA is performed by the Mobility Controller so "no trusted port" has no effect.

Out of curiosity, what is your use case for tunneled-node ports versus native AAA functionality. Centralized security at the controller?

---

@madjali wrote:

I've commented inline:

 

What I intended to say was to create an Access VLAN for the Laptops/Users and then associate that VLAN to the Tunneled-Node Ports. But then have a separate VLAN for APs and have a Trusted Port applied to the Physical Interfaces of which the APs will be terminated on. Is this a correct design considertaion or best practice?

 

MA> The short answer is yes. The vlan defined in the switching-profile, which ultimately is passed up via Tunneled-Node, must match a VLAN on the Mobility Controller. With respect to best practise, some customers just use the switching-profile VLAN as a landing VLAN if you will but AAA on the Mobility Controller side moves the user over to a different VLAN. Either way is fine. 

Secondly, the Tunneled-Node Ports have to have a Switching-Profile of "No Trusted Port". Correct?

MA> The "[no] trusted port" command only applies to native AAA enabled ports on the Mobility Access Switch. When you are using tunneled-node, all AAA is performed by the Mobility Controller so "no trusted port" has no effect.

 

Out of curiosity, what is your use case for tunneled-node ports versus native AAA functionality. Centralized security at the controller?

---

Exactly that. The Customer wants to use centralized security via the Controller.

In that case, you can use the tunneled ports for the users pc/laptops and for the APs please use non-tunnelled  ports

Thanks guys!

---

@eosuorah wrote:

---

@madjali wrote:

I've commented inline:

 

What I intended to say was to create an Access VLAN for the Laptops/Users and then associate that VLAN to the Tunneled-Node Ports. But then have a separate VLAN for APs and have a Trusted Port applied to the Physical Interfaces of which the APs will be terminated on. Is this a correct design considertaion or best practice?

 

MA> The short answer is yes. The vlan defined in the switching-profile, which ultimately is passed up via Tunneled-Node, must match a VLAN on the Mobility Controller. With respect to best practise, some customers just use the switching-profile VLAN as a landing VLAN if you will but AAA on the Mobility Controller side moves the user over to a different VLAN. Either way is fine. 

Secondly, the Tunneled-Node Ports have to have a Switching-Profile of "No Trusted Port". Correct?

MA> The "[no] trusted port" command only applies to native AAA enabled ports on the Mobility Access Switch. When you are using tunneled-node, all AAA is performed by the Mobility Controller so "no trusted port" has no effect.

 

Out of curiosity, what is your use case for tunneled-node ports versus native AAA functionality. Centralized security at the controller?

---

 

Exactly that. The Customer wants to use centralized security via the Controller.

 

 

---

If we have a AAA Profile chooses to move the User to a different VLAN, shouldn't that VLAN still exist within the MAS Switch?

No we donot want the VLAN to be in MAS, as all the traffic in port  are tunnelled and aaa profile is enforced on the controller not on the switch. 

---

@vkumaar wrote:

No we donot want the VLAN to be in MAS, as all the traffic in port  are tunnelled and aaa profile is enforced on the controller not on the switch. 

---

So if my Controller has multiple VLAN (as per different Closets) for the Access Points, are you saying it's best practice to dump all traffic under that same VLAN per Closet?

For example, we have 2 Closets with VLANs 10 and 20.

I have APs assigned an IP Address on either of the VLANs as per the Closet. Are you saying that the GRE Tunnel built from the AP to the Controller on VLAN 10 will pass all Traffic through that Tunnel and VLAN?

1. In case of AP , AP should be connected to the access port not on tunnel port. 

2. The wireless traffic of clients let say on vlan 20, will be tunneled to AP vlan which is on vlan 10 and sent to the controller using the access ports on vlan 10.

so closet just can have AP vlan not the user vlan, since all the traffic is tunneled to single vlan.  

---

@vkumaar wrote:

1. In case of AP , AP should be connected to the access port not on tunnel port. 

2. The wireless traffic of clients let say on vlan 20, will be tunneled to AP vlan which is on vlan 10 and sent to the controller using the access ports on vlan 10.

 

so closet just can have AP vlan not the user vlan, since all the traffic is tunneled to single vlan.  

 

 

---

Interesting. So this VLAN 20 is only configured on the Controller. Correct?

The IP Address assigned to the User Laptop will be issued by who? The Core DHCP Server? That VLAN 20 doesn't it need to be seen somewhere on the Wired Network. Even the Core Switch and not neccessarily on the Closets?

If they need to access the Internet or Servers on the Corporate Network, shouldn't the Core Switch know about this VLAN and have an IP Address existing on the VLAN?

Sorry for the too many questions!

The Answers are inline.

Interesting. So this VLAN 20 is only configured on the Controller. Correct?  

                      yes.

The IP Address assigned to the User Laptop will be issued by who?  DHCP server on teh controller side or the controller

The Core DHCP Server? If the  code DHCP is provide ip address to vlan 20 in the controller.

That VLAN 20 doesn't it need to be seen somewhere on the Wired Network. Even the Core Switch and not neccessarily on the Closets?

No. the reason is all the traffic is tunneled to the controller on AP's VLAN.

If they need to access the Internet or Servers on the Corporate Network, shouldn't the Core Switch know about this VLAN and have an IP Address existing on the VLAN?

SInce the traffic is tunneled they will get IP from the VLAN 20  through the tunnel from controler side. No need for the core switch to know abt this vlan. 

Sorry for the too many questions!

Very good! I understand.

Now, what is best practice? For a Customer that has multiple Closets? Does it matter if I have different VLANs for Tunneled Node for their respective Closets? Or one Flat VLAN is okay? I would assume multiple right? Or depending on the Subnet Mask for the VLAN?

What is best practice?

Secondly, if I have 2 Controllers in a Master/Standby Deployment. I would assume that we need 3 IP Addresses per Tunneled Node VLAN?

Active Mobility Controller

Standby Mobility Controller 

VRRP Mobility Controller (Virtual)

Is that accurate?

Can someone kindly respond to my last question?

Its Best practice to reduce the bradcast domain, so having different vlan to differetn campus should be good. 

Regarding the controller IPs. You can point the tunneled-nodes to the VRRP address. You don't need to point them to the individual controllers.

Thanks guys!

---

@vkumaar wrote:

Its Best practice to reduce the bradcast domain, so having different vlan to differetn campus should be good. 

 

---

Hi Guys,

I was just thinking out loud here and I have a concern about the above statement.

Can we really build multiple VLANs for the Tunneled Node Users???? Isn't the Tunneled Node Configuration associated to the "aaa authentication wired" profile? And I believe you can only have one "aaa authentication wired" profile utilizing 802.1x feature. So I don't see how multiple Tunneled Node VLANs would work.

The more I think about this, I get so confused!  :)

Hi,

A AAA profile configures the authentication settings, not the VLANs. Therefore via Dot1x for example you could have your Radius server passback a different VLAN for different classes of customers. Alternatively, you can have the Radius server pass back a user-role name and locally on the controller, that user-role would have a vlan specified.

Best regards,

Madani

---

@madjali wrote:

Hi,

A AAA profile configures the authentication settings, not the VLANs. Therefore via Dot1x for example you could have your Radius server passback a different VLAN for different classes of customers. Alternatively, you can have the Radius server pass back a user-role name and locally on the controller, that user-role would have a vlan specified.

 

Best regards,

 

Madani

---

Hi Madani,

You just made my point. Imagine a University and this is for Students. So getting a Class attribute of "IT" and assigning them a VLAN. You can't create another VLAN for the same received attribute. You see my point?

So if this AAA Profile is tailored for only one Role, "IT", you can't have multiple VLANs assigned to the same Role unless you are building the RADIUS server configuration on MAS Switch on different Closets.

But with Tunneled Node, where you are performing centralized security, you don't have that option.

Right?

Sorry, I'm not following "So getting a Class attribute of "IT" and assigning them a VLAN. You can't create another VLAN for the same received attribute." If all users have the same attributes, then you're right that it isn't possible to differentiate the users. However you could use a vlan-pool with the user-role to distribute the users across different vlans to break up the broadcast domain.

I'm also not clear what you mean by the AAA profile is tailored for only one Role. If you are just configuring a single UDR/SDR or default authentication role then yes, you are limited to one role but otherwise there are many ways to assign different users to different roles.

Best regards,

Madani

Hi Madani,

I'm sorry. I keep using the wrong terminolgy for the different scenarios.

But we are both saying the same thing.

So we can assign different VLANs for the same User-Role to break up the broadcast domain. I only knew about doing that when configuring the Server Derivation Policy on each MAS Closet with it's respective Access VLAN configuration.

I have to look into this VLAN-Pool recommendation. Is there somewhere I can reference the VLAN-Pool configuration as it relates to User-Roles?

Here is an example I just ran a quick test against.

!
user-role STUDENT-ROLE
 vlan STUDENT-VPOOL
 access-list session allowall
!
vlan 100
vlan 101
!
vlan-name STUDENT-VPOOL
vlan STUDENT-VPOOL 100-101
!

---

@madjali wrote:

Here is an example I just ran a quick test against.

 

!
user-role STUDENT-ROLE
 vlan STUDENT-VPOOL
 access-list session allowall
!
vlan 100
vlan 101
!
vlan-name STUDENT-VPOOL
vlan STUDENT-VPOOL 100-101
!

---

Fantastic!!! Thx a lot.

The last question I have is, how does the Controller distribute the VLANs? Is there an algorithm it uses to distribute the VLANs?

And correct me if I'm wrong, with the VLAN-Pool, a Closet could have Users with different IP Addresses?

That was my reason behind asking how the VLANs are being distributed.

Under the "vlan-name <name>" command, there is an "assignment" knob and you can choose either even or hash. The hash knob means that VLAN assignment is based on the station MAC address. The "even" knob will distribute the users evenly across the vlans.

Best regards,

Madani

And yes users in a given closet could have different IP address ranges.

Thx Madani.

Really appreciate this.

user-role Student
vlan Tunnel-Node
access-list session allowall

vlan-name Tunnel-Node assignment even
vlan Tunnel-Node 200,300

aaa server-group "Trent-RADIUS"
allow-fail-through
auth-server Internal
auth-server RADIUS
!
aaa profile "Campus-WLAN-aaa_prof"
authentication-dot1x "Trent-dot1x"
dot1x-default-role "Student"
dot1x-server-group "Trent-RADIUS"

Please note that my MAS Switch of which the PC is connected to is acting as the DHCP Server on both VLANs (200 and 300).

So if you remove "vlan Tunnel-Node" from "user-role Student" then you see devices in your user-table being assigned "Student"? I'm trying to visualize the connection between the two. If you're passing authentication then the role should just be assigned. Alternatively, if you put "vlan 200", does that still work?

Being stuck in the initial role would indicate a AAA failure. What does the "show auth-tracebuf" show during the authentication process? We may also want to turn on some user-debugs to see what's going on.

If I remove the VLAN Pool from the User Role, the Client doesn't get assigned an IP Address and I believe the Student role is still assigned to it.

The "logon" role assigned is to the MAS Switch.

Can you assist? Even TAC can't seem to figure it out. 

I'll have to set this up. I have enough of your config to emulate it I believe.

Regarding your other questions, If "tunneled-node-profile" is on the interface, "no trusted port" is ignored. The vlan in the switching profile on the other hand is used as the base VLAN prior to re-assignment at the controller. I haven't seen it be an issue in the past.

What's your case number by the way?

Thx for looking into this.

Will still be taking a crack at it. So if you need me to test anything at any time, do let me know.

Case #1445711 is the Ticket Number

This is exactly what I see:

(ArubaControllerA-7240) #show user-table

Users
-----
IP MAC Name Role Age(d:h:m) Auth VPN link AP name Roaming Essid/Bssid/Phy Profile Forward mode Type Host Name
---------- ------------ ------ ---- ---------- ---- -------- ------- ------- --------------- ------- ------------ ---- ---------
172.30.0.253 10:dd:b1:d5:6b:46 student1 Student 00:00:00 802.1x-Wired tunnel 12 Wired 172.20.0.1:gigabitethernet0/0/0/00:1a:1e:19:09:00 Campus-WLAN-aaa_prof tunnel Erics-MacBook-Pro
172.20.0.1 00:1a:1e:19:09:00 logon 00:00:00 tunnel 1 Wired Campus-WLAN-aaa_prof tunnel

User Entries: 2/2
Curr/**bleep** Alloc:2/59 Free:2/57 Dyn:4 AllocErr:0 FreeErr:0

(ArubaControllerA-7240) #

The 1st highlighted IP Address is my MacBook and it's still holding on to the default IP Address it got assigned to on the Management VLAN.

The 2nd highlighted IP Address is the VLAN Interface on VLAN 200 and it's the MAS Switch.

Can you do "show user-table verbose", that will show the VLAN assignment. When dot1x authenticated, that should have caused your Macbook to restart its network interface and as such re-dhcp. Can you change your default switching profile to a non-valid VLAN. What I mean is a VLAN that doesn't have a valid DHCP server on it?

I'm puzzled by the fact that you're seeing the management IP address of the switch as a wired user. That would indicate some type of loop.

Since this is a 7240, I assume 6.2 or 6.3 code?

Yep 6.3 code.

And I agree, seeing the MAS as a Wired User on the Controller was weird to me as well. But I can assure you there isn't any loop.

What if the Controller is just showing it as a registered Node Client? And that's why it comes up on the user-table.

As regards to my MAC, immediately I plug it in, I see it assigned the 172.30.0.253 IP Address, But after a few seconds, it bounces and then get the Default 169.X.X.X IP Address. It doesn't get assigned a valid DHCP.

But on the Controller, it shows me the 172.30.0.253 IP Address.

I will assign the Tunneled Node Port a VLAN that has no DHCP Server associated with it and let you know.

The user-table should never be seeing the switch as a client. Is the port on the controller that is connected to the switch set for "untrusted". That could create this situation. That port should be a trusted port.

Regarding the IP of MBP, the user-table will populate an IP based upon the packets it sees from the client. Since it isn't getting a valid IP after the bounce, I think the table is just caching the old IP until it sees packets with a new IP. But it goes back to the issue that the client isn't getting on a VLAN that has a DHCP server.

Still interesting to see the output of "show user-table verbose".

Or is the vlan untrusted?

Checking. Will let you know.

LOL!!!! Unbelievable!!!

My Controller for some reason made the VLANs in the VLAN Pool to be Untrusted VLANs.

The minute I removed them, I got assigned an IP Address!!!!

Awesome! I'm glad you sent over that user-table output, I would have been scratching my head otherwise for awhile.

Thx madjali!!! 

Now, based on the fact that I have a redundancy between my Controllers. I will have to create the same VLAN Pool on the Standby right? How do I then save that config when I can't really save from the Backup Master?

You can save VLANs and VLAN Pools on a on a backup master, just not the wireless-related stuff.

It just might be a long night for me.

Simulated an outage and it failed on the Standby! **bleep** it!!!!!

Is the tunneled-node-profile pointing to the VRRP address?

Yes it is. I think it's the same issue with the VLANs being untrusted.

However, when I go into the Standby to make that change. It doesn't apply it for some reason.

And I also noticed that the GUI Form for the Port Channel on both Controllers are different.....Strange!

Hmm, I'll have to ping my Controller buddies on that one.

Not good at all. 

Just brought back the Primary Master online. My laptop then go removed form the User-Table of the Old Primary Master. 

And was in limbo until I bounced the port again!!!

Will making the Tunneled Node Profile have the Controller A and Controller B (as backup) IP Addresses make any difference?

We need to see the "show auth-tracebuf" output after the swap. I suspect the client is not responding to the new EAP id request or the controller isn't sending it.

Using backup controller IP won't help and it was really designed for applications where the controllers were on different L3 segments. Same backend tunnel creation and tear-down would occur as VRPP.

I think it does come back. It just takes awhile.

Let me try simulating the outage again and see how long it takes.

It seems to work.

It just takes about 3minutes or so.

Will test again tomorrow. Thx for assisting with this madjali!

Okay so I rebooted the Controller and that resolved the GUI issue and I have applied the VLAN pool to be trusted.

However, my assumption was that if the Primary Master dies, the Clients should automatically switch to the Standby Master.

It is not doing that. However, I had to bounce the port for my Laptop to associate to the new Primary Master.

What do we make of that?

My response was to your previous previous message.

If the primary master dies, we tear down the GRE tunnel and re-establish to the backup. Since there are no valid users on the backup, that should generate new auth requests. What was the user-table state of the backup before you bounced your port?

Hi Guys,

Was just testing out the Tunneled Node Configuration using VLAN Pool assigned to the User Role and it doesn't work.

For some reason, under the "user-table" of the Controller, I only see the MAS assigned a "logon" role which is my "initial-role" for the AAA Wired Profile.

However, if I don't assign a VLAN to the User Role, it works just fine.

Any ideas?

Can you send me the latest relevent AAA sections from the controller? Let me take a look.

One more thing I need to point out.

The Tunneled Node Port was assigned a Switching Profile which assigns it the Management VLAN and also configures it as an "access mode" Port and to be Untrusted.

However, my assumption is that the VLAN assigned by the User Role should take precedence. Right?