Almost at wits end, I feel that this is probably a switch config issue, but I'm clearly missing something so if any of this sounds familiar and anyone has any advice I'd be glad of the help:
Point to point mesh
Cisco <----> AP <**** mesh ****> AP <----> HP <----> 1 x AP
2960cx 274 274 2920 277
The mesh link seems to come up fine.
AP277 attached to switch downstream of mesh with our normal, non-mesh config sends DHCP discovers but never receives offers. I see the offers on the switch upsteam of the mesh (on the port connected to the portal) but the offers never make it across the mesh to the point switch.
I am sending the AP management vlan untagged across the mesh, and the switch management Vlan is 1400, that's going across tagged. The wired-ap-profiles (one for portal, one for point):
Wired AP profile "cam-guild_portal-wiredap"-------------------------------------------Parameter Value--------- -----Wired AP enable EnabledTrusted TrustedForward mode tunnelSwitchport mode trunkAccess mode VLAN 1Trunk mode native VLAN 1Trunk mode allowed VLANs 1,1400Broadcast Broadcast
Wired AP profile "cam-guild_wiredap"------------------------------------Parameter Value--------- -----Wired AP enable EnabledTrusted TrustedForward mode bridgeSwitchport mode trunkAccess mode VLAN 1Trunk mode native VLAN 1Trunk mode allowed VLANs 1,1400Broadcast Broadcast
Just to make things more complicated the switch at the portal end is Cisco 2960cx, and the switch downstream of the mesh is HP 2920. Switch config for link to portal:
interface GigabitEthernet0/1switchport trunk native vlan 3118switchport trunk allowed vlan 1400,3118switchport mode trunkswitchport nonegotiateip arp inspection trustpower inline staticsrr-queue bandwidth share 1 30 60 10priority-queue outstorm-control broadcast level 5.00no cdp enableno lldp med-tlv-select network-policyspanning-tree portfast trunkspanning-tree bpdufilter enablespanning-tree guard rootend
Config for link to point:
interface 23broadcast-limit 5poe-allocate-by valuepoe-value 30dhcp-snooping trusttagged vlan 1400untagged vlan 3118no port-security eavesdrop-preventionspanning-tree bpdu-filterarp-protect trustexit
Link to non-mesh AP:
interface 1broadcast-limit 5poe-allocate-by valuepoe-value 30untagged vlan 3118no port-security eavesdrop-preventionspanning-tree admin-edge-portspanning-tree root-guardexit
I'm going round in circles so any help much appreciated!
See if this helps,
Something went wrong with copy-paste. This one should work.
Something breaks when I paste links,
You can try searching the community knowledge base for the article titled,
"How should the Aruba controller be configured to ensure proper VLAN tagging across a mesh bridge link?"
Thanks for this, interesting reading. I will implement it tomorrow and let you know...
Is this IAP (Instant) or AOS (controller) based? Just wanting to make sure...
So this may or may not be relevant. Because you are running in tunnel mode, and without knowing exactly what the port config is on every relevant connection point, know that whatever comes across the wired interface on the 274 mesh link is tunneled all the way back to the controller. SO if you have VLANs configured on the switches you noted, but NOT on the controller, I assume 3118, then there wouldn't be L2 from the controller out to the har side HP2920.
You also seem to have one profile that is tunnel mode and one that is bridge. At least on the 274s they need to match (either both bridge or both tunnel). The 277 off the 2920 should just be a normal Campus AP. Worst comes to worse, take the switches out of the equation (at least on the HP side) and test to see if you have continuity over the mesh link. If you can make it to the HP2920 from the network, then at least you know the native VLAN is up (whatever that is, either VLAN 1 or VLAN 3118, depending on how they are hooked up).
Thanks for this info, we had to send the equipment out for deployment today so I cannot test any more. However nothing I tried solved the problem, DHCP offers not received by client APs. The mesh was reliable (in terms of coming up) so we are installing the switch and APs in the next day or two, I'll have to work remotely and hope I don't do anything stupid to cut myself off!
We did find something in the release notes for 126.96.36.199 which may be relevant:
"Symptom: Broadcast traffic from a switch to mesh point's Ethernet 0 wassent back. This issue is resolved by removing eth0 from bond0 interface.
Scenario: This issue occured when a client or a switch connected to meshpoints relayed broadcast traffic. This issue was observed when a client ora switch was connected to a mesh point's Ethernet 0Platform: Allplatforms.
Reported Version: ArubaOS 188.8.131.52.Bug ID 124682, 126989"
We'll try a firmware upgrade after installation to see if that solves it.
At Aruba, we believe that the most dynamic customer experiences happen at the Edge. Our mission is to deliver innovative solutions that harness data at the Edge to drive powerful business outcomes.
© Copyright 2021 Hewlett Packard Enterprise Development LPAll Rights Reserved.