ACL behaviour on HSRP standby SVI

[mo shea]

I have been reading several posts in this forum to try to understand ACL  behaviour on a standby HSRP 6500, I would be glad to get this cleared.

Here is the scenario...

I have two 6509 running HSRP for all Vlans...

I created VLAN 100 with standby ip address 192.168.1.129 255.255.255.128

Active 6509 (SW01) ip is 192.168.1.130/25, priority 120

Standby 6509 (SW02) ip is 192.168.1.131/25

I have created a DHCP server on the standby 6509 only on the same VLAN 100 with a defaul router of 192.168.1.129 (i.e. the hsrp vip). I connected a pc directly to the ethernet port on the standby 6509 and put it under VLAN 100 and it obtained its ip 192.168.1.200 from the ios dhcp.

Now I want to restrict this PC (and any other on its subnet) to access only a remote server 172.168.10.10 and nothing else. I have created the following access list, allowing traffic to the remote server, ospf and hsrp updates,ios dhcp...

Extended IP access list SWRES

       10 permit ospf any any log (172 matches)

       20 permit ip any host 172.168.10.10

       30 permit ip any host 224.0.0.2

       40 permit udp any host 255.255.255.255 eq bootpc

       50 deny ip any any log (52 matches)

I have applied this ACL on both the 6509s under interface VLAN 100

ip access-group SWRES in

1. When I ping different subnets on the 6509s from the PC, I still receive icmp replies although I expected the acl to pass traffic destined for the remote server only. I do get deny log messages on the Active 6509, but not on the standby 6509 where the PC is connected. I hope someone can explain this.

2. Is permitting bootpc in the acl enough for IOS  DHCP server and client operation? Do i need to explicitly permit access to the defaul-router configured in the DHCP, which happens to be the VLAN 100 gateway ip and hsrp vip as well (192.168.1.129)

3. I do get deny logs on both the 6509s from the PC trying to access the local VLAN 100 broadcast address on ports 137, 138.

%SEC-6-IPACCESSLOGP: list SWRES denied udp 192.168.1.200(137) -> 192.168.1.255(137)

Are these related to dhcp operation or dns?

All help is appreciated

[rsimoni]

Hi,

I would suggest to address one thing at a time or else there will be too much confusion. Let's start from 1.

First notation is kind of expected deny logs on the standby switch (even if the pc is connected there) as the switch with is routing traffic out from vlan 100 is the active one, so your L3 ACL will be matched only on the standby active device. The standby switch will only bridge traffic at l2 to the active. By the way, ACL on this platform is not a good idea as it causes high cpu utilization; to troubleshoot this issue is ok but after that remember to remove it.

What i don't get is what you wrote when you said that you get deny logs (which seems to indicate that traffic is filtered) but you also receive icmp replies from the hosts you ping. Can you clarifiy?

Also, can you add a speficic entry denying icmp traffic at the beginning of your acl and see if this changes something?

regards,

Riccardo

[mo shea]

Thanks for the reply...

To clarify my point, I had two telnet sessions running at the same time, one for each 6509 switch. I was able to see that ospf permit matches were reported by the logs on each of the switches, but when I ping another subnet from the PC,only the active hsrp 6509 reports denied icmp logs, but I see nothing on the standby 6509, unlike ospf matches that are reported on both the 6509s.

Since you have mentioned that this is  not the best setup, what would you recommend, using a port acl or moving the pc to an edge switch and filter on the uplink to the 6509. I would go for the port acl on the 6509, but I hope that the ios supports layer 2 port acls, because I have another setup using 2 vss 6509 12.2sxh ios in another site and layer 2 port acls are not supported on that ios version.

Thanks again

[rsimoni]

Hi,

but when I ping another subnet from the PC,only the active hsrp 6509 reports denied icmp logs, but I see nothing on the standby 6509, unlike ospf matches that are reported on both the 6509s.

As I wrote you cannot see any hit on the standby 6509 as it is NOT routing the traffic from vlan 100 to other vlans. So this is perfectly expected and not an indication that something is wrong.

Since you have mentioned that this is  not the best setup, 

I did not say that. I just said that since this platform is supposed to hardware switch the traffic the presence of the log statement in a ACL might cause High CPU utilization as it forces the data-plane to punt the packet hitting an ACE with the log statement to the RP (CPU) and this is not good.

10 permit ospf any any log (172 matches)

Having said this, is the ACL working as expected or do you think there is something weird yet? [still discussing of issue 1.]

Riccardo

[mo shea]

Thank you for the explanation

Riccardo Simoni wrote:
As I wrote you cannot see any hit on the standby 6509 as it is NOT routing the traffic from vlan 100 to other vlans. 

Is this behaviour similar for ospf on HSRP? because I am getting ospf hits on both the 6509, unlike icmp.

Riccardo Simoni wrote:
Having said this, is the ACL working as expected or do you think there is something weird yet? [still discussing of issue 1.]

I did not have a chance to add an icmp deny on the svi. But from your evaluation of my ACL elements and its direction on the svi, does it serve the purpose I intend it to  do, i.e. allow users on VLAN 100 to access the remote server only 172.168.10.10, while denying all other traffic, icmp, ip etc. to any other destination?

Thanks again for your feedback

[rsimoni · Accepted solution]

Is this behaviour similar for ospf on HSRP? because I am getting ospf hits on both the 6509, unlike icmp.

OSPF and HSRP packets are not routed outside the vlan they are generated, therefore it is expected that you see hits on both routers as they are packets coming from the same vlan destined to the RP of the router.

I did not have a chance to add an icmp deny on the svi. But from your evaluation of my ACL elements and its direction on the svi, does it serve the purpose I intend it to  do, i.e. allow users on VLAN 100 to access the remote server only 172.168.10.10, while denying all other traffic, icmp, ip etc. to any other destination?

yes, this ACL achieves your goal (the deny icmp ACE was just meant to be added for troubleshooting purposes; since we clarified the behaviours you saw there is no point in adding it).

Riccardo

[mo shea]

I will try adding the deny icmp ACE and report the results, hopefully it will explain why the host is still able to ping other subnets it's not supposed to. Will report the results then.

Thanks a lot

[mo shea]

Thanks for confirming the ACL result. It's fine now. It turned out that a colleague of mine had placed a permit statement, for testing, that allowed hosts to ping other subnets, hence the ACL acted funny. But now all is good

Thanks again.