Wireless Access

last person joined: 14 hours ago 

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

Multiple Mesh Clusters Deployment

This thread has been viewed 6 times
  • 1.  Multiple Mesh Clusters Deployment

    Posted Jun 24, 2016 05:51 AM

    Hello Dears,

     

    If I have many outdoor AP's (IAP 275), and the 5 GHz Signal overlaps between them, can I isolate them into separate Clusters (3 ~ 5 AP's each)? Meaning I can select manually which AP will exactly belong to which Cluster?

     

    Like below, assume Red Dots are the Mesh Portals, and the Blue Dots are the Mesh Clients, each cluster will be Wirelessly Backhauled with 5 GHz, and then will aggregate the Mesh Portals traffic to an aggregation switch.

     

    WiFi Backhauling.png



  • 2.  RE: Multiple Mesh Clusters Deployment

    EMPLOYEE
    Posted Jun 24, 2016 07:54 AM

    You cannot with IAP mesh currently. The only way to accomplish that is to separate the two clusters into separate L2 networks, essentially creating two separate IAP clusters. if you are using Central or AirWave, you can still manage both clusters under the same management, but if not, you just have to manage the two clusters separately to maintain separation of the mesh.



  • 3.  RE: Multiple Mesh Clusters Deployment

    Posted Jun 24, 2016 09:51 AM

    Thanks a lot jhoward, I have some queries here please:

     

    > Do you mean to assign a seperate VLAN per Cluster?

    > If we're connected to MC 7200, will it be the same issue?

    > We have ~ 90 IAP's, with almost 40 Mbps per AP, do you see it's feasibile to maintain ( 3 ~ 5 ) AP's per cluster?

     

     



  • 4.  RE: Multiple Mesh Clusters Deployment
    Best Answer

    EMPLOYEE
    Posted Jun 25, 2016 12:33 AM

    yes, separate VLAN per cluster (or cluster per VLAN, however you want to look at it).

    if you are terminating APs against a controller (no longer IAPs), then you do not have that limitation

    whether that is feasible or not is dependent on what you require to be carried over the mesh links. Just remember that PtMP mesh where 5Ghz is backhauled is dependent on topology (hop and children count), as well as distance between each of the nodes.



  • 5.  RE: Multiple Mesh Clusters Deployment

    Posted Jul 12, 2016 11:24 AM

    Hello,

     

    In case AP will conenct to a controller (MC 7200), can we select "Specifically" from the controller a group of controlled AP's to be inside Mesh Cluster?

     

    What are the requirements for this?

     

    Thanks.



  • 6.  RE: Multiple Mesh Clusters Deployment

    EMPLOYEE
    Posted Jul 12, 2016 11:35 AM

    With a controller-based mesh solution, you create specific AP groups to be defined with unique mesh cluster configurations (mesh cluster IDs basically), then you provision those APs into their respective groups. From there, the rest of the configs can be shared.



  • 7.  RE: Multiple Mesh Clusters Deployment

    Posted Jul 12, 2016 11:52 AM

    But in this case, the controller will assign automatically any "Wired" AP to be the Mesh Portal?

     

    Do I have to configure any VLAN's or DHCP Server with dedicated IP Pool per cluster on the controller?

     

    Thanks.



  • 8.  RE: Multiple Mesh Clusters Deployment
    Best Answer

    EMPLOYEE
    Posted Jul 12, 2016 12:03 PM

    No you will need to designate both mesh portals on the wire as well as mesh points. All Aruba APs MUST be brought up on the wire first to get their initial configuration. For example, if you have one portal and three mesh points (say all AP-275s), you will bring ALL the new AP-275s up on the wire first. Once they are all up they will show up with the mac address in the 'AP Installation' page.

     

    First - create your AP group that will have the mesh profile configured, then put whatever SSIDs you want in there, and configure whatever wired profiles you will need (access VLAN whatever, or trunk VLAN whatever) applied to ENET0 or ENET1 (whichever one you are using, usually ENET0).

    Second - You will designate which will be the portal and which will be the points, and when provisioning them at the bottom of the page, you will name and make the portal a 'portal' from the dropdown, and same for the points designating them the points. 

    Third - When you see all the Aps reboot, it's best practice to test and make sure they all come up. What you need to be careful to do here is make sure the points are NOT connected to the wired network where the portal is or you can have a loop. So what I do is usually change the switch ports the mesh points are in to a non-connected VLAN or will enable POE but disable L2 so they cannot talk over the wire. You can also move them all over to power injectors, or if they were already on power injectors, just unplug the wired uplink of the POE injector.

    Fourth - you should see the portal come up first, then the mesh points shortly after such that all four APs are up.

     

    The user guide has some great instructions on this. Mesh points will get their IP address from the native VLAN of the mesh portal. So in tunnel mode, from the uplink port's perspective, it will see the portal MAC address as well as any mesh point's MAC address, so in our example there will be four mac addresses on that switch port. 

     

    The VLANs you need to carry (in case you are doing wired backhaul) in tunnel mode (where all wired traffic is GRE encapped and sent to the controller) would be configured on the controller, has L2 continuity to the controller's uplink to the core network, and os enabled in the wired AP profile. if you are doing bridge-mode, where the wired backhaul traffic egresses and ingresses at the mesh portal, you have to make sure those L2 VLAns are configured on the mesh portal's uplink and that there is L2 continuity from that switch port's uplink to the core.



  • 9.  RE: Multiple Mesh Clusters Deployment

    Posted Jul 12, 2016 12:26 PM

    Many thanks, I just have 2 queries:

     

    1) If not all AP's can be wired (Because of no wired backhaul available on site), is there any way to setup this on site? Or they must be staged locally to controller first, and then moved to site?

     

    2) When you mentioned "Mesh points will get their IP address from the native VLAN of the mesh portal", you mean the DHCP server of the site router is the one that will assign these IP's to the portals, right?

     

    In case required, can we assign these IP's Statically?



  • 10.  RE: Multiple Mesh Clusters Deployment

    EMPLOYEE
    Posted Jul 12, 2016 12:31 PM

    For controller-based mesh they must be provisioned on the controller fist and then hung. There is no way to provision them from the console.

     

    Wherever the portal gets it's IP address, is where the points will get their IPs. You can statically configure yes, as part of the AP provisining process.



  • 11.  RE: Multiple Mesh Clusters Deployment

    Posted Jul 14, 2016 07:43 AM

    I have a query please, is it possible to have more than 1 Mesh Portal AP (Wired AP), in the same Mesh Cluster?

     

    I think this is not possible, even if all AP's are in the controller-mode, reason is to prevent looping, but want to confirm.

     

    Thanks.



  • 12.  RE: Multiple Mesh Clusters Deployment

    EMPLOYEE
    Posted Jul 14, 2016 08:02 AM

    Multiple portals are fine, it's multiple mesh points on the same L2 associated to the same portals on the same VLANs that are the issue. Think of mesh portals as ports on a switch, you can have as many portals in the same cluster that you want. Each mesh point is ALSO a switch on the other side. When you build a mesh link between a portal and point, you are connecting the two sides (the two sides of the same L2 network) with an ethernet cable. If you stand up TWO points on the same L2 switch, you have two paths now and you have a loop. 

     

    If you have two portals and one mesh point, there is still only one path (the mesh point will only associated with one portal at a time).