Controllerless Networks

last person joined: 2 days ago 

Instant Mode - the controllerless Wi-Fi solution that's easy to set up, is loaded with security and smarts, and won't break your budget
Expand all | Collapse all

IAP VLAN issue: Bug or by design?

This thread has been viewed 0 times
  • 1.  IAP VLAN issue: Bug or by design?

    Posted Jan 12, 2018 05:18 AM

    Hi,

     

    After struggling with an IAP-315 setup we've discovered something weird. But let me describe our setup first:

     

    Site 1:

    10x IAP-315 set up with Management VLAN = 2 and Native VLAN = 101.

    VLAN 2 is our infrastruktuce network.

    VLAN 101 is a guest network with only internet access.

    Switchport config on the switch is: VLAN 2 = tagged, VLAN 101 = untagged.

    When we add new AP's they start out on an untagged VLAN 2 port on the switch, in order to connect with the other configured AP's, and get the config, and then we power the new AP off while changing it's switchport to VLAN2: tagged and VLAN101: untagged.

    Result: Works great.

     

    Site 2:

    Exact same configuration with only ONE difference: The infrastructure VLAN (or management VLAN if you will) is not on ID 2 but uses ID 1 (default VLAN).

    Result: Election broadcast packets are being sent either over the native vlan (untagged), hence we cannot add AP's to the first one we configured.

     

    Conclusions and questions:

    This is 100% reproducible. The show election statistics command on new ap's shows that NO packets are received. Meanwhile both AP's are able to ping eachother just fine.

     

    Also, I should mention, that when we created a test VLAN2 and Site2, we got it working immidiately!

     

    So my question is this:

    Is this behavious a bug or by design (and by design I mean: is it common knowledge that VLAN1 must not, or can not be tagged)?

    The fact that points to this being a bug IMO, is that is it absolutely possible to configure VLAN1 under the Management VLAN and as tagged on our HP switch port. If this wasn't supported, shouldn't they make sure it wasn't accepted when entered in the config?



  • 2.  RE: IAP VLAN issue: Bug or by design?

    EMPLOYEE
    Posted Jan 12, 2018 06:47 AM


  • 3.  RE: IAP VLAN issue: Bug or by design?

    Posted Jan 12, 2018 07:24 AM
    That's what I mean by "management vlan". My bad. It's the management uplink vlan I mean.

    So yes.

    /Rasmus


  • 4.  RE: IAP VLAN issue: Bug or by design?

    EMPLOYEE
    Posted Jan 15, 2018 02:58 AM

    Can you try assigning the management VLAN (the VLAN on which the IAP management and inter-AP communications occur) as untagged, and the data/client VLANs as tagged?

     

    That is how the product is designed, try to avoid having the management network tagged whenever possible. I have seen weird things in the past if you try to tag VLAN 1, which is the default VLAN in most switches, and different switches behave differently which makes it very unpredictable.

     

    Best practice: bring a dedicated VLAN for only the Instant APs internal communication and management as untagged to each AP, and bring the VLANs for your clients as tagged to the Instant AP.



  • 5.  RE: IAP VLAN issue: Bug or by design?

    Posted Jan 15, 2018 03:15 AM

    Yes, and that works. But it is not how we want our configuration (for various reasons).

    The option to tag the management traffic is there, so it is supported doing it that way - doesn't matter how the product was initially designed. I know that the tagged mangement uplink feature was only added later, but still: Now it's there, so it should work.

    I've created a support ticket with HP. Since this configuration works with any other VLAN ID than 1, I am fairly certain this is a bug.

    Anyway, we already configured VLAN 2 in our infrastructure, so it all works now. Just wanted to shed some light on the issue, as I can see a lot of people having VLAN tagging issues with the Aruba AP's in various forums. Hopefully they'll read this, or HP/Arube will acknowledge this as a bug and include a fix in a future firmware update.

     

    /Rasmus