Wireless Access

Hi All,

This thread is for those who are attending RF training webinar conducted by TAC for Customers and Partners of different regions.

Since the number of registered participants is high, we wont be able to answer your questions in the session. Unmuting will also cause voice quality problems.

So please post your questions in this thread and we will answer all your questions shortly.

You can find the presentations in the below link.

http://www.slideshare.net/dhanraj_puduchery/wireless-fundamentals-49411271

Thanks,

Venu Dhanraj

Aruba Networks

(ACMP, CWNA, CCNP )

My self and another colleague did not receive the invitation. It does say that it will be available on afp.arubanetworks.com, this address times out. Any help?

Edit: I believe this is the second time an invitation has not been sent after registering

Hi All, Has the link to the recording been issued as of yet? I have told a number of colleagues about the presentation and they are keen to watch it. Thanks Gordie

HI Friend,

It should have shared already by this time. please contact Cristina on this.

HI,

Here is link to access the Video,

https://arubapedia.arubanetworks.com/arubapedia/index.php/Pinnacle:_Technical_Climb#Europe.2C_Middle_East.2C_Africa

Hi friend,

It is accessible for Partners.

 please check with Cristina on this.

I am a partner but it is denying access to me also.

How much resources does ClientMatch use on instant APs (lets say a moderately loaded Aruba 205AP) in a network? Does it reduce performance in some ways?

Thanks,
Rasmus

Q : How much resources does ClientMatch use on instant APs (lets say a moderately loaded Aruba 205AP) in a network? Does it reduce performance in some ways?

A : It will not effect the performance, the algorithm will takecare of that.

Q1: what will happen if clientmatch let one client from one RAP to another RAP in slpittunnel mode, means clientmatch can support RAP split-tunnel mode, or split-tunnel roaming?

in different forwarding mode, what we should consider the realationship between L2/L3 roaming and Clientmatch?

A : Client match is no where concern to Roaming, Roaming is something which is Client initiative but CM is Controller initiative Stearing. Stearing and Roaming are two different.

Q2: clientmatch will has GUI configuration IN THE FURTURE?

A : Yes. we can expect this soon.

Q3: in AOS 6.4 CM won't support 802.11n AP, so if we disable CM ,means no LB and band-steering function. right? 

A : No. We support CM in 6.4 with 802.11 n

Q : Client Match Can Help old client or is better don't use it ?

A : As long as a client can send a probe request, client match can determine the suitable AP for that client.

Q1: what will happen if clientmatch let one client from one RAP to another RAP in slpittunnel mode, means clientmatch can support RAP split-tunnel mode, or split-tunnel roaming?

in different forwarding mode, what we should consider the realationship between L2/L3 roaming and Clientmatch?

Q2: clientmatch will has GUI configuration IN THE FURTURE?

Q3:in AOS 6.4 CM won't support 802.11n AP, so if we disable CM ,means no LB and band-steering function. right? 

Q : I understand that the AP collects the information (SNR, channel utilization,..) from the AP to make the decision to steer the client... so it's an AP decision and not a controller one right? also , what if the association of the client to the new AP fails? and it's able to associate to the initial AP but the steering process repeats again? (leaving the client unassociated)

A : No. Always decision made by the Controller, controller will handle the stearing logic. Controller first finds a suitable AP before streang hence Client should be able to move to the new AP with out any issue.

Q : In terms of troublshooting, what are the main reasons of PHY/MAC error and how can ve ab¡void?

A : Main reasons for PHY/MAC errors would be poor SNR and reasons for poor SNR would be either the client is far away from the AP or due to interference or may be due to noise in the channel.

Q : We saw in different cases that bandsteering implemented in ARM is working better then in clientmatch, how can this be explained? 

A : Here perceptions are different, ARM will do band steering for creating space for only b/g capable clients and where as CM will do band steering to avoid poor SNR. in the case of ARM steering is smooth because criteria is simple compared to CM.

Q : Can we have session for outdoor deployment scinario and best practive for mesh links .

A : Sure we will consider your request and come out with a training plan.

Q : Regarding ARM assignmnet - shall we choose single band or multiband

A : We can enable for Single or Dual band on each radio. Option is available in ARM profile mapped to a radio.

For your ref :

Q : At dense deployment for conferrence halls with 1000 user and 15 AP-225 ( overhead design or side coverage ) can we use Instant or it would be hard to handle the high and fast roaming of all theses cleints 

A : Both Campus AP and IAP deployment can justify this requirement. if the requirement is providing wireless for only conference hall we recommend IAP or if your requirement is big ( more than 100 APs) then go with Controller based deployment. always be in touch with your SE for seeking suggestions on deployment.

Q : Client match and ARM can be activated simultaneously or are they mutrual exclusive?

A : Client Match is a feature of ARM, if ARM is disabled CM will be disabled CM is depended on ARM.

ClientMatch is independent of ARM.  It will work even with ARM disabled.  Clientmatch depends on ARM scanning to build Virtual Beacon Reports, but outside of that it does not depend on ARM.

---

@cjoseph wrote:

ClientMatch is independent of ARM.  It will work even with ARM disabled.  Clientmatch depends on ARM scanning to build Virtual Beacon Reports, but outside of that it does not depend on ARM.

---

their is a "Scaning: option in ARM profile, not sure when the clientmatch will be disabled in next 3 conditions:

