How to filter unnecessary Broadcast Messages? (like VRRP, STP)

[Stefan Priebe]

Hi!

First a short netzwork plan:
Uplink 1 Uplink II
| |
[Foundry]----------[Foundry]
| |
| |
[HP 2824]----------[HP 2824]
| |
| |
-----[HP 2650]-----
|||
MULTIPLE SERVERS

We use VRRP on the Foundry Bigiron for IP failover and RSTP in the whole network.

Now all these broadcastmessages are reaching the servers at the HP 2650 too. So i would like to know if it isn't a security risk and if there is a way to filter them. At the moment it is about 2GB per day per port at the HP 2650.

thanks
Stefan

[Stefan Priebe]

I forgot to click retain format. So here the map again:
Uplink 1 Uplink II
| |
[Foundry]----------[Foundry]
| |
| |
[HP 2824]----------[HP 2824]
| |
| |
-----[HP 2650]-----
|||
MULTIPLE SERVERS

[Tijl van der Steeg]

For RSTP you can use bpdu-filtering
port a5 bpdu-filter etc

Not sure about VRRP.

[Stefan Priebe]

oh yes i forgot about bpdu-filter you're right. But the most problem are the VRRP packets. I thought there must be a filter like block all broadcasts except for ARP or so.

[Pieter 't Hart]

From some VRRP-document:

The master virtual router sends VRRP advertisements to other VRRP routers in the same group. The advertisements communicate the priority and state of the master virtual router. The VRRP advertisements are encapsulated in IP packets and sent to the IP Version 4 multicast address assigned to
the VRRP group. The advertisements are sent every second by default; the interval is configurable.

- So this is multicast, not broadcast.
- you can configure the interval
- you may be able to split into multiple VRRP-groups to separate traffic on the server vlan from other vrrp traffic.

[Tijl van der Steeg]

Cheers I was searching for configuring the interval as well. 5 virtual points :P

[Mohammed Faiz]

So if IGMP was configured on that VLAN that would mean the VRRP advertisements would not be broadcast, yes?

[Pieter 't Hart]

Hi Mohammed,
sometimes it's difficult to use the right terminology.
- So this is multicast, not broadcast
Here the document means TCP/IP-multicasts.

The packet is sent to a TCP/IP multicast address but as there is no entry in the mac-address table of the switch, it wil be sent (flooded not broadcast) to all ports.
IGMP (snooping) is used to prevent a switch from "flooding" a packet (not broadcast) to all ports, but only forward the packets to ports that have subscribed to the corresponding multicast group.

does this help?

[Stefan Priebe]

thanks - how do i define a multicast group on HP 2824? And does this also affects STP or only VRRP?

[Pieter 't Hart]

STP is a layer-2 protocol (mac-based)
VRRP is a layer-3 protiocol (ip-based)

so you need different solutions for both protocols.

[Stefan Priebe]

OK so for STP bpdu-filter is the solution and for VRRP a multicastgroup or IGMP or multicastgroup + IGMP?

[Pieter 't Hart]

As all your switches have multiple links between them, you NEED spanning-tree on these ports and must NOT enable bpdu-filtering on these ports.

BPDU filter affects incomming packets on a port not packets sent to the port.
A server on a normal access port should not send BPDU packets a filter thus will have no effect.
So how do your servers receive BPDU packets? How are your server ports on the 2650 configured?

The problem may lie deeper like coexistence between STP, PVSTP, MSTP. Resulting in more STP-packets than neccessary.
I think the foundry may use PVSTP (per vlan STP) where the procurve will use MSTP (multiple instance STP).
RSTP is the "rapid" version and may occur on all these vaiants.

[Stefan Priebe]

No all devices are working in RSTP mode - as PVSTP is not supported by HP.

The ports where the servers are were receiving BPDU Packets from the HP 2650 switch - what is correct cause the switch send these packets to all ports except i configure a BPDU filter for the ports where the servers are connected. That is what i understood. So this is fixed with BPDU-Filter for the ports where no other switch is connected.

So my only problem which is left are the VRRP pakets. And i would like to know if i need only a multicast group or multicast plus IGMP?

Sorry it's not so easy for me to explain it in english.

[Stefan Priebe]

@Pieter 't Hart
could you please answer my last question? That would be really nice.

[Pieter 't Hart]

The answer is allready there (7-oct 8:57).
You'll need both.

The multicast group is configured between the devices that really communicate using multicast.
The source sends packets to a multicast-adress that basically will be sent to all ports in the vlan, as this mac-address is not bound to a switch-port.
IGMP (snooping) is configured on the switch(es), so the above behaviour is reduced to ports that actually joined the multicast group.
The switch does this by listening to (snooping) the IGMP join packets.

[Stefan Priebe]

as i don't want to route multicast - isn't it easier using
ip igmp blocked
command than IGMP on the HP switches? Or is IGMP def. the way to go.

[Stefan Priebe]

mhm i'm still receiving mcast traffic on port 10:

HP 2610-24 B-2(vlan-1)# show ip igmp 1 config

IGMP Service

VLAN ID : 1
VLAN NAME : DEFAULT_VLAN
IGMP Enabled [No] : Yes
Forward with High Priority [No] : No
Querier Allowed [Yes] : Yes

Port Type | IP Mcast
---- --------- + --------
1 | Blocked
2 | Blocked
3 | Blocked
4 | Blocked
5 | Blocked
6 | Blocked
7 | Blocked
8 | Blocked
9 | Blocked
10 | Blocked
11 | Blocked
12 | Blocked
13 | Blocked
14 | Blocked
15 | Blocked
16 | Blocked
17 | Blocked
18 | Blocked
19 | Blocked
20 | Blocked
21 | Blocked
22 | Blocked
23 | Blocked
24 | Blocked
25 | Blocked
26 | Blocked

[Pieter 't Hart]

>>> mhm i'm still receiving mcast traffic on port 10: <<<
how do you detect this?
you've got a network analyzer connected to this port?

>>> isn't it easier using ip igmp blocked <<<
igmp is NOT all multicast traffic!
igmp is a protocol to control muticasts (to routers).
if you block the igmp traffic, the mutlicasts source still sends the multicast messages out within the vlan!
and the switch cannot use igmp-snooping!

so the effect of blocking igmp is more negative than positive.

[Stefan Priebe]

> you've got a network analyzer connected to
> this port?
yes => wireshark

>>> isn't it easier using ip igmp blocked
>>> igmp is NOT all multicast traffic!
mhm OK - but if igmp is active it works for ALL multicast traffic? Cause VRRP is a known protocol and in switchdocumentation is written IGMP works not for known IPs... but i don't want that the customers see the VRRP pakets.

[Pieter 't Hart]

>>> but if igmp is active it works for ALL multicast traffic? <<<
If you talk about igmp-snooping NO.
There are "just" multicast messages and multicast GROUPS. igmp concerns multicast-groups! VRRP does NOT!

>>>
Cause VRRP is a known protocol and in switchdocumentation is written IGMP works not for known IPs... <<<
I don't understand what you mean here...

>>> but i don't want that the customers see the VRRP pakets. <<<
Is this really a problem?
Then you must isolate the redundant routing paths from the subnets of the customers.
A may do this by configuring the 2650 with routed uplinks and let it route to a separate vlan/subnet where the servers reside. this way the 2650 can see the vrrp packets but never forwards (routes) vrrp-packets to the servers. The customers only communicate to the 2650's address in this subnet.

[Stefan Priebe]

mhm OK so i can't filter these vrrp packets :-(

Also at the moment a customer server send out multicasttraffic and floods all other port - as we read out the paketcounters all other customers have to pay for the flood one customer created. So i wanted to stop the mcast traffic.

[Pieter 't Hart]

in that case you may consider going even further than my last suggestion.

create a vlan/subnet for each customer.
let the network (eg the 2650) do basic routing between these subnets.
Don't configure multicast routing!
Multicasts will stay contained within a single customers vlan.

[Stefan Priebe]

OK so there is no way around it? My idea was to simply block multicast traffic as it is not needed and is it easier to do this than creating VLANS for each customer