Hostname handling in FRR

[sudharr86]

Description

There are a couple of issues with hostname handling in FRR

1. if hostname is changed in linux shell, and if its different from the hostname configured under FRR configs, we see two different hostname commands in show run. This is happens as the command is printed from two different sources.

Source 1: From Daemons (e.g., zebra)
Each FRR daemon (zebra, bgpd, staticd) has its own host.name variable. When show running-config runs, vtysh queries each daemon via socket, and each daemon outputs its config including:

// lib/command.c line 450-456
static int config_write_host(struct vty *vty)
{
    const char *name = cmd_hostname_get();  // Returns daemon's host.name
    if (name && name[0] != '\0')
        vty_out(vty, "hostname %s\n", name);
    ...
} 

The daemon's host.name is set either from:
System hostname via uname() at startup
Or from the config file when FRR reads frr.conf/zebra.conf

Source 2: From vtysh itself
vtysh also has its own host.name variable. When outputting config, vtysh_config_write() adds it:

// vtysh/vtysh_config.c line 730-743
void vtysh_config_write(void)
{
    const char *name = cmd_hostname_get();  // vtysh's own host.name
    if (name && name[0] != '\0') {
        snprintf(line, sizeof(line), "hostname %s", name);
        vtysh_config_parse_line(NULL, line);
    }
    ...
} 

2. Hostname change is never propgated to daemons. Daemons like BGP/ISIS will exchange hostnames as part of BGP session establishment/ ISIS adjacency establishment. the daemons pickup the system hostname when they come up and hold on to it. This is never changed when hostname is changed. So, when the hostname is changed, the daemons have to be notified somehow. IMO, we should do this for vtysh hostname cli and not linux hostname cli since its not FRR config. FRR daemons should react to FRR configs.

Kindly share your thoughts.

Version

8.5.4, 10.3

How to reproduce

configure hostname in linux and frr vtysh.

Expected behavior

FRR daemons to use hostname configured in FRR via vtysh.

Actual behavior

FRR daemons use hostname configured in linux shell.

Additional context

No response

Checklist

• I have searched the open issues for this bug.
• I have not included sensitive information in this report.

[Ko496-glitch]

Hey @sudharr86, I was able to reproduce this issue locally. If you have any guidance on where to start or which components to target, I’d really appreciate it. I’m interested in working on this fix.