topic Re: vrrp matching access-list in Switches, Hubs, and Modems

vrrp matching access-list

Mauro Furini — Wed, 01 Dec 2010 10:57:54 GMT

after the dhcp... :)
i have forgotten a very little particular before to put the deny any any in the bottom of the acl...the VRRP statement to permit the conversation of two 6200.

I have experience with Cisco Hsrp, and the line I usually use is:

permit udp x.x.x.x 0.0.0.255 host 224.0.0.2 eq 1985

i suppose that the similar statement may be:

permit udp x.x.x.x 0.0.0.255 host 224.0.0.18

where 224.0.0.18 is the multicast address of the vrrp.
But with this configuration, i don't see the counter of the line grow up with the "sh statistics..." command, even if I apply this line in a VACL or in a RACL.
Any suggestion?

Re: vrrp matching access-list

Antonio Milanese — Wed, 01 Dec 2010 13:22:23 GMT

Hello Mauro,

VRRP use its own ip protocol so you need an extended ACL specifying ip protocol "VRRP" or as number 112.

Regards,

Antonio

Re: vrrp matching access-list

Mauro Furini — Wed, 01 Dec 2010 14:14:05 GMT

i tried this statement:

permit ip x.x.x.x 0.0.0.255 224.0.0.18 0.0.0.0
permit udp x.x.x.x 0.0.0.255 224.0.0.18 0.0.0.0 eq 112
permit tcp x.x.x.x 0.0.0.255 224.0.0.18 0.0.0.0 eq 112
permit udp x.x.x.x 0.0.0.255 224.0.0.18 0.0.0.0
permit vrrp x.x.x.x 0.0.0.0 224.0.0.18 0.0.0.0
permit vrrp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255

UNSSUCESSFULLY :(

Re: vrrp matching access-list

Antonio Milanese — Wed, 01 Dec 2010 15:31:09 GMT

Hello,

try to use a VACL:

access-list 101 extended permit 112 any host 224.0.0.18
access-list 101 extended permit 112 any host 224.0.0.2 eq 8888

the first should filter on ip protocol 112 that's the VRRP protocol number and the second deals with VRRP-E (now i do not recall if HP is using that on your switches) that runs on UDP/8888 and use the multicast address of 224.0.0.2.

Regards,

Antonio

Re: vrrp matching access-list

Mauro Furini — Wed, 01 Dec 2010 16:13:49 GMT

Thank's Antonio, I try immediately.
The first line is automatically changed in

permit vrrp 0.0.0.0 255.255.255.255 224.0.0.18 0.0.0.0 and never hit in the counter

In the second line i can't specify the port at the end of the statement and it will appear in this way:

permit vrrp 0.0.0.0 255.255.255.255 224.0.0.2 0.0.0.0

and the counter never increase.
:(

Re: vrrp matching access-list

Pieter 't Hart — Thu, 02 Dec 2010 10:52:32 GMT

disable the ACL and verify if VRRP is working at all.

show vrrp (statistics).

Re: vrrp matching access-list

Mauro Furini — Fri, 03 Dec 2010 08:09:03 GMT

The exhibit is the same:

CORE1

Vlan ID : 111
Virtual Router ID : 111
State : Master
Up Time : 36 days
Virtual MAC Address : 00005e-00016f
Master's IP Address : 10.9.130.6
Associated IP Addr Count : 1 Near Failovers : 3
Advertise Pkts Rx : 56 Become Master : 11
Zero Priority Rx : 0 Zero Priority Tx : 0
Bad Length Pkts : 0 Bad Type Pkts : 0
Mismatched Interval Pkts : 0 Mismatched Addr List Pkts : 0
Mismatched IP TTL Pkts : 0 Mismatched Auth Type Pkts : 0

CORE2

Vlan ID : 111
Virtual Router ID : 111
State : Backup
Up Time : 36 days
Virtual MAC Address : 00005e-00016f
Master's IP Address : 10.9.130.6
Associated IP Addr Count : 1 Near Failovers : 4
Advertise Pkts Rx : 3176605 Become Master : 15
Zero Priority Rx : 0 Zero Priority Tx : 0
Bad Length Pkts : 0 Bad Type Pkts : 0
Mismatched Interval Pkts : 0 Mismatched Addr List Pkts : 0
Mismatched IP TTL Pkts : 0 Mismatched Auth Type Pkts : 0

Re: vrrp matching access-list

Pieter 't Hart — Fri, 03 Dec 2010 08:51:33 GMT

On what point do you apply the ACL?
try the port that connects the 6200's, not the vlan interface.
You may need to reconfigure the ACL and apply it to the conencting interface (port not vlan).

Beware: the packets do not "traverse" the 6200 (port-in => port-out), but originate from the first 6200 and terminate at the other 6200 (first -> out-only; second -> in-only).

Re: vrrp matching access-list

Mauro Furini — Fri, 03 Dec 2010 11:02:53 GMT

I can try, but it cannot be the final solutions, cause i need to filter every vlan.

However i found a little (my) mystake. I applied the test acl only in the core1 switch, but not in the core2.
Tomorrow i applied correctly the acl in the second core switch in the vlan context, and it works great.
The statement is:

permit vrrp x.x.x.x 0.0.0.255 224.0.0.18 0.0.0.0

The anomaly is that the same acl in the core1 switch doesn't work...how could?
Thanks

Re: vrrp matching access-list

Antonio Milanese — Fri, 03 Dec 2010 12:36:35 GMT

Hello Mauro,

ok now i've a better understanding of your problem..

Peter correctly write:

>Beware: the packets do not "traverse" the 6200 (port-in => port-out), but originate from the first 6200 and terminate at the other 6200 (first -> out-only; second -> in-only).

VRRP failure detection depends on missed (3 times) missed periodic advertisement sent by the master in multicast mode.

CORE1 is the master now so it is "beaconing mode only" and so RACL or inbound VACL do not filter traffic since, how you recall from DHCP =) post, "it's generated from the switch itself"

On CORE2 an inbound VACL it's working as expected.

Try to force CORE2 election and i think that counters will increase as well.

Regards,

Antonio

Re: vrrp matching access-list

Pieter 't Hart — Fri, 03 Dec 2010 12:37:32 GMT

How did you test?
did you failover the vrrp-master?

the master sends hello packets
After a master has been selected, the backup only receives and sends nothing.
So no counter will increment from that...

Re: vrrp matching access-list

Mauro Furini — Fri, 03 Dec 2010 14:22:14 GMT

Goal!
I make the test forcing the failover and I see the packet tracked in the acl of the CORE1.

My fault was I expected a Cisco like behavior, where in both core switch I see hsrp packet match the acl.

Thanks a lot