Bypass / Cheat ACL

[Jeffrey_233]

Hi All

I'm having a problem with a connection to a storage device in our DC.

I have multiple there and there are many ACL's in on our Core (Bonded Pair) but they are the same rules to each storage device.

Applied via switch to get to the DC. I've compared the ACL's on each Core to see if there was a miss match but couldn't find any.

I keep getting packet loss to one on the storage nodes. Clients are on Vlan10 and Storage is on Vlan100.
Clients are currently configured to Vlan10 and ACL gives access to the storage.

If I did a trunk mode to the Client with a native vlan10
Would this allow me to trick/cheat the ACLs and give me a direct/better connection to confirm it's an ACL or possibly something else?
Or is there a better way to check and test this?

[marce1000]

   - If you think the problem is related to the ACL's then try remove them temporarily and test

 M.

[balaji.bandi]

I do the below test :

1. This may be due to load balance or physical port issues.

   - if this is port-channel, shutdown 1 of the port and test, same test other links too, see any difference.

2. as suggested, remove ACL for temporary and test.

Do you see any errors on the interface?

[MHM Cisco World]

two different VLAN need some L3 in between ? are you config any HSRP ? how two DC SW handle L3 GW?
the goal of using HSRP is give one Default GW IP to Client which is the VIP. 
I think the Client use wrong Default GW so it never connect to Storage.

[Jeffrey_233]

The dropped packets still creeping up even when switch dropping one of the ports in the port channel group.

As far as the ACL's go. I've allowed all tcp traffic and only denied 443 so users can't get to the storage UI.
And no change.
I'm starting to think there is something else going on here.

[MHM Cisco World]

Can you simple draw the topology?

[Jeffrey_233]

[MHM Cisco World]

OK, The ACL is apply in SVI of VLAN10 on CoreSW ?
show ip access-list
see the match count where it increase ? check that line many be the line number affect the traffic. 

[MHM Cisco World]

Do you check acl match ? Is it hit any line? If not 

 add deny any any at end of acl 

Do check agian to see if it hit deny any any if not 

Then there is routing or NAT issue in your netwrok.

[Jeffrey_233]

@MHM Cisco World What do you mean by 

---

@MHM Cisco World wrote:

Do you check acl match ? Is it hit any line? If not 

 add deny any any at end of acl 

Do check agian to see if it hit deny any any if not 

Then there is routing or NAT issue in your netwrok.

---

[MHM Cisco World]

Why we add deny any any it the end of acl, even if it by defualt end any acl?

For troubleshooting, the default deny not appear but config it make it appear in show access list,

This make sure that not acl drop traffic but something else.

Are you check the ACL or NOT?

[delbert.hudson]

To get acl counts.

[balaji.bandi]

quick test remove the ACL see what is the outcome.

check interface output have any drops ? or post information here ( all the path interface connected)

show interface g x/x

[Georg Pauwen]

Hello.

--> The dropped packets still creeping up even when switch dropping one of the ports in the port channel group.

If you are using a port channel, the default load balancing algorithm is src-dest-ip. You might want to try a different algorithm and check if that makes a difference, using the global command ' port-channel load-balance'. Your options are:

dst-ip
dst-mac
src-dst-ip
src-dst-mac
src-ip
src-mac
src-port
dst-port
src-dst-port

[Jeffrey_233]

We finally got around to restarting the storage device. Have been waiting for backups to complete.
It looks to have resolved the issue, going to keep an eye on it for the week to see if anything creeps up.
Appreciate all the help.