Carp is flooding my network with VRRP packets (Yes, that doesn't make sense)
-
Ahhh!!!! Doh!! You are right the arp reply will have a source of the physical nic sending it on the frame, but the info for the vip will be contained in the reply!
Thanks! Brain fart on my end for sure ;) Your packet captures very helpful in knocking out the stupid fog ;)
But even with downstream switches you can filter the those multicast packets from end point ports, and only allow it to the switches and the carp interfaces if he is worried about the "flooding" ;)
-
Certainly. As long as the switches see the CARP MAC so they can stick it in the table for the ISL/trunk port. Else they will flood it every time they see it. My hunch is stuff would break.
-
Hi
One Packet per Second is normal?
i have 16 Packets per second(in one vlan so if i have 20 VLANS, i have 20*16 Packets only vor VRRP) and little netgear switches have problem to handle this traffic.
Is this a failure in my network or normal and i must filter it?
Thank you
-
i have 16 Packets per second(in one vlan so if i have 20 VLANS, i have 20*16 Packets only vor VRRP) and little netgear switches have problem to handle this traffic.
Ok, so that would be 320 pps. Even a cheap Netgear switch is rated at 1,448,000 pps. To repeat Derelict, don't hassle it.
-
If they are all different CARP VIPs then that is how your network is designed so you need switches that can deal with it.
I have a hard time believing that any switch (even a Netgear) can't handle 320 CARP advertisements per second.
-
The switch doesn't really care about the frames being CARP.
If it's a "dumb" switch it only looks at the lowest bit of the first byte of the destination-mac: the multicast-bit.
–> a dumb switch can't actually distinguish a broadcast-frame from a multicast-frame (broadcast is just a special multicast-address)The more intelligent switches can analyze the multicast frames a bit more in depth (usually on L3 with IGMP), but as long as it's still a L2 multicast frame it doesn't really care if it's CARP or something else.
-
If they are all different CARP VIPs then that is how your network is designed so you need switches that can deal with it.
No, and this is the only reason why i am so worried, i have multiple Packets (same VRID) in each VLAN per second and i read somthing about pfsense CARP send only one packet per second.
Can it be that this happening because i have a LCAP Lagg(1 pfsense has 4 cable connected on two Stack Switches, so both pfsense are connected on two switches with 8 cables)?Thank you
-
Post a packet capture of this please.
advbase 1 advskew 0, the default on a primary node, will result in about 1.003 seconds between advertisements PER CARP VIP.
If you are seeing more than that you are probably seeing some incorrect flooding or looping in your switching gear.
If you only capture CARP in Diagnostics > Packet Capture CARP will be decoded. If you need to subsequently vire a capture just select CARP again and click View Capture.
Wireshark can be coerced to decode CARP instead of VRRP. Right-click a VRRP packet and select Decode As. Set protocol 112 to CARP there.
-
Special, pfsense gives me one packet per second but if i capture with a client i have multiple packets per second.
I add both capture as attachment, i hope this helps. -
You don't happen to run 12 CARP IPs on the same ID do you?
-
Where was the CARP.pcap capture taken?
Where was the CARP_Local.pcapng capture taken?
You can see by the ip.id those packets are duplicated.
I still suspect something in your switching gear somewhere.
-
You don't happen to run 12 CARP IPs on the same ID do you.
No, only WAN has the same vhid because of IP Alias(vhid 13).
All vlan has a different vhid.
Where was the CARP.pcap capture taken?
With Pfsense on Management Interface (vhid 4) with Diagnostics -> Packet Capture
Where was the CARP_Local.pcapng capture taken?
With my Computer, also in the vhid 4 Network but 4-5 Switchs between Computer and pfsense
You can see by the ip.id those packets are duplicated.
I still suspect something in your switching gear somewhere.Yeah…very special
-
Well, I know what it's not… pfSense.
It's always the switching layer, bro.
