Wireless Access

last person joined: yesterday 

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

IAP Cluster, Bridging Issue

This thread has been viewed 1 times
  • 1.  IAP Cluster, Bridging Issue

    Posted Jun 02, 2015 11:39 AM

    Hello's

    I have the following setup and running into some issues.

    ENVIRONMENT

    1) IAP cluster running IAP 103's

    2) A non-Aruba wireless device that is connected to the IAP cluster wirelessly

    3) The non-Aruba wireless device has enabled bridging on it's Ethernet port.

    4) A switch is connected to the non-Aruba wireless device Ethernet port

    5) Devices are connected to this switch.

     

    PROBLEM/ISSUE

    1) Devices connected to the switch behind the non-aruba wireless device can access the Internet/Network with no problem.

    2) Devices connected to the IAP wireless SSID, or the internal network cannot initiate a ping or communicate with the the devices on the switch behind the non-Aruba wireless device.

     

    Any ideas on what could be causing this comm breakdown?

    Thanks,

    1m



  • 2.  RE: IAP Cluster, Bridging Issue

    Posted Jun 02, 2015 12:41 PM

    HI Friend,

     

    What role is mapped to that non Aruba device which is connected to the IAP over wireless(SSID).

    I belive policy mapped to the role is the issue.

     

    Please feel free to come back if the issue is solved.



  • 3.  RE: IAP Cluster, Bridging Issue

    Posted Jun 02, 2015 12:57 PM

    Thanks for your response.

    The non-Aruba wireless device is connected to the IAP wireless network as a client. Meaning, In the non-Auba wireless device settings, we've entered the SSID and the key to connect it to the IAP wireless network.

     

    To your point, If the device is connected as a client, should it not be receiving the same role any other wireless client would receive and therefore make your point not accurate to this issue?



  • 4.  RE: IAP Cluster, Bridging Issue

    Posted Jun 02, 2015 01:32 PM

    HI,

     

    Here non Aruba device should be treated as a client and it should be mapped to the same role as other clients but here in this scenario, non Aruba device is not generating the traffic ( if you ping from the non Aruba device it should be able to ping you can try) it has to bridge the traffic from wired port to the wireless, here is the issue.

     

    My point is, is that non Aruba device configured for bridging the traffic ?

    Please try to fix the issue from this issue.

     

    Please feel free for any further help on this.



  • 5.  RE: IAP Cluster, Bridging Issue

    Posted Jun 03, 2015 09:34 AM

    Thanks for your response.

     

    The "non-aruba wireless device/client" that is associated with the IAP cluster is set for transparent bridging. Of this i'm 100% sure. In fact, Intermittently, one of the devices behind the non aruba wireless device can be pinged. But this is intermittent and not consistent. This tells me bridging is enabled.

     

    One other question. When configuring the non-aruba device to be a client of the IAP cluster, I enter the SSID name and key. What is weird is the non-aruba device asks me to select an IAP to associate to. It does not see the cluster as one SSID. Could this be the issue? I'm reaching for straws here :(



  • 6.  RE: IAP Cluster, Bridging Issue

    Posted Jun 03, 2015 09:46 AM

    Hi,

     

    It is really  weird issue. to fix the issue we need to understand how that non Aruba device is working. I advice you to contact TAC to seek quick solution for this.



  • 7.  RE: IAP Cluster, Bridging Issue

    Posted Jun 03, 2015 04:14 PM

    We too have seen the issue of poor connectivity behind a wireless bridge (non-Aruba) connecting to the Aruba (and other) access points.

     

    In our case the bridge was using the SSID to select a BSSID shuch that it essentially "nailed" its connection to the one AP on the one channel and would not roam - you'll have to plan around that when you lay out your access points.

     

    Your problem with only occasional pings is probably due to Aruba's settings to keep broadcasts out of the air. Check the settings on your iAP VC for your SSID and look at the Broadcast Filtering in Advanced Options.



  • 8.  RE: IAP Cluster, Bridging Issue

    Posted Jun 03, 2015 06:30 PM

    Thanks for your reply.

    I specified ping as the method of communication that was failing. However, the application behind the bridge uses several protocols and this application is intermittently available on those protocols which leads me to think that perhaps the Broadcasting filtering modification you recommended is not the issue. 

    I'm now leaning towards using an aruba IAP to replace the non-aruba wireless device. The plan is to use the aruba IAP as a mesh point and have it provide brdiging services instead. Hopefully this works better.

     

    Thanks all for your time,



  • 9.  RE: IAP Cluster, Bridging Issue

    Posted Jun 03, 2015 06:43 PM

    Actually that other protocols are broken too makes me more certain of the broadcast issue.

    I agree that an Aruba bridge will probably work better though.

     

    At layer-2, the device on the far side of your bridge makes an ARP packet to tell the switch where it is, the devices which needs to know are the iAP and the upstream switch behind that iAP. Depending on how your bridge device handles that ARP broadcast and how the iAP deals with it I can easily see the iAP losing track of that MAC address and then not sending packets toward the bridged device.



  • 10.  RE: IAP Cluster, Bridging Issue

    Posted Jun 03, 2015 06:52 PM

    Wow, very well put. Now that you put it that way I can see how the broadcast filtering can be causing a problem. I'll work on the issue tomorrow by attempting to switch to an aruba AP as the mesh client. Funnily enough, the environment has IAP 103's and for whatever reason the IAP 103 will not form a mesh. That's for another day, but thanks much for your quick and onpoint responses.

    1m