Share MAC Adress to other WAPS.

Charles7
Conversationalist

Share MAC Adress to other WAPS.

Hi,

 

Is there a possibility that a WAP can share an authenticated MAC address with another WAP?

Thanks,

12 Replies 12
kYutobi
Kind of a big deal

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. 

Enthusiast
Charles7
Conversationalist

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

alemabrahao
Kind of a big deal
Kind of a big deal

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

 

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.

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.

LinkedIn ::: https://blog.rhbirkelund.dk/

Like what you see? - Give a Kudo ## Did it answer your question? - Mark it as a Solution 🙂

All code examples are provided as is. Responsibility for Code execution lies solely your own.

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.

LinkedIn ::: https://blog.rhbirkelund.dk/

Like what you see? - Give a Kudo ## Did it answer your question? - Mark it as a Solution 🙂

All code examples are provided as is. Responsibility for Code execution lies solely your own.

I don't think you need to worry about this, in corporate solutions like Meraki it's something transparent for the user.

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.

 

General Roaming Process

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:

  1. The client scans the network for candidate “target” APs (802.11k can help optimize this).
  2. The client and the target AP exchange 802.11 reauthentication messages (the client sends a request and the AP responds).
  3. The client and the target AP exchange 802.11 reassociation messages.
  4. If this is an 802.1x SSID, the client and the target AP cannot yet start communicating; they first need to establish a key. The 802.1x EAP authentication begins with the derivation of a master key.
  5. The 802.11i 4-way handshake is next: the client and the target AP derive their Pairwise Transient Key (PTK)—the unique encryption key for their association, derived from the master key.
 

 

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.

802.11k and 802.11v

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.

PMK Caching

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.

Fast Handoff Support for 802.1x

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. 

 

Opportunistic Key Caching (OKC)

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

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

802.11r or Fast BSS Transition speeds up roaming in two ways:

  • When the SSID uses 802.1x authentication without 802.11r, the client needs to perform EAP authentication every time it roams to a different AP. 802.11r bypasses this step by caching a part of the key derived from the RADIUS server in the wireless network (thereby eliminating step 4 from the general process). This basically builds on the OKC method of caching keys (OKC was a precursor of or a step towards 802.11r). 802.11r specifies a key hierarchy: a first-level key for storage in the RADIUS server (PMK-R0), and a second-level key for storage in APs (PMK-R1), used to derive the PTK for encryption. 
  • Additionally, 802.11r piggybacks the 4-way handshake messages between the client and the target AP onto the reassociation messages (combining steps 3 and 5 in the general process). This piggybacking is done whether the SSID uses 802.1x or WPA2-PSK. 
 

 

 

 

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.

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.

LinkedIn ::: https://blog.rhbirkelund.dk/

Like what you see? - Give a Kudo ## Did it answer your question? - Mark it as a Solution 🙂

All code examples are provided as is. Responsibility for Code execution lies solely your own.
Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels