Cloud Managed Networks

 View Only
last person joined: 2 days ago 

Forum to discuss all things related to HPE Aruba Networking Central and UXI Network Management, including deployment of managed networks, configuration, best practices, APIs, Cloud Guest, AIOps, Presence Analytics, and other included Applications
Expand all | Collapse all

AOS10 WLAN Gateways and Central connectivity

This thread has been viewed 28 times
  • 1.  AOS10 WLAN Gateways and Central connectivity

    Posted Mar 22, 2024 08:45 AM

    HI

    I'm having a real hard time getting our 7205 controllers to behave as I believe they should. Running AOS 10.5.1.0 they ZTP just fine on 0/0/0 into Central where they are preprovisioned to a group. But from here on, I cannot get Central to work.

    My group config contains a PC-0 of the two 10Gbe Interfaces, VLAN 1 Native and trunked with my required VLANs.

    I run the guides on the Gateway and override the group config to assign a static IP in VLAN 10, and a default gateway on the same VLAN. I assign the VLAN as the systemIP and the LAG interface comes up and I can ping the IP on the VLAN.

    When i disconnect the ZTP port 0, i can no longer get the Controller to talk to central. On the console i can resolve DNS names, I can ping the internet using the LAG VLAN 10 interface, but the controller won't talk to central. Nothing helps. I can't SSH to the systemIP either, so only serial console access works.

    Are there restrictions on gateways that Central can only be reached from a permanently connected ZTP interface? Or do I need to configure the controller to access Central from other interfaces than ZTP?

    -Keyser



  • 2.  RE: AOS10 WLAN Gateways and Central connectivity

    Posted Mar 22, 2024 09:05 AM

    If I assign/overrule the ZTP interface on 0/0/0 to instead be my VLAN 10 i Access mode, the controller talks to Central just fine.

    So same VLAN, same IP, same default Gateway works on 0/0/0 but not on the LAG - even though it can DNS and connect to internet when only connected on the LAG.

    So I assume it's something I need to enable in the config? My google foo is helpless in the Aruba documentation on this issue.




  • 3.  RE: AOS10 WLAN Gateways and Central connectivity

    Posted 10 days ago

    I wasted a number of hours on probably the same thing. Gear came on 8.7.0.0, upgraded to 10.4.1.1, factory defaulted and tried to use ZTP to central with port-channel right out of the gate. After a couple hours, running debugs on the firewall I will was looking at packet captures. It seemed as the same was occurring, dns, ntp, and some other traffic was successful. Activate would not provide the instructions to kick it over to central. 

    packet capture showed that tcp-3way handshake was failing. 9012 sent syn, activate responded with syn-ack, responded again with syn-ack. eventually RTO's appended and a retry event took place. 

    It was a huge headache as there was no reboot option, and I do not have PDU's I can kill power. After spending extensive time for smarthands at datacenter to get shipment, racked, console, for nexus vpc with a cluster of units. Here I am spending hours on why traffic doesn't get received on the 9012 when LACP was enabled. 

    After going into full-setup, waiting for reboot just to factory default and go back in ZTP mode. It is surely a pain and I am sure there is some sort of software issue at fault. There is no way I can debug in that mode. I was checking LACP counters and they were incrementing in both directions. fdb table looked fine. 

    Going through ZTP as an access port worked but although now I am trying to debug on why I cant connect successfully to central. It has partially logged in and the control-channel seems to show its up. 

    Defiantly not a fluid process for something that has been heavily pushed. 




  • 4.  RE: AOS10 WLAN Gateways and Central connectivity

    Posted 10 days ago

    I found the issue to be caused by missing trust setup on LACP lags in central. When you create interface (lacp) and you mark it admin up and trusted it still doesn't work. You also have to mark each VLAN tagged to the interface trusted - on that interface. Sort of makes sense because it will provide more granularity in Security. But it's not obvious in the UI that you have to do it.