manage edge bgp_password - #803
Conversation
update bgp_password_enable for edge connection. Change to false. By default it was enabled but if you don't provide password it failed, because password can't be empty.
|
Hey Charlie, {% if link.bgp_section is defined and link.bgp_section.bgp_password is defined and link.bgp_section.bgp_password is not none %} |
ccoueffe
changed the title
| policy_vars: | ||
| BGP_PASSWORD: "{{ link.bgp_section.bgp_password | default('') }}" | ||
| BGP_PASSWORD_ENABLE: {{ link.bgp_section.bgp_password_enable | default(defaults.vxlan.topology.edge_connections.bgp_section.bgp_password_enable) }} | ||
| {% if link.bgp_section is defined and link.bgp_section.bgp_password is defined and link.bgp_section.bgp_password is not none and link.bgp_section.bgp_password | length > 0 %} |
There was a problem hiding this comment.
Medium: Preserve the public bgp_password_enable contract
Issue
The changed template derives BGP_PASSWORD_ENABLE only from whether bgp_password is non-empty. It never reads the schema-valid bgp_password_enable input. That silently changes the public contract from an explicit enable control, defaulting to true, to password-presence inference.
Evidence
-
The changed branch sets
BGP_PASSWORD_ENABLE: truewhenever a non-empty password exists andfalseotherwise;link.bgp_section.bgp_password_enableis never consulted. -
At authoritative model ref
f997000b00b383725a9853c7f200b3a2c38cbb08,bgp_password_enableandbgp_passwordare independent optional properties, while the enable default remainstrue. The published generated documentation exposes the same Boolean default and optional password. -
Focused validation against that exact schema accepted both contradictory combinations: password present plus
bgp_password_enable: false, and password omitted plusbgp_password_enable: true. -
A strict render of the PR template produced these effective payloads:
Input combination Rendered enable Password key present Password omitted, enable omitted falseNo Password empty or null falseNo Password present, enable omitted trueYes Password present, explicit enable falsetrueYes Password omitted, explicit enable truefalseNo
Practical example
An operator can pre-stage a BGP password in the model while deliberately keeping authentication disabled until the remote peer is ready:
vxlan:
topology:
edge_connections:
- source_device: border-1
source_interface: Ethernet1/1
dest_device: wan-router-1
dest_fabric: WAN
local_ip: 192.0.2.1/30
neighbor_ip: 192.0.2.2
bgp_section:
neighbor_asn: 65100
# The password is staged, but authentication must remain disabled.
bgp_password_enable: false
bgp_password: "example-staged-secret"The explicit intent is:
BGP_PASSWORD_ENABLE: false
BGP_PASSWORD: "example-staged-secret"PR 803 ignores the Boolean and sees only that the password is non-empty, so it renders:
BGP_PASSWORD_ENABLE: true
BGP_PASSWORD: "example-staged-secret"If the remote router has not enabled the same authentication yet, the NaC run unexpectedly enables it on border-1; the peers no longer agree and the established BGP session can drop and remain down. The inverse is also silent: bgp_password_enable: true with an accidentally omitted password renders BGP_PASSWORD_ENABLE: false instead of failing validation for incomplete input.
Existing PR overlap
No matching existing PR comment found. The August 6 suggestion from mthurstocisco proposes password-presence gating, but it does not reconcile, remove, or deprecate the existing public enable property.
Impact
A user who explicitly disables password authentication while retaining a password gets authentication enabled. That can reset an established BGP session and prevent it from returning if the peer is not using the same password. Conversely, explicit enable intent without a password is silently disabled instead of being rejected as incomplete input. In both cases, a schema-valid setting is accepted and then contradicted by the rendered intent.
Suggested fix
Choose one authoritative contract and enforce it end to end. If the Boolean remains public, honor its effective value; when true, require a non-empty password through semantic validation, and when false keep enable false even if a password is supplied. If passwordless edge BGP should be the normal omission behavior, coordinate a source-model default change from true to false rather than overriding the source default in this template. In either case, emit the desired password key deterministically as described in Finding 2. Add schema/semantic/render tests for omitted, empty, null, present, explicit false plus present, and explicit true plus absent.
If password presence is intentionally replacing the Boolean, coordinate a source-model change that deprecates or removes bgp_password_enable, updates its default and generated docs, rejects ambiguous legacy combinations with a migration message, and lands before this behavior is released.
Medium: Emit an empty password so removal is observable to
|
…hen enabled - Template: if bgp_password_enable is true, send password; if false, send empty password - Validation: rule 321 now rejects bgp_password_enable=true without a non-empty bgp_password - Always emit BGP_PASSWORD key for dcnm_policy diff detection
|
Hi Mike, Thanks for the thorough review. I went back to my initial approach — keeping the boolean — but with a hybrid logic:
This covers the points raised by Matt and Peter during the meeting, your review comments, and my original concern about the empty password failure. Template changes (
Validation rule (321):
Regarding the staged password scenario (
Behavior matrix:
|
|
Hi @ccoueffe my worry is that to transition away from the current setup and defaults (IE enable is true) then, at least for our customers, your change will silently turn off authentication with no warnings, I think that is too much of a breaking change. Currently we have customers just specifying a password (as that was all that was required previously), with your change (based on your matrix above) they will have their authentication turned off and password removed. Please can you look at this logic again to better handle this breaking change transition |
5 participants
update bgp_password_enable for edge connection. Change to false. By default it was enabled but if you don't provide password it failed, because password can't be empty.
Related Issue(s)
Related Collection Role
Related Data Model Element
Proposed Changes
change default value for edge bgp password enable.
Test Notes
Cisco Nexus Dashboard Version
Checklist