summaryrefslogtreecommitdiff
path: root/lib/routemap_cli.c
diff options
context:
space:
mode:
authorPhilippe Guibert <philippe.guibert@6wind.com>2021-10-27 14:56:37 +0200
committerPhilippe Guibert <philippe.guibert@6wind.com>2021-10-27 16:54:19 +0200
commit29263027acf9ab3468106e37c76ab1a65d197ea4 (patch)
treeea2818031e83b08a09cb008492916100d6ef3bce /lib/routemap_cli.c
parentf1506cf36b91014d920f82bbfe655651a2356141 (diff)
isisd: make isis work with default vrf name different than 'default'
The problem is related to startup configuration, which is not operational on default vrf name. To reproduce the issue, run the two daemons: zebra -o vrf0 & isisd -f /tmp/isisd.conf router isis 1 lsp-gen-interval 2 net 10.0000.0000.0000.0000.0000.0000.0000.0000.0000.00 metric-style wide redistribute ipv4 connected level-2 redistribute ipv6 connected level-2 The obtained show running-config looks like below: router isis 1 vrf default lsp-gen-interval 2 net 10.0000.0000.0000.0000.0000.0000.0000.0000.0000.00 metric-style wide redistribute ipv4 connected level-2 redistribute ipv6 connected level-2 The default vrf name is obtained by zebra daemon. While isis is not connected to zebra, i.e. at startup, when loading a startup configuration, the macro VRF_DEFAULT_NAME is used and returns 'default'. But because zebra connected and forces to a new default vrf name, the configuration is not seen as the default one, and further attempts to configure the isis instance via 'router isis 1' will trigger creation of an other instance. To handle this situation, at vrf_enable() event, which is called for each default vrf name change, the associated isis instance is updated with th new vrf name. The same is done for NB yang path. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Diffstat (limited to 'lib/routemap_cli.c')
0 files changed, 0 insertions, 0 deletions