If your ACL contains L3 destination that are not in the VLAN, using only VLAN ACL is fine, deny security rules will apply. See VLAN ACL as a super-set.
Routed-in ACL is purely for routed traffic. VLAN ACL is for bridged and routed traffic. Sometime, admin want to decoupled L2 and L3 in writing ACL in 2 separate location, each having its own purpose. Sometime, IT have split security zone with team1 managing VLAN ACL and team2 managing routed ACL, those ACL not having the same level of granularity. In your case, I think you might want to keep it simple and just use VLAN ACL, and you can remove route-in ACL.
For step1, your proposal is correct.
-------------------------------------------
Original Message:
Sent: Dec 16, 2025 06:26 AM
From: parnassus
Subject: AOS-CX ACL synchronization on VSX Cluster
Hello Vincent, thank you for answering.
Yes, my current goal is to mimic the behavior of the ACL (in the form of "ip access-list extended <VLAN-ACL-name> in") I originally applied on AOS-S core switch in order to migrate the ACL (and the routing too) to AOS-CX (VSX). As far as I understood, I don't need to use the ACL to permit/block intra-VLAN communications within the same subnet protected by the ACL itself (thus when communications are happening between hosts hosted within the same VLAN) but for sure I need it to permit/block inter-VLAN communications between VLANs (thus when communications are originating within the VLAN by its hosts and are egressing that VLAN through its SVI to reach any other external directly/not-directly connected destination).
Given the above the simple approach of applying the ACL to the Layer 2 context with the apply access-list ip VLAN-2021 in should be enough? say:
VLAN Layer 2 context:
vlan 2021
name DF-10.255.21.0-24
vsx-sync
description Segment-10.255.21.0-24
apply access-list ip VLAN-2021 in <------ to keep
So I can remove the apply access-list ip VLAN-2021 routed-in part from the VLAN Layer 3 context:
VLAN Layer 3 context:
interface vlan 2021
description Segment-10.255.21.0-24-SVI
vsx-sync access-lists active-gateways
ip mtu 9198
ip address 10.255.21.251/24
active-gateway l3-src-mac
active-gateway ip mac 12:02:00:00:02:00
active-gateway ip 10.255.21.254
l3-counters
apply access-list ip VLAN-2021 routed-in <------ to remove
Clearly the above considering an ACL built in the classical form (each VLAN will own its dedicated ACL):
deny protocol source (net/host of the VLAN) destination (any other net/host)
permit protocol source (net/host of the VLAN) destination (any other net/host)
Vincent, I'm worried about over-simplifying too much...and, maybe, doing so...missing an alternative approach much more flexible and powerful...but, given the way I applied all the ACL on AOS-S, I believe the above approach could be enough also on AOS-CX, isn't it?
Original Message:
Sent: Dec 16, 2025 05:57 AM
From: vincent.giles
Subject: AOS-CX ACL synchronization on VSX Cluster
-1- yes, it will synchronize ACL to the secondary.
-2- If you have no rule in your ACL to protect destination from source inside the same VLAN (say an intra VLAN rule), then you can use a routed-in ACL in the SVI and no ACL in the VLAN; this is protection for routed traffic only. If you have intra-VLAN rules, then you can combine intra and inter VLAN rules in a VLAN ACL, no need to add a routed-in ACL.
If you want to use VLAN ACL for intra-VLAN rules only and use a routed-in ACL for inter-VLAN rules, this is also possible.
If you want to copy/paste what you used with AOS-S, and it was a VLAN ACL, then I guess the easiest is to simply use one VLAN ACL (no need for additional routed-in SVI).
Original Message:
Sent: Dec 15, 2025 05:30 AM
From: parnassus
Subject: AOS-CX ACL synchronization on VSX Cluster
Hi Vincent!
- So it's good to add the vsx-sync parameter inside the ACL context, isn't it?
- Your note "b" forwards me back to the question I made in my earlier post: "So now my question is...is the apply access-list ip VLAN-2021 routed-in statement applied into the interface vlan 2021 context on VSX Primary necessary or should I remove it? I basically need that the VLAN 2021 segment - which owns its SVI via interface vlan 2021 context - see the applied ACL on the incoming direction (seen from the router which is the VSX) but I was confused by applying the ACL into two different contexts (vlan and interface vlan)." - in other words, if I'm trying to mimic the behavior of the ACL (ip access-list extended <VLAN-ACL-name> in) I originally applied on AOS-S...should I proceed with:
- apply access-list ip VLAN-2021 in at VLAN contex alone? or should I use instead the:
- apply access-list ip VLAN-2021 routed-in at VLAN interface context or should I apply both (as I did)?
- Basically I want to apply an ACL to traffic originating within a VLAN and egressing it to other internal/external destinations (as seen from the routing Switch = as seen by the VLAN's SVI)...or should I totally re-think the way of applying such of an ACL when working on AOS-CX because the AOS-CX approach is able to apply the ACL (in/routed-in), as you wrote, in different ways achieving different goals?
- OK
- OK
Original Message:
Sent: Dec 12, 2025 09:39 AM
From: vincent.giles
Subject: AOS-CX ACL synchronization on VSX Cluster
Hello Davide,
-a- The vsx-sync inside ACL context is visible in an example p60 of VSX Config Best Practices (step11). So I guess it answers for VLAN ACL.
-b- Please make the distinction between VLAN ACL (traffic entering the VLAN) and routed-in ACL applied to a SVI, which is used for routed-traffic, i.e.
VLAN ACL applies to both bridged and routed traffic. The Interface VLAN routed-in ACL only applies to routed traffic.
So you may use only routed-in ACL if you don't want to apply security for non-routed traffic, or you may use VLAN ACL and routed-in ACL if you want to better segment and
construct your ACLs in simpler forms. One note: routed-in ACL and VLAN ACL are 2 different types of ACL and hence use different TCAM blocks. Sometime, the choice is driven
by the other policy/ACL functions being used in parallel (the number of parallel lookup is limited - platform dependent)
-c- vsx-sync access-list is not documented in best practices. This is a choice, to keep config light. But you got it in your example.
-d- vsx-sync acl-log-timer and acl-secure-update are correctly applied to vsx context. acl-secure-update is useful to ensure the same security enforcement mechanism exists on primary and secondary when ACL entries are updated (block all during the time the TCAM is re-programmed).
Hope this clarifies.
Best regards,
Vincent Giles
Original Message:
Sent: Dec 04, 2025 10:31 AM
From: parnassus
Subject: AOS-CX ACL synchronization on VSX Cluster
Hi Yash, first of all, thank you!
OK, I see...so let me to understand...do I need to apply the access-list ip VLAN-2021 (ingress) at both VLAN Layer 2 and VLAN Layer 3 contexts as you suggested in order for the ACL to work? if it's so, I already did that, indeed see the 2x8360 AOS-CX 10.13.1120 VSX Primary's running configuration (snippets):
VLAN ACL IPv4 context:
access-list ip VLAN-2021
vsx-sync
!
1000 comment Permit VLAN 2021 ICMP echo-reply to any permitted destination
1000 permit icmp 10.255.21.0/255.255.255.0 any icmp-type echo-reply
1010 comment Permit VLAN 2021 ICMP echo to any permitted destination
1010 permit icmp 10.255.21.0/255.255.255.0 any icmp-type echo
...
VLAN Layer 2 context:
vlan 2021
name DF-10.255.21.0-24
vsx-sync
description Segment-10.255.21.0-24
apply access-list ip VLAN-2021 in
VLAN Layer 3 context:
interface vlan 2021
description Segment-10.255.21.0-24-SVI
vsx-sync access-lists active-gateways
ip mtu 9198
ip address 10.255.21.251/24
active-gateway l3-src-mac
active-gateway ip mac 12:02:00:00:02:00
active-gateway ip 10.255.21.254
l3-counters
apply access-list ip VLAN-2021 routed-in
Additionally this is the VSX context part:
vsx
system-mac 02:02:00:00:02:00
inter-switch-link lag 256
role primary
keepalive peer 10.255.249.1 source 10.255.249.0 vrf VSX-Keepalive
linkup-delay-timer 35
vsx-sync acl-log-timer acl-secure-update dns icmp-tcp lldp loop-protect-global mclag-interfaces neighbor snmp ssh static-routes stp-global time vsx-global
side note: have a look at the vsx-sync acl-log-timer acl-secure-update settings above, is it correct to have them applied in the vsx context?
Cheers, Davide.