Netgate 7100 with HA update issues
-
@w0w @stephenw10
very weird stuff here, I did a tracert and ping and I had internet....
Also the 24.03 update was visible and I could install it...Now it has rebooted, the internet is gone again...
So I need to wait another day before it comes back.... -
Did you check the default route?
-
@stephenw10 where do I check this, I have no static routes setup
-
@stephenw10 said in Netgate 7100 with HA update issues:
Otherwise check for a default route in Diag > Routes.
Also check that the default route shown there is valid/expected assuming it is there.
-
@stephenw10 NO idea how that actually works but here it is:
-
Ok, that looks good.
Can you test a ping to, say, 8.8.8.8 from the command line on that node?
Whilst that ping is running check the state table in Diag > States. Filter it by 8.8.8.8 and make sure the outbound state exists and on the correct interface.
-
@stephenw10 Well then there is no reply, in the states it says:
-
Hmm, what is that connected to? How are the other NICs connected?
I assume the primary node can ping everything OK?
-
@stephenw10 the primary node can ping perfectly
The WAN nics are connected to a patchpanel and get a direct ip from the hosting in the datacenter.
WAN on pri;ary is .35
WAN on secondary is .36
Virtual WAN for HA and how we go out is .33 (if we are on a server and do whatismyip.com we see .33 ) -
Hmm. Traffic just disappearing like that I start to suspect something odd upsteam.
Check on the primary node to see if replies are somehow being incorrectly sent to it. So you would see that in the firewall log there unless you have rules to pass it.
I assume the CARP VIPs are all failing over correctly?
-
I do see this on the firewall, don't know what that is:
I already added that to the rules, but it does not help.
I do seem not to be able to ping the other SYNC side:
-
@stephenw10 nevermind the ping, I solved that by a rule
-
I wouldn't expect to see CARP multicast traffic on the SYNC interface. There shouldn't normally be a CARP VIP on it.
I also wouldn't expect that to make any difference to secondary connectivity though.
Try pinging something from the secondary and then running a pcap on the primary WAN for that same target and see if packets are coming back incorrectly there.
-
@stephenw10 I sent you a chat