1.disable ARM

2.uncheck scanning option

3.uncheck Clientmatch

thanks

Kzhu

If you just uncheck ClientMatch it will be disabled.

If you uncheck scanning, access points will only be able to discover clients on the channel they are on, making client match less effective if enabled.  Setting ARM to disabled by itself does not do anything to ClientMatch.

great, so clear!

how Clientmatch work in remote-AP environment?

Clientmatch sometimes can be thought as making client roaming mandatory, but we support client roaming in rap split-tunnel, considering firewall transfer.

---

@kzhu wrote:

how Clientmatch work in remote-AP environment?

Clientmatch sometimes can be thought as making client roaming mandatory, but we support client roaming in rap split-tunnel, considering firewall transfer.

 

---

There is no expectation of roaming on a split-tunneled SSID and it is not supported.

ClientMatch also is not active on remote APs.

---

@cjoseph wrote:

---

@kzhu wrote:

how Clientmatch work in remote-AP environment?

Clientmatch sometimes can be thought as making client roaming mandatory, but we support client roaming in rap split-tunnel, considering firewall transfer.

 

---

There is no expectation of roaming on a split-tunneled SSID and it is not supported.

ClientMatch also is not active on remote APs.

 

---

means clientmatch only support CAP? for RAP we use ARM2.0?

---

@kzhu wrote:

---

@cjoseph wrote:

---

@kzhu wrote:

how Clientmatch work in remote-AP environment?

Clientmatch sometimes can be thought as making client roaming mandatory, but we support client roaming in rap split-tunnel, considering firewall transfer.

 

---

There is no expectation of roaming on a split-tunneled SSID and it is not supported.

ClientMatch also is not active on remote APs.

 

---

means clientmatch only support CAP? for RAP we use ARM2.0?

---

Clients have roamed by themselves for many years without ClientMatch.  ClientMatch is typically designed for high density environment.  Most RAPs are a single access point at a remote location, which means no or  very limited opportunities to roam.  The clients should roam just fine on their own.  Even ARM 2.0 would not expected to be turned on in a RAP environment.  802.11ac access points do not support ARM 2.0 anyway...

Q : will there be any experience of connection loss during steering on the clients?

A : If we enable Client aware scanning, AP will never steer the associated client hence there should not be any connection loss.

---

dhanraj_puduchery@yahoo.com wrote:

Q : will there be any experience of connection loss during steering on the clients?

 

A : If we enable Client aware scanning, AP will never steer the associated client hence there should not be any connection loss.

---

you mean associated client or active client? I think should be active client.

dhanraj_puduchery@yahoo.com wrote:

Q : will there be any experience of connection loss during steering on the clients?

 

A : If we enable Client aware scanning, AP will never steer the associated client hence there should not be any connection loss.

---

you mean associated client or active client? I think should be active client.

Yes,

It is all active clients ( those who are Tx or Rx the data).

---

@vdhanraj wrote:

dhanraj_puduchery@yahoo.com wrote:

Q : will there be any experience of connection loss during steering on the clients?

 

A : If we enable Client aware scanning, AP will never steer the associated client hence there should not be any connection loss.

---

you mean associated client or active client? I think should be active client.

 

 

Yes,

 

It is all active clients ( those who are Tx or Rx the data).

---

1.  There is typically not an experience of connection loss during steering.  The client experience is just like if the client roams. 

2.  There is no such thing as client aware scanning;  There is ARM Client Aware where an AP will not change channels if active clients are associated, but it is not related to and has no effect on Client Match. 

Q : Clientmatch will has GUI configuration IN THE FURTURE?

A : Yes we can expect it in future :)

Q : How much reasources does ClientMatch use on instant AP(lets say atuba 205AP) in a network does it reduce performance in some ways?

A : No. ARM or client match will not impact the performance. will consume very low resources.

Q : Band steering works with n clients bettween 2.4 and 5 GHz bands?

A : Yes.

Q : You mentioned the feature "Mode aware" that is available on the controllers. When will this be available in Instant?

A : Sure, we can raise a feature request :)

Q : Once the client is associated with AP, and starts moving around - does it still send beacon requests?

A : Yes. it will send probe request periodically to understand the signal level and capabilities of all the nearby APs.

Q : who is handling this process Master or Local ?

A : Always Master

---

dhanraj_puduchery@yahoo.com wrote:

Q : Regarding ARM assignmnet - shall we choose single band or multiband

 

A : We can enable for Single or Dual band on each radio. Option is available in ARM profile mapped to a radio.

 

For your ref :

---

Single-Band is the default and should b used 99% of the time.  Multi-Band scan is when you have single radio access points and you want them to possibly be assigned to both bands automatically.  http://www.arubanetworks.com/techdocs/ArubaOS_64x_WebHelp/Web_Help_Index.htm#ArubaFrameStyles/ARM/Multi_Band_ARM_and_802_1.htm

http://community.arubanetworks.com/t5/Controller-Based-WLANs/How-does-ARM-multiband-assignment-work-and-how-do-I-configure-it/ta-p/177060

HI dhanraj

we have mesh setup in the sea port we are facing problem while the client is moving from one ap to another AP . when the client near other AP also still it is connectig to the same Ap where it was previously connected .  this is like a tsicky client issue please suggest what settings we need to to