Networking General

Last reply by 02-03-2022 Unsolved
Start a Discussion
3 Argentum

OS10 access-list and vlans: what is in and what is out?

I have a vlan51, vlan52 and vlan53, and want to stop traffic between vlan51 and 52, but allow both to connect to vlan53.  I started with just the traffic from vlan53 into vlan52, but that broke existing connections between the vlans. My idea of in and out was clearly wrong, and reversing the permit IP addresses fixed the problem.

'In' clearly doesn't mean traffic coming into vlan52 from other vlans.  

Is there a good guide for this?

interface vlan52
 no shutdown
 ip address
 ip access-group ceph_nfs_client_v52_in in
interface vlan53
 no shutdown
 ip address

Ingress IP access-list ceph_nfs_client_v52_in
 seq 10 permit ip
 seq 100 deny ip any any


Replies (9)
3 Argentum

Where this works

 seq 10 permit ip
 seq 100 deny ip any any



Hi Rob.


The traffic between the different VLANs is blocked by default, so you need to bypass this for inter-VLAN routing.

As we can not offer configuration services here I ask you to check out the following community posts and articles about this topic:

Inter VLAN routing with multiple VLANs

Dell S4128F-ON Inter VLAN routing


Inter vlan routing


Inter Vlan Routing Dell N2024


Dell EMC Networking Configuring VLAN on Switches


What is VLAN Routing?


OS10 Enterprise Edition User Guide



And if you find the solution, don't hesitate to post it here on the forum, so others could benefit from it.


Maybe somebody else here in the community knows how to solve it quickly, but if not, you can contact your sales representative in order to ask for a fee-based configuration service.



Best regards



Stefan Richter
Community Manager
Brand certified, SMaC Professional


I will look through the docs you posted.

I do have working routing between the vlans. Just adding an IP address to a vlan, also adds a route into the routing table, and traffic flows.  And I have VRRP working on the VLTi pair (two S5232Fs, running 10.5.2).

I have ACLs working on physical interfaces, but that knowledge doesn't look to translate to vlans. 

I don't understand the traffic paths in and out of vlans, so the  references in the CLI guide to 'Ingress' and 'egress' aren't helpful.



You may also want to look at ACL filters,


DELL-Josh Cr
Social Media and Communities Professional
Dell Technologies | Enterprise Support Services

Did I answer your query? Please click on ‘Accept as Solution’. ‘Kudo’ the posts you like!


Found a 2008 document, which looks to still apply.

The behaviour I see looks to be the same on 10.5.2.  The ACLs look to be being applied on the physical interfaces that belong to the VLAN, so ingress  to the VLAN is packets coming in through a physical interface.  And they look to be being applied to the traffic already on the vlan, if it passes through a physical interface (i.e traffic to/from the same network as the VLAN needs to be permitted). 

"On a PowerConnect 62xx switch, traffic that enters a VLAN interface via an internal source will be overlooked by an ingress ACL. This includes traffic originating from the switch interface and traffic that has been routed from another VLAN. Similarly, traffic exiting one VLAN interface only to enter another interface within the switch is also overlooked, as only traffic exiting the switch has ACLs applied to it.


In the above diagram, the ingress ACL applied on VLAN 1 only affects traffic received from hosts connected to VLAN 1. If traffic is flowing from VLAN 2 to VLAN 1, the ACL applied to VLAN 1 will have no effect, as it is not applicable to traffic that is entering the interface from an internal source (such as another VLAN). Traffic does not have to be routed for the ACL to take effect. Traffic from VLAN 1 that is destined for something on the same subnet is still subjected to the ACL."



I'm still not 100% sure what is going on, but the VLAN ingress ACLs look to work if the source IP is the local  vlan's network and the destination is the remote vlan's network. 

The was one exception though, where on one of the vlans, I also had to put in rules for the remote vlan as the source, and the local vlan as the destination. I'm not sure why this was necessary on just this vlan, so I ended up adding catch all permits on the other vlans too, just in case (but they did seem to be working without the additional permits). 

I also put in a rule for the vlan to be able to talk to itself, and for the vlan router to send to the VRRP multicast address.

All the OS 10 documents I have found or been referred to, don't distinguish between hardware port ACLs and VLAN ACLs. Or more accurately, they say ACLs can be applied to physical, port channel and VLAN interfaces, then go on to talk about physical interfaces. There is clearly a difference that needs to be documented. 


Hi Rob, 

I came across the same issue as yourself when creating and applying VLAN ACLs on a pair of Dell S4128F-ON switches in a VLT configuration with peer-routing enabled. 

Unlike Cisco, ACLs on Dell switches appear to function more like a VLAN Map rather than a pure router based ACL. Applying an ACL inbound to a VLAN interface suddenly blocked all traffic between hosts within the same VLAN and also caused incomplete TCP handshakes to other hosts within another VLAN. 

According to Dell the implicit deny any any at the end of the ACL will deny all traffic not specifically permitted via the ACE entries. Adding permit ip any any or permit <source network> <source network> at the end allowed this traffic to flow. 

I have also found that some deny ip statements do not apply, properly.  For example I want to stop VLAN 20 ( from being able to talk to VLAN 70 ( so I have the entry deny ip specified in an ACL inbound the interface of VLAN 20, this should deny the network from being able to talk to the network, however I can still ping the VLAN 70 SVI on switch 1 yet ping replies on the SVI on switch 2 fail as does some other traffic but not all. 

The Dell OS10 documentation does not detail how VLAN ACLs are applied or how these work, this is also very confusing if you are coming from a Cisco background.

You can see my previous post on this below.



2 Bronze
2 Bronze

ACL is L3 Routing, Think in terms of Routing for direction.  Traffic inbound to routing is traffic leaving/out the Vlan and Traffic outbound of the routing is entering/in the Vlan.


I am familiar with Layer 3 routing and how ACLs work and I'm sure the original poster of this thread is too, this is not what we are asking about. 

What we are saying here is that ACLs on Dell Switches are not applied in the same way as with other networking vendors such as Cisco, HPE etc

For example, on Cisco switches lets assume the following, you have VLAN 2 with and VLAN 3 with

You create the following ACL inbound on the VSI of VLAN 2 to allow traffic from, VLAN 2 to VLAN 3 and block everything else. 

permit ip

deny ip any any

In this instance traffic from to will be able to pass but traffic to any other networks will be blocked due to the deny ip any any statement at the end. 

Hosts within the network will still be able to communicate with each other as expected as they are on the same network segment. 

This is NOT the case on Dell switches, in the example above the ACL is also applied to hosts within the same VLAN unless you specifically permit this either by using the permit ip any any statement or permit ip 

Nowhere within Dell's documentation for OS10 is this mentioned nor do support or product engineers appear to acknowledge this when supporting customers, this is what needs to be communicated. 





Latest Solutions
Top Contributor