pfSense English Support > CARP/VIPs

3rd interface not failing back...

(1/5) > >>

jakehathaway:
I have a QMOE connection between 2 data centers, location A and B. Each d/c is running a pf setup of 2 machines, PF1 and PF2. Each machine has 4 int, 1-WAN, 2-LAN, 3-QMOE, 4-PFSync.
Most traffic travels from A to B, not the other way. At some point the interfaces on location A failover from PF1 to PF2. Things seem fine. But when they failback to PF1, int-3 doesn't seem to failback, PF1 shows backup, PF2 shows master. But all traffic appears to be traveling to PF1 but the routes are not active (since it is in backup).
I have added a screen shot to show how PF1 looks when it is not working.
Thanks for any info.
Jake

sullrich:
Check the switch.  It is not passing multicast correctly.

Also search the forum.  This exact question has been asked (and answered) around 20 times.

jakehathaway:
We are looking into the multicasting. Sorry for duplicate post, but I searched for an hour looking for something similar and didn't find it.
If you know of one of them please link to it here, thanks.

Jake

Juve:
log on with SSH or directly from console (choose 8 ).
On the box not failling back, do a tcpdump like this:
tcpdump -i <ifname> -ttt -n proto CARP
where <ifname> is the name of the physical interface.

Do the same on the second box.

When all is working fine, you should see a trace showing multicast traffic directed to 224.0.0.18 (vrrp v2 multicast address), sourced from the IP address of the physical interface of the master node. On the slave node, you should see these packets too. When powering off  the master node the packets should then be sourced from the slave node with a higher advskew.


The four main problems you should encounter:

1) Misconfiguration: password, VHID or advskew problems, check it again.

2) Another device using VRRPv2 is using a VHID you are using, check you network devices or change VHID

3) You don't see master's packets on the slave node when doing the tcpdump (so the slave node has one or more interface in master mode). You have a communication error between the two machines. Check the switchs, the cables. Or look at problem 4 ;-)

4) You have a NAT rule, natting everything from a source network to a single IP address which IS NOT the interface address and which is in ANOTHER subnet. Should happen on WAN iface most of the time.








sullrich:
Stickying thread.

Navigation

[0] Message Index

[#] Next page

Go to full version