I had some info I wanted to just correct on previous statement about AAA Profile. I came across a site of ours with 2930F + per-port tunneled node. It ended up using the same AAA profile as what was applied to default authentication wired profile (show aaa authentication wired). This was on AOS 8.10 although could be slightly different on per-user (as cx does not support per port) or AOS 10.x. My recommendation would be to check the AAA profiles used by clients in the user table vs assume. If its not something that is trying to be achieved then its not applicable.
The default is on physical port. If the vlan or port is untrusted then it will use a use a role for every IP address (arp inspect or dhcp inspect) that is plugged into the port. Its best to understand which profiles are used and this way incorrect configs will not be used that may block intended traffic.
-------------------------------------------
Original Message:
Sent: Jan 29, 2026 08:02 AM
From: mvanoverbeek
Subject: VRRP on SD-Branch
Thank Justink,
Those are some good recommendations, I am going to test it back out over the weekend and see where I get with it.
------------------------------
Martijn van Overbeek
Architect, Netcraftsmen a BlueAlly Company
Original Message:
Sent: Jan 28, 2026 04:43 PM
From: justink
Subject: VRRP on SD-Branch
Your welcome!
Its a hard OS to learn the CLI, although the pro's defiantly are there. 10.x has all the same features and concept's as previous releases; with some added. Each architecture has its focus points although configs still work pretty much the same. I wouldn't get bent out of shape in regards to default configs that are not used by anything. You can try to move something back to the default group and then move back over to see if it corrects it.
Ideally the least amount of changes on design deployment is the intended goal. Apply 95% in group configs. I know you can use a CSV file for bulk config updates in branch gateways. I am not sure what options will exist when New central supports orchestration. There have been some general sync issues I have seen with new/legacy central over the years. The general direction seems to be the same if it happens. I never really had this experience with Mobility Conductor on 8.x. Of course it had its own flaws at times, although has been a large work horse for us over the last 4 years with BOC-VPN.
I am not 100% as to the vlan of your clients. If they are on same subnet as dhcp server and you are not using UBT. Your arp and forwarding table would be used on swtich @ L2 vs being directed back to gateways. If UBT or needing to route traffic. Then you would need to look at datapath session table for flags. If you look at datapath session "dpi" table it will tell you the ace index as to which ACL is actually used when the traffic hits. Even with dpi disabled at firewall it will still show you the ace index. There have been times I have had return traffic blocked in an role of a device but not the role of the source. When these times exist you can typically find which ace index it as fault and get it fixed pretty quickly. This used to be a tough spot when I was at customers years ago as I could never identify what was blocking the traffic. Once understood its pretty easy.
Also keep in mind, if you do have a PBR used back to datacenter. Make sure your local subnets are configured as "forward" vs route. You dont want to route your local site traffic back to datacenter. This is another reason I dont prefer pbr. Its much easier to troubleshoot and fix route based designs.
The routing profile (pbr) is used in parallel to a role (untrusted) or acl (trusted). If you learn the seesion table enough you can pickup traffic that is not returned or routed in PBR. I dont really go by what is in the config and instead I go by what outputs of commands inform me. The only real caveat in session table is when traffic is source-nat, you wont see the response traffic *if you are filtering at source/client ip*. If you look at destination IP you will see the response. There are other ways to go around this but you can identify the source/destination nat that takes place if you use session table in firewalls enough.
Its hard to suggest what the fault was that you had with a couple chats and not real time session. Some areas I would focus on..
- does traffic arrive on gateway (session table)
- is traffic routed by accident to datacenter (we need local subnets to be forwarded in pbr) (show acl hits)
- are we traversing subnets, or do we need to look at local arp table, or are we bridging (show arp, show datapath bridge, show route-access-list, show ip access-group)
- do clients/server show in user table (is port untrusted or UBT used?) (default design is to not permit client traffic if port is untrusted and client is not in user table)
- are we using nat by accident?
- does session table show response traffic for packets/bytes?
I would generally focus on the session table vs spend time on pcap's. It could be something simple that was not in place which blocked the response traffic or pushed the traffic to a destination you didn't want. You can rule things out by adding allowall acl in the roles that you use.
Original Message:
Sent: Jan 27, 2026 08:37 PM
From: mvanoverbeek
Subject: VRRP on SD-Branch
Hi Justin,
These were helpful commands, I learned that through show route-access-list that only a PBR I configured was in sue not that uplink-lb-cfg-racl access-list which I can't recall even configuring.
Looks like the other ACLs aren't really in use either.
I still find it strange however that two identical boxes with the same software have configuration differences. The one thing that comes to mind is: I think I configured one while in the default group (this was relating to that other post and the other VLAN for WAN) while I configured the other while being in the branch-gateway group. That must be it!
I removed the aaa-profile from vlan 3 and changed port-channel and VLAN to trusted, after this change ping to DNS worked again.
To things I learned:
Setting up profiles, roles and policies is tedious, complex and most likely not adding much except for a lot of complexity. Especially when I think I can still provide security in the roles itself.
I probably need to revisit the access-list and trust of VLANs and port-channels again and fully understand how this works
I had a aaa-routing profile on the VLAN but noticed this did not capture any deny logs from DNS, so it must be something else that caused silent drops. The weird thing that remains is that only one IP out of the subnet was affected, and after removing the Aaa-profile and adding trust this IP was reachable again. I just can't explain that.
Setup was like this:
==port channel == vlan 3,25,26 ==port channel== Gateway01==svi 26+svi3
DNS server ==vlan25 ===switch with SVI 25
==port channel == vlan 3,25,26==port channel= Gateway02==svi 26+svi3
------------------------------
Martijn van Overbeek
Architect, Netcraftsmen a BlueAlly Company
Original Message:
Sent: Jan 27, 2026 07:55 PM
From: justink
Subject: VRRP on SD-Branch
Forgot to mention. If DNS is still not working. Grab the session table while testing a few times.
- show datapath session table <dns-server-ip>
Original Message:
Sent: Jan 27, 2026 04:44 PM
From: mvanoverbeek
Subject: VRRP on SD-Branch
Things improved which is great, I can now ping the secondary gateway and ssh to it when connected to the Gateway through UBT or Wireless. Thanks for both of your help!I t is a good reminder to not fully rely on the GUI. I am running 10.7.2.2 SSR
The issue remaining is DNS and the fact that I cannot reach this server (very strange), I will do some more debugging on that end.
That said there were some remnants from tests I did that I forgot about so I should NOT blame the Central
I scanned through the configurations after comparing the GUI
I scanned through the two configuration and did see a few things I did not understand below listed, hopefully one of you can help me understand the importance of these differences:
I am especially curious about uplink-lb-sys-racl but basically all
Configuration lines that can only be found on gateway 1 not on gateway 2
netservice any-v6 255
netservice any 0
!
ip access-list session sys-switch-acl
any any sys-svc-gre permit
any any sys-svc-syslog permit
any any sys-svc-snmp permit
any any sys-svc-http permit
any any sys-svc-https permit
user any sys-svc-kerberos-tcp permit
user any sys-svc-smb-tcp permit
any any sys-svc-snmp-trap permit
any any sys-svc-ntp permit
user any sys-svc-ftp permit
any user sys-svc-telnet deny
!
ip access-list session switch-logon-acl
any any any permit
!
ip access-list route uplink-lb-sys-racl
any host 44.228.90.242 any route next-hop-list load-balance-ipsecs
any network 192.168.26.0 255.255.255.0 any forward
any network 10.100.3.0 255.255.255.240 any forward
!
user-role ap-role
no openflow-enable
access-list session global-sacl << this line
access-list session apprf-ap-role-sacl << this line
access-list session ra-guard
access-list session control
access-list session ap-acl
access-list session v6-control
access-list session v6-ap-acl
user-role sys-switch-role
access-list session global-sacl
access-list session apprf-sys-switch-role-sacl
access-list session sys-switch-acl
!
user-role switch-logon
access-list session global-sacl << this line
access-list session apprf-switch-logon-sacl << this line
access-list session switch-logon-acl << this line
!
user-role guest-logon
captive-portal "default"
access-list session global-sacl << this line
access-list session apprf-guest-logon-sacl << this line
access-list session ra-guard
access-list session logon-control
access-list session captiveportal
access-list session v6-logon-control
access-list session captiveportal6
!
user-role logon
access-list session global-sacl << this line
access-list session apprf-logon-sacl << this line
access-list session ra-guard
access-list session logon-control
access-list session captiveportal
access-list session vpnlogon
access-list session v6-logon-control
access-list session captiveportal6
Hope you can provide more clarity
------------------------------
Martijn van Overbeek
Architect, Netcraftsmen a BlueAlly Company
Original Message:
Sent: Jan 27, 2026 03:26 PM
From: mvanoverbeek
Subject: VRRP on SD-Branch
Hi Justin
Thanks for helping with this, I will do a little more research to see if your suggestion of just trusted VLAN 3 (routing VLAN) is a better option. I might make things easier.
On Keith's question: Despite having done all configurations at the group level and only details on the gateways themselves I was surprised to see a lot of differences between the devices I couldn't really explain. I will go through it tonight in more details to at least try to align them. It is a bit worrying because I literally wiped them last week an mainly worked at group mode.
------------------------------
Martijn van Overbeek
Architect, Netcraftsmen a BlueAlly Company
Original Message:
Sent: Jan 27, 2026 09:55 AM
From: justink
Subject: VRRP on SD-Branch
I get what you are testing based on other threads of communication. Untrusted ports has worked the same since I can remember back on 6.4. I am assuming after enabling AAA and putting all vlan's as untrusted. The gateway of your vrrp peer showed up as a user role? I am not sure what your intentions would be long term. Generally I would steer away from having core services between gateway peers show up in a role. I would generally try to make these vlan's as trusted. If you cant just a simple allowall acl for the "network" role.
After spot checking the design guide. The references are for UBT (user based tunneling) on switch to vrrp gateway.
https://arubanetworking.hpe.com/techdocs/VSG/docs/070-sd-branch-design/esp-sd-branch-design-120-sdb-branch-design/#l2-and-l3-boundaries
I can propose a slightly different method if you are trying to use L2 to a switch and not use UBT. This suggestion could be slightly more limited. Direclty connect both gateways as a trusted port. Have your VRRP heartbeats go directly vs the link to switch. Use spanning tree to shut down the port on the switch from gateway 2. Spanning tree will only enable the port if the primary gateway link goes down.
As to general documentation. I personally wouldn't spend my time looking it up. There could be some other traffic purposes that are used if both gateways are in the same site. You could capture a tech-support and look for the ports to see if you can find a source services that is initiating that traffic.
If there is question of blocked traffic. I would check acl ace index you are hitting. You can reference the "session dpi" output to capture that and validate.
show datapath session dpi table x.x.x.x (used to get the ace index)
show acl ace-table all (use your ace index to match acl)
show acl hits role <name> (goto command for validating)
Original Message:
Sent: Jan 26, 2026 09:27 PM
From: mvanoverbeek
Subject: VRRP on SD-Branch
I am playing around with the SD-Branch.
On my LAN I use a port-channel that i set as Untrusted
All VLANs on this port-channel also are set as Untrusted
I created a AAA-Profile + Role + Policy (access-list)
When configuring VRRP I noticed that the two VRRP peers were unable to exchange packets
Permitting protocol 112 did not work
Eventually I noticed that enabling TCP ports 9190 and 9199 worked
I cannot recall seeing this anyway?
Is there documentation descibing the best practices of ports to enable on the LAN side in a Redundant setup?
Here is some of the output from the DNS server, I can't wrap my brain around it, why it is causing issues (no ping responses, no DNS responses)
As mentioned this subnet works fine if it is NOT on the gateway.
(branch01gw02) *#show datapath session dpi table 192.168.25.251
Datapath Session Table Entries
------------------------------
Flags: F - fast age, S - src NAT, N - dest NAT
D - deny, R - redirect, Y - no syn
H - high prio, P - set prio, T - set ToS
C - client, M - mirror, V - VOIP
Q - Real-Time Quality analysis
u - Upstream Real-Time Quality analysis
I - Deep inspect, U - Locally destined
E - Media Deep Inspect, G - media signal
r - Route Nexthop, h - High Value
A - Application Firewall Inspect
i - Session classified on first packet
J - SDWAN Default Probe stats used as fallback
f - FEC Enabled for the Session
X - SDWAN Exception, x - Translation
B - Permanent, O - Openflow
L - Log, o - Openflow config revision mismatched
Z - Session is redirected to IDPS
c - CSI classified
Apptag Vendor: q - Qosmos, w - Web-cc, c - CSI
Source IP or MAC Destination IP Prot SPort DPort Cntr Prio ToS Age Destination TAge Packets Bytes AclVer Int-Flag Sess-Flag2 PktsDpi UplnkVlan AppID AceIdx Flags DpiTIdx CPU ID ASliceId BaseApptag CatApptag RepApptag GeoApptag SaasApptag
----------------- --------------- ---- ----- ----- -------- ---- --- --- ----------- ---- ---------- ---------- -------- -------- ---------- --------- --------- ------------------------ ------------------- --------------- -------- -------- ------- ---------------------------- ---------------------------- ---------------------------- ---------------------------- ----------------------------
192.168.26.10 192.168.25.251 1 312 2048 0/0 0 0 1 local 4 1 60 285 80001 8 0 none (0 ) 295/0 /558 /0 FCIZ 145 1 31 (0 ) (0 ) (0 ) (0 ) (0 )
192.168.25.251 10.100.3.3 17 53 21548 0/0 0 0 1 local 8 1 117 0 1 0 0 none (0 ) 0/0 /0 /0 FYI be 1 31 (0 ) (0 ) (0 ) (0 ) (0 )
10.100.3.3 192.168.25.251 17 20083 53 1/4103 0 0 0 local 8 1 66 e2f 80001 0 0 none (0 ) 0/0 /0 /0 FCI 16a 1 31 (0 ) (0 ) (0 ) (0 ) (0 )
192.168.25.251 10.100.3.3 17 53 20083 0/0 0 0 0 local 8 1 133 0 1 0 0 none (0 ) 0/0 /0 /0 FYI 16a 1 31 (0 ) (0 ) (0 ) (0 ) (0 )
192.168.25.251 192.168.26.10 1 312 0 0/0 0 0 0 local 4 1 60 0 1 8 0 none (0 ) 0/0 /0 /0 FYIZ 145 1 31 (0 ) (0 ) (0 ) (0 ) (0 )
10.100.3.3 192.168.25.251 17 21548 53 1/4103 0 0 1 local 8 1 66 e2f 80001 0 0 none (0 ) 0/0 /0 /0 FCI be 1 31 (0 ) (0 ) (0 ) (0 ) (0 )
(branch01gw02) *# show acl ace-table all | include 295
295: any any 0 0-0 0-0 f80001:permit
(branch01gw02) *# show acl ace-table all | include 558
558: any any 0 0-0 0-0 f180001:permit
(branch01gw02) *#show user-table
Users
-----
IP MAC Name Role Age(d:h:m) Auth VPN link Connected To Roaming Essid/Bssid/Phy Profile Forward mode Type Host Name User Type
---------- ------------ ------ ---- ---------- ---- -------- ------------------ ------- --------------- ------- ------------ ---- --------- ---------
10.100.3.14 ec:67:94:d6:96:80 routing 00:08:17 tunnel 1 Wired aaa-routing tunnel WIRED
192.168.25.145 ec:67:94:d6:96:80 routing 00:00:18 tunnel 1 Wired aaa-routing tunnel WIRED
192.168.26.10 f4:c8:8a:16:c9:ac f4c88a16c9ac Shalalah 00:00:43 N/A Wireless Shalalah/d0:4d:c6:c7:4c:ce/N/A Shalalah_#1769455631357_273#_ dtunnel Win 10 WIRELESS
10.254.254.64 ec:67:94:d6:96:80 routing 00:08:17 tunnel 1 Wired aaa-routing tunnel WIRED
10.254.254.152 ec:67:94:d6:96:80 routing 00:08:17 tunnel 1 Wired aaa-routing tunnel WIRED
10.254.254.156 ec:67:94:d6:96:80 routing 00:08:17 tunnel 1 Wired aaa-routing tunnel WIRED
10.254.254.151 ec:67:94:d6:96:80 routing 00:08:17 tunnel 1 Wired aaa-routing tunnel WIRED
10.254.254.44 ec:67:94:d6:96:80 routing 00:08:17 tunnel 1 Wired aaa-routing tunnel WIRED
10.254.254.153 ec:67:94:d6:96:80 routing 00:08:17 tunnel 1 Wired aaa-routing tunnel WIRED
User Entries: 9/9
Curr/Cum Alloc:9/44 Free:4/35 Dyn:13 AllocErr:0 FreeErr:0
(branch01gw02) *# show acl hits role Shalalah
User Role ACL Hits
------------------
Role Policy Src Dst Service/Application Action Dest/Opcode New Hits Total Hits Index Ipv4/Ipv6
---- ------ --- --- ------------------- ------ ----------- -------- ---------- ----- ---------
Shalalah shalalah any any any permit 11603 11603 16167 ipv4
Here's also the proof that a host in this subnet is able to receive and process responses from the DNS server (.251)
overlake200sw01# ping 192.168.25.251 source vlan26
PING 192.168.25.251 (192.168.25.251) from 192.168.26.77 : 100(128) bytes of data.
108 bytes from 192.168.25.251: icmp_seq=1 ttl=64 time=0.291 ms
108 bytes from 192.168.25.251: icmp_seq=2 ttl=64 time=0.281 ms
108 bytes from 192.168.25.251: icmp_seq=3 ttl=64 time=0.248 ms
108 bytes from 192.168.25.251: icmp_seq=4 ttl=64 time=0.246 ms
108 bytes from 192.168.25.251: icmp_seq=5 ttl=64 time=0.262 ms
--- 192.168.25.251 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4089ms
rtt min/avg/max/mdev = 0.246/0.265/0.291/0.017 ms
overlake200sw01# ping 192.168.25.1 source vlan26
PING 192.168.25.1 (192.168.25.1) from 192.168.26.77 : 100(128) bytes of data.
108 bytes from 192.168.25.1: icmp_seq=1 ttl=64 time=0.095 ms
108 bytes from 192.168.25.1: icmp_seq=2 ttl=64 time=0.106 ms
108 bytes from 192.168.25.1: icmp_seq=3 ttl=64 time=0.102 ms
^C
overlake200sw01# ping 192.168.25.240 source vlan26
PING 192.168.25.240 (192.168.25.240) from 192.168.26.77 : 100(128) bytes of data.
108 bytes from 192.168.25.240: icmp_seq=1 ttl=64 time=0.285 ms
108 bytes from 192.168.25.240: icmp_seq=2 ttl=64 time=0.365 ms
108 bytes from 192.168.25.240: icmp_seq=3 ttl=64 time=0.369 ms
------------------------------
Martijn van Overbeek
Architect, Netcraftsmen a BlueAlly Company
------------------------------