Finally check after T2319 :
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Today
Yesterday
@dereckson While testing and modifying the GRE tunnel, it took so long on Ysul that SSH stopped responding, and we lost access to the machine.
Now, regardless of whether router-002 or router-003 is the primary router, the tunnel with Windriver works perfectly. However, there is still an issue with Ysul: the tunnel works when router-003 is primary, but it does not work when router-002 is primary.
Wed, Apr 29
Tue, Apr 28
Mon, Apr 27
We noticed that Windriver is unable to ping the public IP addresses of router-002 and router-003. However, GRE tunnel creation is successful, and tunnel connectivity works with router-002, although pinging its public IP is still unsuccessful.
When creating a GRE tunnel to the alias IP of ysul as an endpoint the tunnel is unpingable however when creating the GRE tunnel using the public IP of ysul, GRE tunnel responds well to ping.
I suspect that the problem might come from using an alias IP as GRE endpoint that might cause this as it suggest encapsulation/decapsulation issues
Sun, Apr 26
I created and tested a Salt reactor that listens for the carp/master event sent by the routers. For now, the reactor only runs a test command on Ysul and Windriver to confirm that the event is correctly received and that the master can trigger actions on those hosts.
Test to validate Salt event emission and reception on the master :
Fri, Apr 24
This issue is indeed not longer relevant.
Mon, Apr 20
Sun, Apr 19
I'm not sure this issue is still relevant as we're reinstalling Ysul in T2315.
Thu, Apr 16
Thu, Apr 9
Wed, Apr 8
I also came across OpenOSPFD, an OSPF routing daemon originally developed for OpenBSD, but it is marked as deprecated because it depends on an older CARP implementation.
I’ve noticed that Quagga is now deprecated and has been replaced by FRRouting (FRR), which is actively maintained.
Tue, Apr 7
Mon, Apr 6
Sun, Apr 5
Apr 3 2026
Apr 1 2026
Apr 1 14:03:22 router-002 kernel: carp: 2@vmx1: MASTER -> BACKUP (more frequent advertisement received) Apr 1 14:03:22 router-002 kernel: in_scrubprefix: err=65, prefix delete failed Apr 1 14:03:22 router-002 carp-ovh[98074]: Not MASTER -> exit
Mar 31 2026
Mar 30 2026
Apr 1 14:01:39 router-002 kernel: carp: 2@vmx1: BACKUP -> MASTER (master timed out) Apr 1 14:01:39 router-002 carp-ovh[98049]: Detected MAC on vmx1: 00:50:56:09:3c:f2 Apr 1 14:01:39 router-002 carp-ovh[98053]: Checking current state... Apr 1 14:01:39 router-002 carp-ovh[98057]: Checking IPs for MAC 00:50:56:09:3c:f2 Apr 1 14:01:39 router-002 carp-ovh[98061]: OVH returned: ['178.32.70.110', '51.68.252.230'] Apr 1 14:01:39 router-002 carp-ovh[98065]: VIP is already on correct MAC -> nothing to do
When router-003 (The MASTER) become unavailable :