6900 and block incoming HSRP

[andgus]

Hi
I have a OS-6900-X40 switch running SVLAN with a linkagg to one of our customers cisco routers.
The customer has about 400 vlans with HSRP configured on their Cisco routers and I don't want this traffic flooded in to the linkagg between me and the costomer. About 800 (400 vlans * 2) packets every seconds.

Have tried different policies but the 6900 doesn't block the HSRP packets. Does the 6900 switch process the HSRP packets before the policy triggs.
The linkagg are ports 1/39 and 1/40

policy port group block-hsrp 1/39-40
policy condition block-hsrp source port group block-hsrp destination udp-port 1985 destination ip 224.0.0.2
policy action block-hsrp disposition drop
policy rule block-hsrp precedence 666 condition block-hsrp action block-hsrp log

or

policy port group block-hsrp 1/39-40
policy condition block-hsrp source port group block-hsrp destination ip 224.0.0.2
policy action block-hsrp disposition drop
policy rule block-hsrp precedence 11000 condition block-hsrp action block-hsrp log

I can see in the qos log that the policy is trigged and packets dropped!!!

Can anybody help me with this issue?

Regards
Anders

[andgus]

Forget to say. With Wireshark, I can see the HSRP hello packets on other ports in the same svlan in the 6900.

Simple diagram.. =)
Customer routers(HSRP) ---> 6900(HSRP policy) ---> Wireshark. HSRP Hello packets

[silvio]

Hi,
If you would like to block this traffic at the whole 6900 than you can try without the port group. I'am not sure about linkaggg in your case.
So firstly I would test only the condition with destination IP. Also you can check the matched packets with logging
For it use "policy rule block-hsrp log" and than "show qos log".
Also you can try not to use the destination ip - maybe the destination port 1985 (you have to check in wireshark if tcp or udp) is more successfull for you.

I wonder about your info, that you can see the matches of the dropped packets (I assume with "show active policy rules") but otherwise you still see HSRP packets on the other site of the switch. Normaly if you see the match than the policy will handled correctly. You are sure that there is no other way for the packets?
For testing this you can create same policy like before f.e. with Allow-action but with log. Than you can check where the packets are received (the ports).
regards
Silvio

[andgus]

Thanks for the answer,

I have tried blocking HSRP hello packets with:
- A policy without port group.
- A policy blocking dest ip 224.0.0.2 and udp port 1985.
- A policy with udp port 1985
- A policy with the destination mac 01:00:5e:00:00:02 (The multicast address 224.0.0.2 macaddress).

Nothing seems to block the hello packets from traversing the switch.
HSRP v1 use the all routes multicast group 224.0.0.2 as destination. Maybe the switch have to switch these packets before the policy drop the packets. I am 100 % sure there is no other way for the packets to reach the other side of the switch.

I have the same SVLAN configured on the uplink linkagg to the customer and 16 other ports where I can see the hello packets origin from the customer routers.
I can see this with Wireshark that the packets are seen on the other side of the switch.
I also see this in the qos log (~ 1000 per second):

9/25/17 8:55:00 [@01:00:00] rule 'block-hsrp' matched:drop
9/25/17 8:55:00 DoubleTagged. 802.1p 0 cvlan 265 c802.1p 6
9/25/17 8:55:00 svlan 103 port 1/40
9/25/17 8:55:00 MAC F8:66:F2:14:39:C1 -> 01:00:5E:00:00:02
9/25/17 8:55:00 TOS 0xc0 (UDP) 172.27.9.62:1985 -> 224.0.0.2:1985
9/25/17 8:55:00 [@01:00:00] rule 'block-hsrp' matched:drop
9/25/17 8:55:00 DoubleTagged. 802.1p 0 cvlan 624 c802.1p 6
9/25/17 8:55:00 svlan 103 port 1/40
9/25/17 8:55:00 MAC F8:66:F2:14:39:C1 -> 01:00:5E:00:00:02
9/25/17 8:55:00 TOS 0xc0 (UDP) 10.15.20.254:1985 -> 224.0.0.2:1985
9/25/17 8:55:00 [@01:00:00] rule 'block-hsrp' matched:drop
9/25/17 8:55:00 DoubleTagged. 802.1p 0 cvlan 509 c802.1p 6
9/25/17 8:55:00 svlan 103 port 1/40
9/25/17 8:55:00 MAC F8:66:F2:14:39:C1 -> 01:00:5E:00:00:02
9/25/17 8:55:00 TOS 0xc0 (UDP) 10.8.41.254:1985 -> 224.0.0.2:1985
9/25/17 8:55:00 [@01:00:00] rule 'block-hsrp' matched:drop
9/25/17 8:55:00 DoubleTagged. 802.1p 0 cvlan 563 c802.1p 6
9/25/17 8:55:00 svlan 103 port 1/40
9/25/17 8:55:00 MAC F8:66:F2:14:39:C1 -> 01:00:5E:00:00:02
9/25/17 8:55:00 TOS 0xc0 (UDP) 10.10.16.254:1985 -> 224.0.0.2:1985

Dropped! but switched!!

Regards
Anders

[silvio]

very strange....
224.0.0.2 is also IGMPv2 leave message. Maybe this is the reason ....
have you multicast switching enabled? If yes than try with disabled MC.
I think it will be helpfull if you open a ticket at Alcatel for this very interesting issue.
regards
Silvio

[andgus]

Thanks for the tips.

We don't have multicast switching or routing enabled on the switch.
I tried the policy on a older 6850 and a 6450 and it works lika a charm. The 6900 has QinQ configured and I even try this policy without success:
"policy condition block-hsrp destination port group block-hsrp inner source-vlan 556 destination ip 224.0.0.2 destination udp-port 1985"

I will make a setup in my lab with single or double tagged traffic to make sure that the policy works on both. Hm.. Have a feeling the issue has something to do with QinQ.

I have opened a ticket at Alcatel.

Regards
Anders

[andgus]

Update.

The policy doesn't work on 6860 and 6900 switches with or without QinQ.
Same policy does work with 6450 and 6850 switches!! Just tested in my lab.

Now I'll have to wait for Alcatel to response..

Regards
Anders

[silvio]

thanks for inform us about your tests. Please post us the solution from Alcatel.
regards
silvio