Missing show run output#22619
Conversation
Add some missing debug commands to the show command. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Found a bit of code where spaces were being used instead of tabs. Fix. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Current code displays `timers active 0` when a show run is run. It should be `timers active disabled`, fix it. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
If you enter this: bfd peer 1.2.3.4 bfd-mode sbfd-echo bfd-name FOO multi-hop local-address 1.2.3.4 srv6-source-ipv6 1::1 srv6-encap-data 2::2 exit this is displayed: bfd peer 1.2.3.4 bfd-mode sbfd-echo bfd-name FOO local-address 1.2.3.4 srv6-source-ipv6 1::1 srv6-encap-data 2::2 exit Fix the missing multihop. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
If you enter this: router bgp 32939 vrf BLUE address-family l2vpn evpn advertise-pip show run does not display `advertise-pip`: ! router bgp 39239 vrf BLUE exit ! Fix it. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
This was not being properly displayed in a show run. Fix. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
This command was never displayed when modified, fix it. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When configuring ipv6 nhrp authentication, only ip nhrp authentication is displayed on a show run. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
This command is never displayed on a `show run` Show it. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Greptile SummaryThis PR fixes several missing
Confidence Score: 4/5Safe to merge — all changes are additive show-run fixes with no behavioral impact on the data plane, and each is well-scoped to its daemon's config writer. The code changes are narrow and correct: each adds a previously-missing vty_out call or fixes the value passed to an existing one. The one non-obvious change is enabling log filter-text persistence in lib/log_cli.c, which intentionally changes a session-only setting to a persistent one and may surprise operators who relied on the old behavior. lib/log_cli.c — the log filter-text persistence change is intentional but is a behavioral shift that benefits from explicit documentation. Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[show running-config] --> B{config_write_host}
B --> C[memory release rate\n NEW: write if non-default]
A --> D{bgp_config_write}
D --> E[bgp graceful-restart disable-eor\n NEW: write if flag set]
D --> F{bgp_config_write_evpn_info}
F --> G[advertise-pip / no advertise-pip\n NEW: else advertise-pip\nwhen pip_ip_static == INADDR_ANY]
A --> H{interface_config_write - nhrpd}
H --> I[auth_token present?]
I -->|yes| J[IS_VALID_AFI auth_afi?\n NEW: use auth_afi, fallback AFI_IP]
J --> K[write: ip/ipv6 nhrp authentication]
A --> L{frr_logging yang nodes}
L --> M[filter-text\n NEW: now included in cli_show]
A --> N{pim_debug_config_write}
N --> O[debug pim graft\n NEW]
N --> P[debug pim state-refresh\n NEW]
A --> Q{eigrp_cli_show_active_time}
Q -->|timer == 0| R[write: timers active-time disabled\n NEW]
Q -->|timer != 0| S[write: timers active-time N]
A --> T{bfd_cli_show_sbfd_peer}
T --> U[yang_dnode_exists multi-hop?\n NEW: dynamic instead of hardcoded]
U -->|yes| V[print multihop keyword]
U -->|no| W[omit multihop keyword]
%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
flowchart TD
A[show running-config] --> B{config_write_host}
B --> C[memory release rate\n NEW: write if non-default]
A --> D{bgp_config_write}
D --> E[bgp graceful-restart disable-eor\n NEW: write if flag set]
D --> F{bgp_config_write_evpn_info}
F --> G[advertise-pip / no advertise-pip\n NEW: else advertise-pip\nwhen pip_ip_static == INADDR_ANY]
A --> H{interface_config_write - nhrpd}
H --> I[auth_token present?]
I -->|yes| J[IS_VALID_AFI auth_afi?\n NEW: use auth_afi, fallback AFI_IP]
J --> K[write: ip/ipv6 nhrp authentication]
A --> L{frr_logging yang nodes}
L --> M[filter-text\n NEW: now included in cli_show]
A --> N{pim_debug_config_write}
N --> O[debug pim graft\n NEW]
N --> P[debug pim state-refresh\n NEW]
A --> Q{eigrp_cli_show_active_time}
Q -->|timer == 0| R[write: timers active-time disabled\n NEW]
Q -->|timer != 0| S[write: timers active-time N]
A --> T{bfd_cli_show_sbfd_peer}
T --> U[yang_dnode_exists multi-hop?\n NEW: dynamic instead of hardcoded]
U -->|yes| V[print multihop keyword]
U -->|no| W[omit multihop keyword]
Prompt To Fix All With AIFix the following 1 code review issue. Work through them one at a time, proposing concise fixes.
---
### Issue 1 of 1
lib/log_cli.c:523
**Behavioral change: log filter-text now persists across restarts**
The old code carried an explicit comment: `"This is not saved, but may be the future."` Enabling the `cli_show` callback here means `log filter-text` entries will now appear in running-config and be re-applied when the config is loaded on daemon restart. Previously these were session-only/ephemeral. The YANG leaf-list is properly defined as a config node so there is no technical blocker, but operators who relied on filter-text being temporary (e.g. short-lived debug filters) will now find those entries surviving restarts. Worth calling out in the commit message or release notes so users are not surprised.
Reviews (1): Last reviewed commit: "lib: Fix `log filter-text X` to display" | Re-trigger Greptile |
| { .xpath = "/frr-logging:logging/filtered-file/filename", .cbs.cli_show = logging_filtered_file_filename_cli_write }, | ||
| /* This is not saved, but may be the future. */ | ||
| /* { .xpath = "/frr-logging:logging/filter-text", .cbs.cli_show = logging_filter_text_cli_write }, */ | ||
| { .xpath = "/frr-logging:logging/filter-text", .cbs.cli_show = logging_filter_text_cli_write }, |
There was a problem hiding this comment.
Behavioral change: log filter-text now persists across restarts
The old code carried an explicit comment: "This is not saved, but may be the future." Enabling the cli_show callback here means log filter-text entries will now appear in running-config and be re-applied when the config is loaded on daemon restart. Previously these were session-only/ephemeral. The YANG leaf-list is properly defined as a config node so there is no technical blocker, but operators who relied on filter-text being temporary (e.g. short-lived debug filters) will now find those entries surviving restarts. Worth calling out in the commit message or release notes so users are not surprised.
Prompt To Fix With AI
This is a comment left during a code review.
Path: lib/log_cli.c
Line: 523
Comment:
**Behavioral change: log filter-text now persists across restarts**
The old code carried an explicit comment: `"This is not saved, but may be the future."` Enabling the `cli_show` callback here means `log filter-text` entries will now appear in running-config and be re-applied when the config is loaded on daemon restart. Previously these were session-only/ephemeral. The YANG leaf-list is properly defined as a config node so there is no technical blocker, but operators who relied on filter-text being temporary (e.g. short-lived debug filters) will now find those entries surviving restarts. Worth calling out in the commit message or release notes so users are not surprised.
How can I resolve this? If you propose a fix, please make it concise.Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
| else if (!host.motd) | ||
| vty_out(vty, "no banner motd\n"); | ||
|
|
||
| if (frr_mem_release_rate_get() != FRR_MEM_RELEASE_MB_DEFAULT) |
There was a problem hiding this comment.
a nit, maybe: the new api is going to report a non-zero rate in builds that don't have support at all. that seems a little confusing? do you think that's worth thinking about, or is it too minor to matter?
There was a problem hiding this comment.
I disagree that it works that way at all. I do not have the memory stuff compiled in at all and it does not show up in my show run
There was a problem hiding this comment.
hmm - the api returns the "default" value, which is 1MB, right? I get it that the test condition avoids emitting config in that case, but the api returns what it returns?
There was a problem hiding this comment.
yes it is returnning FRR_MEM_RELEASE_MB_DEFAULT in the no compile case as such the if statement won't be true. So no display?
There was a problem hiding this comment.
rereading this I am not sure what we are arguing about. Can you help me understand ?
See individual commits for what is missing. Code inspection found a bunch of code that was not properly being displayed in a show run.