[sonic-bgpcfgd] Add ability to wait on rehydration for additional Loopback IPs during reloads

[anish-n]

Why I did it

If there are additional Loopback IPs defined in config db that are being advertised out via frr template files(using bgp network statements) and their config has not replayed in sonic-bgpcfgd, then these loopback ips transiently fail to be advertised out by the templates.

Work item tracking

• Microsoft ADO (number only):

How I did it

We introduce the ability to check for and fail peer addition requests if a additional loopbacks, as specified via a per-peer J2 file(additional_loopbacks.j2), are not replayed to bgpcfgd yet.

How to verify it

bgpcfgd unit test, and real device test in lab

Which release branch to backport (provide reason below if selected)

• 202305
• 202311
• 202405
• 202411
• 202505
• 202511

Tested branch (Please provide the tested image version)

Description for the changelog

Link to config_db schema for YANG module changes

A picture of a cute animal (not mandatory but encouraged)

[mssonicbld]

/azp run Azure.sonic-buildimage

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[Copilot]

Pull request overview

Adds a mechanism in sonic-bgpcfgd to block BGP peer programming during reload/rehydration until required Loopback IPv4 addresses are available, with required loopbacks optionally driven by a per-peer-type Jinja template.

Changes:

• Extend BGPPeerMgrBase to discover additional required loopbacks from additional_loopbacks.conf.j2 and gate add_peer() until their IPv4 addresses (or bgp_router_id) are present.
• Add/adjust unit tests to validate the new gating behavior and expected log messages.
• Introduce an internal peer template listing Loopback4096 as an additional required loopback.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
src/sonic-bgpcfgd/bgpcfgd/managers_bgp.py	Adds template-driven loopback dependency initialization and enforces loopback IPv4 availability before adding peers.
src/sonic-bgpcfgd/tests/test_bgp.py	Updates tests to patch and assert new log_info / log_warn calls related to loopback dependency handling.
dockers/docker-fpm-frr/frr/bgpd/templates/internal/additional_loopbacks.conf.j2	Adds internal peer template declaring Loopback4096 as an additional required loopback.

[yxieca]

/azpw ms_conflict

[mssonicbld]

/azp run Azure.sonic-buildimage

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[yxieca]

/azpw ms_conflict

[prsunny]

@anish-n , looks like no impact if lo0 is only present. @StormLiangMS , @deepak-singhal0408 could you review/signoff

[StormLiangMS]

LGTM — clean, extensible design. Approve with minor nits.

Summary

This PR gates BGP peer addition in bgpcfgd on additional Loopback IPs (beyond Loopback0) being replayed during reload/rehydration. Instead of hardcoding Loopback4096 for internal peers, it introduces a template-driven approach (additional_loopbacks.conf.j2) that makes the mechanism extensible per peer type.

What I Liked

• Template-driven approach — new loopback dependencies can be added per peer type without code changes
• Lazy init (post_dependencies_init) — avoids startup ordering issues by deferring template resolution to first add_peer()
• Defensive fail-open — setting post_dependencies_init_complete = True before rendering means a broken template won't block all peer programming. This is the right trade-off for production stability
• Generalized loop replaces the old separate Loopback0 / Loopback4096 checks — cleaner code

Minor Observations (non-blocking)

1. Double get_lo_ipv4("Loopback0|") call — The loop at line ~185 calls get_lo_ipv4(loopback + "|") for every loopback (including Loopback0), then line ~215 calls lo0_ipv4 = self.get_lo_ipv4("Loopback0|") again for kwargs['loopback0_ipv4']. Could cache the result from the loop to avoid the redundant directory lookup.

2. get_lo_ipv4 local var still named loopback0_ipv4 — The function is now generalized (docstring updated to LoopbackX), but the local variable on line ~515 is still loopback0_ipv4. A rename to loopback_ipv4 would be consistent.

3. Path construction — self.fabric.env.loader.searchpath[0] + "/" + base_template + ... — consider os.path.join() for robustness.

4. No loopback name validation — Template output is parsed as free-form text. A malformed template could inject unexpected names into self.loopbacks. Low risk since templates are controlled, but a regex check (re.match(r'Loopback\d+', name)) would add a safety net.

CI Status

All builds and KVM tests (t0, t1-lag, t2) pass ✅. DCO/Semgrep clean.

[StormLiangMS]

@deepak-singhal0408 could you review?

[yijingyan2]

/azpw ms_conflict

[yijingyan2]

/azpw ms_conflict

[deepak-singhal0408]

looks good. thanks,

[mssonicbld]

Cherry-pick PR to msft-202506: Azure/sonic-buildimage-msft#2147

[prsunny]

@StormLiangMS , @deepak-singhal0408 , please check the labels for cherry-pick.

[mssonicbld]

Cherry-pick PR to 202511: #26615