FRR BGP over IPsec , when HA happens (slave-> master, master ->slave)
-
@mcury nice !
Still requires an admins interaction BUT the concept works.
I see no reason why it cant be automated. -
@michmoor said in FRR BGP over IPsec , when HA happens (slave-> master, master ->slave):
Still requires an admins interaction BUT the concept works.
I see no reason why it cant be automated.Exactly, a little intervention but nothing that takes a lot of time, tick two things, save and that is it. :)
I'll start to plan a script, something to check, am I the primary, if so, enable frr, something like that.
-
@mcury maybe the script can check the CARP status? So check if i am Master?
Also a secondary check as well. Maybe ping the SYNC interface of the neighbor. If its down and if you are master than bring up FRR.So high level
Every GUI change in FRR needs to be sync'd to the standby
The standby needs to monitor CARP status
The standby needs a reliable detector to know it should take over routing - pings the SYNC interface of the master. -
@michmoor said in FRR BGP over IPsec , when HA happens (slave-> master, master ->slave):
@mcury maybe the script can check the CARP status? So check if i am Master?
Also a secondary check as well. Maybe ping the SYNC interface of the neighbor. If its down and if you are master than bring up FRR.Yes, I'll have to learn carp CLI commands to check the status, any help is much appreciated because I'll probably need to parse the output to get what we need..
Then, set up some ifs and elses in the master and in the backup.
A ping test would also help this checking..
And lastly, a cron job in both nodes -
@mcury I got you. Im researhing now.
-
@michmoor said in FRR BGP over IPsec , when HA happens (slave-> master, master ->slave):
@mcury I got you. Im researhing now.
I'm stuck right now, unfortunately.
I'll be checking later today or perhaps during the weekend.But I think we will nail it, only a matter of time
-
@michmoor said in FRR BGP over IPsec , when HA happens (slave-> master, master ->slave):
hey guys , as i've been following with much interest this thread:
Every GUI change in FRR needs to be sync'd to the standby
The standby needs to monitor CARP status
The standby needs a reliable detector to know it should take over routing - pings the SYNC interface of the master.i've been playing a with conf's coptions myself here ,there is an option under FRR->Global Settings-> CARP Status IP , by default this is set to none , but if its set to the IP of the CARP then: Used to determine the CARP status. When the CARP vhid is in BACKUP status, FRR will not be started.
unfortunattely for me i can't test it , cause one of my nodes was fried.(waiting on a replacement this week or the next one)
hope that helps ...
-
@vinns said in FRR BGP over IPsec , when HA happens (slave-> master, master ->slave):
but if its set to the IP of the CARP then: Used to determine the CARP status. When the CARP vhid is in BACKUP status, FRR will not be started.
Thanks for the insight, I actually tried that but FRR remains active in the backup node.
-
I don't know what I did, but now it is working.
Routes, HA and everything... FRR is now not running on the secondary node.
My guess is that you need a reboot of both nodes after configuring FRR in HA mode, not sure yet what happened, but yes, it is working with that option (CARP Status IP).Good news :)
-
@mcury i can confirm the same. tested. seems okay, after selecting that CARP STATUS IP option.
one more thing i was not able to replicate , the FRR configs even though its in HA mode , does not propagate to the slave ( my slave node was fried a couple of weeks ago , so i had a new one bought) put them in cluster , but the only thing that did not propagate over , was the FRR confs... which is strange....any ideas?
-
@vinns said in FRR BGP over IPsec , when HA happens (slave-> master, master ->slave):
one more thing i was not able to replicate , the FRR configs even though its in HA mode , does not propagate to the slave ( my slave node was fried a couple of weeks ago , so i had a new one bought) put them in cluster , but the only thing that did not propagate over , was the FRR confs... which is strange....any ideas?
Same problem here, It doesn't propagate the configuration to the slave.
Since this cluster only has one area and a few networks, I configured the slave with the same settings manually. -
@mcury i didn't have much choise there. had to do that manually from the master... i mean it was not too much...as i do a very simple BGP connection to AWS and push 3 routes. But would be perfect to have the FRR confs being populated on the exact manner as everything else...
-
@vinns said in FRR BGP over IPsec , when HA happens (slave-> master, master ->slave):
@mcury i didn't have much choise there. had to do that manually from the master... i mean it was not too much...as i do a very simple BGP connection to AWS and push 3 routes. But would be perfect to have the FRR confs being populated on the exact manner as everything else...
I think this would be the easiest way:
https://www.reddit.com/r/PFSENSE/comments/127l8di/ha_sync_with_frr_bgp/ -
@mcury right. thats the same result we got too. so nothing new on that. and i agree on the fact that, it could very well be that the support of HA sync does not include the FRR, afterall that is an additional package. i mean its not the end of the world to copy 30-40 lines from the xml and add them to the second node if that is the case so be it. :) many thanks for looking into this man , appreciate your help :)
-
@vinns said in FRR BGP over IPsec , when HA happens (slave-> master, master ->slave):
right. thats the same result we got too. so nothing new on that. and i agree on the fact that, it could very well be that the support of HA sync does not include the FRR, afterall that is an additional package. i mean its not the end of the world to copy 30-40 lines from the xml and add them to the second node if that is the case so be it. :) many thanks for looking into this man , appreciate your help :)
:)
