How can I filter HSRP to access ports? Or limit to trunked ports?

[lonelyadmin]

I have a relatively simple setup.

4500X L3 switches connected over trunks. Each L3 VLAN has a standby IP defined with a different priority on each switch. That standby IP is the gateway for that VLAN. 2960X L2 switches attach to the L3 switches with no L3 interface definitions (well there is one L3 vlan for VTP and other default VLAN type things to use, but no L3 for users interfaces). HSRP seems to function fine when a switch is rebooted or whatever. What I'd like to do is allow HSRP traffic where it is needed and block where it isn't. In my setup, allowing it on the trunks between switches and blocking it on every other interface seems to be the most sensible. What's the best recommendation for achieving that? I don't want to possibly affect any other multicast traffic by blocking HSRP broadcast traffic. 

Using wireshark on any of the interfaces I can see the HSRPv2 traffic sourced from the .2 or .3 IP addresses sent to 224.0.0.102

4500X's

!4500X_primary
interface Vlan10
 description users10
 ip address 10.1.10.2 255.255.255.0
 ip access-group VLAN_10_IN in
 ip access-group VLAN_10_OUT out
 ip helper-address 10.10.10.10 
 standby version 2
 standby 1 ip 10.1.10.1
 standby 1 priority 110
 standby 1 preempt
 standby 1 authentication md5 key-string random_string_cnbreu timeout 5
 no autostate
!
!4500X_secondary
interface Vlan10
 description users10
 ip address 10.1.10.3 255.255.255.0
 ip access-group VLAN_10_IN in
 ip access-group VLAN_10_OUT out
 ip helper-address 10.10.10.10 
 standby version 2
 standby 1 ip 10.1.10.1
 standby 1 priority 95
 standby 1 authentication md5 key-string random_string_cnbreu timeout 5
 no autostate
!

[Seb Rupik]

Hi there,

you have already implemented HSRP authentication between your two 4500, so have prevented rogue devices from participating in the process.

If you wanted to go a step further, a defence I have seen at one sites was to implement ACLs at the access-layer on every edge switchport denying traffic destined to common multicast groups (OSPF, EIGRP, etc) of which the HSRP group you mention was one.

cheers,

Seb.

[Sebastian Fernandez · Accepted solution]

Hello @lonelyadmin 

Ideally in this setup STP should be enough to prune vlans on unwanted ports. But if you really want to go deeper, enable IGMP snooping because HSRP uses multicast hello on 224.0.0.2. IGMP snooping should be able to control who gets what for the multicast, but please be cautious about it if you are running other multicast applications. I would not generally recommend it (but only if you are a curious kind like me :) ). 

But if you really want to go granular and control what multicast traffic gets forwarded.  I would choose to configure port based ACL on switches. Port ACLs are exactly like router ACLs but are supported on physical interfaces and can be configured on Layer 2 interfaces on a switch. But keep in mind that Port ACL only supports inbound traffic filtering. Port ACL can be - standard, extended, and MAC-extended.

Processing of the Port ACL is similar to that of the Router ACLs; the switch examines ACLs associated with features configured on a given interface and permits or denies packet forwarding based on packet-matching criteria in the ACL.

Most important Part: When applied to a trunk port, the ACL filters traffic on all VLANs present on the trunk port. When applied to a port with voice VLAN, the ACL filters traffic on both data and voice VLANs.

The best part with port ACL is that it can filter IP traffic (using IP access lists) and non-IP traffic (using MAC access list). Both types of filtering can be achieved—that is, a Layer 2 interface can have both an IP access list and a MAC access list applied to it at the same time.

But honestly - I wouldn't choose any of the above unless I have a good reason to filter HSRP.

Please mark this post if you find it useful.

- 

Sebastian

[Jon Marshall]

Hi Sebastian

My understanding was the IGMP snooping will not filter 224.0.0.x addresses ie. they are always flooded regardless. 

Jon

[Sebastian Fernandez]

Thank you for correcting that @Jon Marshall. I went to cross check on the basics and yes you are right link local multicast group will not be controlled by IGMP snooping. Let me also edit that post so that it does not mislead future readers. 

Regards,

Sebastian

[Sebastian Fernandez]

Thank you for correcting that @Jon Marshall I went to cross check on the basics and yes you are right link local multicast group will not be controlled by IGMP snooping. Let me also edit that post so that it does not mislead future readers. 

Regards,

Sebastian

[lonelyadmin]

My only reason to filter it is that it doesn't need to be there. I can't think of any reason why an end user would need to receive HSRP traffic.

Would blocking the src/dst mac and IP block any other traffic or is it specific to that particular instance of HSRP?

Can you show an example of how to block HSRP on the access ports?

Thanks!