Hi,
Is there a possibility that a WAP can share an authenticated MAC address with another WAP?
Thanks,
Solved! Go to solution.
The process of roaming, i.e. a client moving from one AP (BSS) to another AP (BSS) within the ESS, is also called BSS Transition. In general (i.e., without any optimization), a BSS transition comprises the following steps:
The 802.1x EAP process generally takes much longer than the 4-way handshake (in one trace, for example, the EAP process took around 90 ms and the 4-way handshake took around 30 ms). Many of the mechanisms that reduce roaming times, therefore, do so by skipping the 802.1x EAP authentication step.
The subsequent sections describe methods that speed up or eliminate one or more of the steps outlined above.
Arista APs support 802.11k and 802.11v. The IEEE 802.11k amendment, also called Radio Resource Measurement (RRM), defines methods allowing stations to inform each other about their respective radio frequency (RF) environments. That way, they can make faster and better informed decisions on roaming. With 802.11k, a client can request an AP to send a Neighbor Report. This reduces the number of channels a client has to scan (thereby optimizing step 1 in the roaming process).
The IEEE 802.11v amendment is also called Wireless Network Management (WNM). As the name suggests, 802.11v has a broader scope than 802.11k. While 802.11k defines methods that help individual stations understand their radio environment, 802.11v defines services that help improve overall network performance. An important 802.11v service is BSS Transition Management (BSTM). When an AP decides to disassociate with a client (because the AP knows that a neighboring AP can better serve the client), it sends an 802.11v frame called a BSTM Request, warning the client of its intention to disassociate. This allows a client some time to find a better AP and associate with it.
Arista APs use PMK (Pairwise Master Key) caching. With PMK caching, an AP caches the PMK ID used by the client and the AP during their association. Consider a client that roams from AP1 to AP2, and now returns (roams back) to AP1. If the client also caches PMKIDs, it sends an association request containing the PMKIDs it has recently used. Since AP1 also has the cached PMKID from their earlier association, the client and the AP skip the 802.1x EAP authentication and start the 4-way handshake (thereby eliminating step 4 from the general process). A limitation of PMK caching is that it does not speed up roaming when a client roams to an AP for the first time.
Enterprise networks typically use 802.1x RADIUS-based authentication. As mentioned in the general steps, in the absence of any optimization, a client needs to undergo the entire 802.1x EAP process every time it roams.
In 802.1x EAP authentication, the PMK is derived from the Master Session Key (MSK). OKC can be thought of as a network-wide, 802.1x version of PMK caching. With OKC, the Wi-Fi network caches the PMK for a client as long as the client is associated with the network. So when a client roams, the client and the target AP skip the 802.1x EAP authentication (eliminating step 4 from the general process) and start the 4-way handshake.
Preauthentication is when a client initiates authentication and establishes a PMK Security Association (SA) with the target AP while the client is still associated with the current AP. The client does this via the current AP over the wired network. When preauthentication completes, the client and the target AP both have a PMK SA, i.e., they have a PMK cached for their future association. So when a client roams, the client and the target AP skip the 802.1x EAP authentication (eliminating step 4 from the general process) and start the 4-way handshake.
A drawback of preauthentication is that it does not scale well; all clients need to establish PMK SAs with all possible APs they could roam to, greatly increasing network traffic. The 802.11r standard solves this problem.
802.11r or Fast BSS Transition speeds up roaming in two ways:
Is there a reason? Also why not authenticate both MACs for the WAPs? Again, only asking because not sure what you're trying to accomplish.
Hi,
Thanks for taking your time on answering my question. I was just wondering if there are any ways for users to get a 1 time authentication and roam freely without another authentication when transferring to another AP.
Thanks
What do you want to achieve?
Client Tracking
Each AP keeps track of all its connected wireless clients. This includes the client's network access information such as VLAN and group policy (either from Dashboard or RADIUS). During a roam, this information is shared with other APs in the network so the client can maintain their level of access.
Client tracking information is shared with Access Points via broadcast messages, so ensure that port isolation and private VLAN features are not enabled upstream in a configuration that can block broadcasts between APs.
https://documentation.meraki.com/MR/Wi-Fi_Basics_and_Best_Practices/Roaming_Technologies
Hi,
Thanks for taking your time for this. What i am trying to achieve is having a seamless experience for user when roaming. As i understand it when a user roams the user needs to have another authentication process when connecting to another AP. I was just wondering if there are any ways for users to get a 1 time authentication and roam freely without another authentication when transferring to another AP.
If you configure a wireless network with e.g. WPA2-PSK, each client will have to enter a pre-shared key (PSK) and they will be able to authenticate with the Access Point on that SSID. For all Access Points in the same Meraki network, the client will roam freely between the Access Points.
We have active RADIUS server for our encryption.
Then configure it for Enterprise security, instead of Personal/Password.
The rest is done on your RADIUS server.
I don't think you need to worry about this, in corporate solutions like Meraki it's something transparent for the user.
The process of roaming, i.e. a client moving from one AP (BSS) to another AP (BSS) within the ESS, is also called BSS Transition. In general (i.e., without any optimization), a BSS transition comprises the following steps:
The 802.1x EAP process generally takes much longer than the 4-way handshake (in one trace, for example, the EAP process took around 90 ms and the 4-way handshake took around 30 ms). Many of the mechanisms that reduce roaming times, therefore, do so by skipping the 802.1x EAP authentication step.
The subsequent sections describe methods that speed up or eliminate one or more of the steps outlined above.
Arista APs support 802.11k and 802.11v. The IEEE 802.11k amendment, also called Radio Resource Measurement (RRM), defines methods allowing stations to inform each other about their respective radio frequency (RF) environments. That way, they can make faster and better informed decisions on roaming. With 802.11k, a client can request an AP to send a Neighbor Report. This reduces the number of channels a client has to scan (thereby optimizing step 1 in the roaming process).
The IEEE 802.11v amendment is also called Wireless Network Management (WNM). As the name suggests, 802.11v has a broader scope than 802.11k. While 802.11k defines methods that help individual stations understand their radio environment, 802.11v defines services that help improve overall network performance. An important 802.11v service is BSS Transition Management (BSTM). When an AP decides to disassociate with a client (because the AP knows that a neighboring AP can better serve the client), it sends an 802.11v frame called a BSTM Request, warning the client of its intention to disassociate. This allows a client some time to find a better AP and associate with it.
Arista APs use PMK (Pairwise Master Key) caching. With PMK caching, an AP caches the PMK ID used by the client and the AP during their association. Consider a client that roams from AP1 to AP2, and now returns (roams back) to AP1. If the client also caches PMKIDs, it sends an association request containing the PMKIDs it has recently used. Since AP1 also has the cached PMKID from their earlier association, the client and the AP skip the 802.1x EAP authentication and start the 4-way handshake (thereby eliminating step 4 from the general process). A limitation of PMK caching is that it does not speed up roaming when a client roams to an AP for the first time.
Enterprise networks typically use 802.1x RADIUS-based authentication. As mentioned in the general steps, in the absence of any optimization, a client needs to undergo the entire 802.1x EAP process every time it roams.
In 802.1x EAP authentication, the PMK is derived from the Master Session Key (MSK). OKC can be thought of as a network-wide, 802.1x version of PMK caching. With OKC, the Wi-Fi network caches the PMK for a client as long as the client is associated with the network. So when a client roams, the client and the target AP skip the 802.1x EAP authentication (eliminating step 4 from the general process) and start the 4-way handshake.
Preauthentication is when a client initiates authentication and establishes a PMK Security Association (SA) with the target AP while the client is still associated with the current AP. The client does this via the current AP over the wired network. When preauthentication completes, the client and the target AP both have a PMK SA, i.e., they have a PMK cached for their future association. So when a client roams, the client and the target AP skip the 802.1x EAP authentication (eliminating step 4 from the general process) and start the 4-way handshake.
A drawback of preauthentication is that it does not scale well; all clients need to establish PMK SAs with all possible APs they could roam to, greatly increasing network traffic. The 802.11r standard solves this problem.
802.11r or Fast BSS Transition speeds up roaming in two ways:
Thank you so much for this information and for you patience. I am new to Cisco Meraki so forgive me if i confused you.
should i enable Layer 3 Roaming for a more seamless wireless connection?
No, don't enable Layer 3 Roaming.
For 90% of Meraki installations, it's ok to just bridge clients onto a vlan.