problem with my ACL

[ohassairi]

hello

i use 2 core switches : c6500 SUP1+PFC+MSFC2 (12.1)using HSRP....

i added an ACL to vlan 122:

ip access-list extended acl122

permit ip 10.122.0.0 0.0.255.255 100.100.0.0 0.0.255.255

int vlan 122

ip access-group acl122 in

now, from a computer in vlan 122 i can ping all computers in vlan 100 and all computers in vlan 122 except my gateway 10.122.100.254 that is the hsrp address. even the real addresses 10.122.100.252 & 253 can't be pinged.

arp is resolved, but it seems to be a problem caused by my ACL.

is this normal?

[Jon Marshall]

Hi

Yes it is normal because you have applied the acl on the vlan interfaces in an inbound direction so unless you add in the HSRP + physical addresses you will not be able to ping them

You can ping all the other clients in vlan 122 because they do not go to the vlan interfaces so are not subject to the acl you have applied.

If you need to be able to ping the default-gateway just add in the relevant lines into your acl.

HTH

Jon

[ohassairi]

ok

i got your point

now i tryied an other way : i changed the in to out so i have

ip access-group acl122 out

i found i can ping my gateway, but can t access to 100.100.0.0 network, the permitted destination.

why?

[Jon Marshall]

Hi

Have you changed the acl at all ?

On which interface have you applied the acl now ?

Jon

[ohassairi]

no i did not change the ACL it is applied on the same interface vlan122

[Jon Marshall]

Hi

You are denied getting to the 100.100.0.0 because you acl is denying this traffic. Any traffic coming back from 100.100.0.0 vlan will have a source ip address in the 100.100.x.x ranage but you are not allowing this in your acl.

I believe you can ping your gateway now because the icmp echo request gets through to the vlan 22 interface and then the icmp echo reply is simply switched back at layer 2.

HTH

Jon

[Richard Burts]

Jon

The ping is NOT switched back at layer 2. The gateway received the ping request and it generated a ping response (at layer 3). The reason that it works is an important - but not always clearly understood - aspect of Cisco access lists. An outbound access list will NOT affect any packet generated by the router itself, it only affects traffic that is passing through the router.

HTH

Rick

[Jon Marshall]

Rick

Many thanks for that. To be honest it didn't sound totally right after i wrote it as it would not have explained why icmp worked and no other traffic did so i should have amended it, apologies to original poster.

Didn't actually know that about outbound access-lists not affecting traffic originated by router. You learn a lot on NetPro.

Is that any interface on the router or is it just the interface on which the acl is applied ?

Thanks

Jon

Edit - actually scrap that last question as on reading your explanation again it is clear it is any traffic generated by the router.

[ohassairi]

thanks for all

but i think INbound ACL is applied to traffic generated by my 6k switch. so i must add an explicit entry to my hsrp traffic (multicast). i don t find this a pretty solution. can the ACL bypass the multicast traffic and be applied only to unicast traffic?

[Richard Burts]

Oussama

An inbound access list is applied to packets received by the interface from devices on that segment. An inbound access list would not affect any traffic generated by that switch. That is why you would need to add a permit for the HSRP address and the physical addresses if you want to be able to ping them from devices on that segment.

To answer the specific question that you ask here: no the ACL can not bypass the layer 3 multicast traffic and be applied to only layer 3 unicast traffic.

HTH

Rick

[ohassairi]

Hello Richard

You said : An inbound access list would not affect any traffic generated by that switch

But if I apply my ACL in this way:

ip access-list extended acl122

permit ip 10.122.0.0 0.0.255.255 100.100.0.0 0.0.255.255

permit icmp 10.122.0.0 0.0.255.255 10.122.0.0 0.0.255.255

deny ip any any log

!

int vlan 122

ip access-group acl122 in

ip address 10.122.100.252 255.255.0.0

standby 102 ip 10.122.100.254

then the hsrp traffic generated by the second core switch 10.122.100.253 and destinated to 224.0.0.2 is denied (I can see this in log) and the passive gateway (10.122.100.252) becomes active. I obtain 2 active hsrp peers!

y26w: %STANDBY-6-STATECHANGE: Vlan122 Group 122 state Standby -> Active

so I think the ACL do affect traffic generated by the switch.

to resolve this problem

I must apply my acl in this manner:

ip access-list extended acl122

permit ip 10.122.0.0 0.0.255.255 100.100.0.0 0.0.255.255

permit icmp 10.122.0.0 0.0.255.255 10.122.0.0 0.0.255.255

permit ip 10.122.0.0 0.0.255.255 224.0.0.2

that s why i asked if there is a way to resolve this problem by an other way.

regards

[hoogen_82 · Accepted solution]

ACL's on routers & switches will affect traffic originating from them, acl's on the other hand on PIX firewalls do not affect traffic originated from the PIX itself.

Cheers

Hoogen

[Richard Burts]

Oussama

Perhaps we have some confusion about terminology when we say traffic generated by the switch. There are 2 switches involved here, lets refer to switchA and switchB. My statement is that an inbound ACL on switchA will not affect any traffic generated by "that switch" (swichA). It seems to me to be extremely obvious that switchA will not see traffic that it generates as inbound traffic. It also seems obvious that switchA will see traffic from switchB as inbound - and that is the traffic that is causing the issue.

Yes indeed you need to add a permit in your inbound ACL to permit the traffic from switchB for HSRP.

HTH

Rick