Project

General

Profile

Actions

Bug #7617

closed

OpenBGP not restarting on new WAN IP or firewall reload

Added by Phil Biggs almost 7 years ago. Updated over 4 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
05/31/2017
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Affected Version:
Affected Plus Version:
Affected Architecture:

Description

OpenBGP does not reload/restart with other packages when the WAN IP changes or the firewall rules are reloaded.

Restarting the service manually generates the following log entries, which might provide a clue:

Jun 1 07:56:40 php-fpm 33067 /index.php: Successful login for user 'admin' from: 192.168.111.8
Jun 1 07:58:09 php-fpm 63893 /status_services.php: The command '/usr/local/etc/rc.d/bgpd.sh stop' returned exit code '1', the output was 'killall: warning: kill -TERM 5658: No such process killall: warning: kill -TERM 5454: No such process'


Files

OpenBGPD logs.txt (51.1 KB) OpenBGPD logs.txt Phil Biggs, 05/31/2017 08:38 PM
Actions #1

Updated by Phil Biggs almost 7 years ago

A symptom of this is that a table maintained by OpenBGP is not updated after a WAN IP change or firewall reload.

Strangely, updates received by OpenBGP from its neighbor are logged but those same updates are not added to the table.

Could it be that one process is restarted but another is not?

Actions #2

Updated by Phil Biggs almost 7 years ago

Attaching some system and routing logs.

Actions #3

Updated by Phil Biggs almost 7 years ago

I need to withdraw this report, assuming my assessment below is correct. Apologies for any effort wasted on this.

After looking at some of the code I realized that the OpenBGPD package isn't actually "restarted" when the firewall rules are reloaded. If it is already running, which it will be in normal circumstances, OpenBGPD is reloaded - i.e., the config is just reread. I can see that restarting OpenBGPD would be undesirable where lots of routing table entries are involved.

My table is emptied as a result of pf being restarted/reloaded on WAN IP or firewall rule change. Because the table isn't maintained through the GUI, it remains empty until OpenBGPD is manually restarted.

I guess I need to look for some other way of restarting OpenBGPD or reloading the table when pf is restarted.

Actions #4

Updated by Phil Biggs almost 7 years ago

It's a horrible hack but I added a line to openbgpd.inc:

function openbgpd_restart() {
    if (is_openbgpd_running() == true) {
        exec(PKG_BGPD_BIN . "/bgpctl reload");
        exec(PKG_BGPD_BIN . "/bgpctl neighbor postfix clear");

    } else {
        exec(PKG_BGPD_BIN . "/bgpd -f " . PKG_BGPD_CONFIG_BASE . "/bgpd.conf");
    }
}

The table is successfully reloaded on new WAN IP but it doesn't work after a firewall rule change.

I need to find out how to do that.

Actions #5

Updated by Kill Bill almost 7 years ago

Phil Biggs wrote:

The table is successfully reloaded on new WAN IP but it doesn't work after a firewall rule change.
I need to find out how to do that.

AFAICT the afterfilterchangeshellcmd thing still works. Use the shellcmd package for that.

Actions #6

Updated by Phil Biggs almost 7 years ago

Many thanks for that. Tested and works.

I didn't know that shellcmd even had that option. I've never used it before.

I wonder if I can now remove the hack from openbgpd.inc.

Actions #7

Updated by Kill Bill almost 7 years ago

Yeah I'd say it's no longer needed since WAN IP change will trigger filter_configure() on its own.

Actions #8

Updated by Phil Biggs almost 7 years ago

Thank you, again. shellcmd package was the answer.

Perhaps someone could close this now. (I can't see any way to do that myself.)

Actions #9

Updated by Jim Pingle over 4 years ago

  • Status changed from New to Closed
Actions

Also available in: Atom PDF