Wireless Access

last person joined: 18 hours ago 

Access network design for branch, remote, outdoor and campus locations with Aruba access points, and mobility controllers.
Expand all | Collapse all

Roaming on Remote APs

Jump to Best Answer
  • 1.  Roaming on Remote APs

    Posted May 24, 2014 09:46 AM

    how good or bad is roaming between remote APS?

    Let say i got 3 APS on a remote Site, and roaming between them its needed.

    Those  APS will be on RAP mode and  will have one  ssid on bridge mode and he other one on split tunnel.

     

    Anyone have an idea?

     

    Cheers

    Carlos

     

     



  • 2.  RE: Roaming on Remote APs

    Posted May 25, 2014 04:45 AM

    I believe roaming between RAPs is fine, but you should note the following with respect to band steering taken from the cli guide,

     

    Note, however, that if a campus or remote APs has virtual AP profiles configured in bridge or split-tunnel forwarding mode but no virtual AP in tunnel mode, those APs will gather information about 5G-capable clients independently and will not exchange this information with other APs that also have bridge or split-tunnel virtual APs only.

     

    It's not clear whether this impacts roaming as well.



  • 3.  RE: Roaming on Remote APs

    Posted May 25, 2014 05:23 AM

    If im using client match how is this affected on raps with rap bridge and rap split tunneling vaps?

     

     

    Cheers

    Carlos



  • 4.  RE: Roaming on Remote APs
    Best Answer

    Posted May 25, 2014 08:00 AM

    @NightShade1 wrote:

    how good or bad is roaming between remote APS?

    Let say i got 3 APS on a remote Site, and roaming between them its needed.

    Those  APS will be on RAP mode and  will have one  ssid on bridge mode and he other one on split tunnel.

     

    Anyone have an idea?

     

    Cheers

    Carlos

     

     


    Roaming works on bridged SSIDs.  Roaming does not work on split-tunneled SSIDs.  You should use an instant cluster for a split-tunneled setup.  Do not deploy more than one split tunneled AP at a site; use instant instead.

     

    Clientmatch will work on a bridged SSID.



  • 5.  RE: Roaming on Remote APs

    Posted May 25, 2014 10:32 AM

    Okay

    So it will work on bride mode even if the ap is on RAP mode right??

    If this true i bealive that if i put always on on the SSID and when he is not reporting to the WC for some reason in that particualr momment the roaming will not work until it see it again right???

     

    The other question

    The client match on bridge mode on rap mode is as good as the one that is on tunnel mode? or they are not?

     

     

    Also t, The split tunneling here  will be for  guest access so the roaming i dont think it will be THAT important... guest just access the wifi on conference room and stay there.

     

    The requirement he has is that the internet traffic must go out to the internet locally in each site... thats why i need split tunnel on captive portal.

     

    For now they do not want to invest in more equipment so the instant option or anything that involve bying is out of the table... they had one controller and one ap per site, now they are changing this for the controller they got alrady and 3 aPS per site or something like that.

     

     

     

     



  • 6.  RE: Roaming on Remote APs

    Posted May 25, 2014 10:41 AM

    Roaming works in Bridged mode, period.  Clientmatch works in bridged mode period.  If the AP is not reporting to the WC, the client will make its own decisions about roaming without Clientmatch.



  • 7.  RE: Roaming on Remote APs

    Posted May 26, 2014 10:06 AM

    So there is no roaming on split tunneling neither the normal client roaming without the help of the controller???

     

    Cheers

    Carlos



  • 8.  RE: Roaming on Remote APs
    Best Answer

    Posted May 26, 2014 11:18 AM

    When you do a split tunnel, the client's firewall state is contained within the access point.  When that client roams, there is no expectation that the firewall state is transferred to the next access point, because there is no expectation of roaming on  a split tunneled SSID.  If the client roams, the firewall state is forgotten making for a poor experience.  It has always been this way, because the expectation is that a split-tunneled SSID is one at a remote site with a single access point.  That is just about the client firewall state.

     

    wifi clients have always roamed and will continue to roam like they always have.  When the access point is not connected to the controller, clientmatch cannot assist the clients in roaming, so clients will have their default roaming behavior.