There is an implicit deny all statement at the end of the ACL that blocks all traffic not specifically permitted. Adding a permit any any to the end should allow all none denied traffic to work. Let us know if you have any additional questions. Page 1364 https://dell.to/3l28MeU
Interestingly I came across a stranger issue when connecting our new VDI environment up to these switches.
When Logged into a VM on the destinated VDI VLAN I noticed that incomplete TCP handshakes to some hosts within the 10.0.0.0/23 network were occurring while others were fine. Running a packet capture from within the client VM showed that TCP packets to these hosts where hung at SYN_SENT flag while on the server side the transmission was sitting at SYN_RECIEVED, however the ACK flag was never processed resulting in the connections failing to go to the established state.
Oddly, our current VDI environment is connected to a stack of 2x Dell N1524 switches in Layer 2 mode (no routing) which are then connected to the S4128F-ON switches via an LACP port channel. This environment is on the same VLAN and did not experience these issues.
Adding a permit ip any any statement at the end of the inbound ACL for VDI VLAN interface (10.20.0.0/23) solved the TCP handshake issues within the new VDI environment on the S4128F-ON switches.
What I don't understand is that this ACL already had permit ip 10.20.0.0/23 10.0.0.0/23 specified so surely it shouldn't have made a difference what switch these environments were connected to?
Could this be a potential firmware bug with the S4128F-ON switches? We are currently running on firmware from late April this year.
DELL-Josh Cr
Moderator
•
9.5K Posts
0
September 30th, 2020 10:00
Hi Greig,
There is an implicit deny all statement at the end of the ACL that blocks all traffic not specifically permitted. Adding a permit any any to the end should allow all none denied traffic to work. Let us know if you have any additional questions. Page 1364 https://dell.to/3l28MeU
DELL-Josh Cr
Moderator
•
9.5K Posts
0
September 30th, 2020 12:00
Yes, that should work.
Greig_Mitchell
1 Rookie
•
15 Posts
2
September 30th, 2020 12:00
Hi Josh,
Would adding permit ip 10.0.0.0/23 10.0.0.0/23 at the end of the ACL also give the same effect and allow non-denied traffic within the same VLAN?
Many thanks.
Greig_Mitchell
1 Rookie
•
15 Posts
0
October 8th, 2020 01:00
Thanks Josh, that has worked.
Interestingly I came across a stranger issue when connecting our new VDI environment up to these switches.
When Logged into a VM on the destinated VDI VLAN I noticed that incomplete TCP handshakes to some hosts within the 10.0.0.0/23 network were occurring while others were fine. Running a packet capture from within the client VM showed that TCP packets to these hosts where hung at SYN_SENT flag while on the server side the transmission was sitting at SYN_RECIEVED, however the ACK flag was never processed resulting in the connections failing to go to the established state.
Oddly, our current VDI environment is connected to a stack of 2x Dell N1524 switches in Layer 2 mode (no routing) which are then connected to the S4128F-ON switches via an LACP port channel. This environment is on the same VLAN and did not experience these issues.
Adding a permit ip any any statement at the end of the inbound ACL for VDI VLAN interface (10.20.0.0/23) solved the TCP handshake issues within the new VDI environment on the S4128F-ON switches.
What I don't understand is that this ACL already had permit ip 10.20.0.0/23 10.0.0.0/23 specified so surely it shouldn't have made a difference what switch these environments were connected to?
Could this be a potential firmware bug with the S4128F-ON switches? We are currently running on firmware from late April this year.
DELL-Josh Cr
Moderator
•
9.5K Posts
0
October 8th, 2020 09:00
I was not able to find anything about a known issue with the firmware.