NSP Discovery and Bulk BGP Change Across SR OS and SR Linux
An operator uses Nokia NSP to manage 240 SR OS routers and 60 SR Linux data-center leaves. A 45-minute change window is reserved to add a new eBGP peer to 80 SR OS nodes. The previous manual CLI change caused configuration drift on 12 nodes because one engineer used the classic CLI and another used MD-CLI. NSP discovery for the SR Linux leaves is failing: ICMP works, but the nodes remain unmanaged. The SR OS nodes are discovered over SNMPv2c with community nspread and mediated over SSH. The SR Linux leaves use gNMI on port 57400 with TLS, but the NSP gateway is configured with the wrong CA profile. The operator wants a repeatable, auditable change with validation and rollback, and cannot afford a full maintenance reboot.
1. What is the most likely reason the SR Linux leaves stay unmanaged, and what would you check first?
Read the worked answer
ICMP and SNMP discovery are not the issue for SR Linux. NSP uses model-driven mediation over gNMI/57400 with TLS. A wrong CA profile causes the TLS handshake to fail before credentials are checked, so the node remains unmanaged even though it replies to ping. Check the NSP gateway CA/server profile, the SR Linux certificate SAN and validity, time synchronization, gRPC/gNMI service state, the management VRF, and any CPM filter that permits TCP 57400. Also confirm that the NSP discovery profile is the SR Linux/MDM type, not an SNMP profile used for SR OS.
2. Compare a CLI script with an NSP model-driven change for the 80-node BGP addition. Recommend one and justify.
Read the worked answer
A CLI script is fast but bypasses YANG validation, has no transactional rollback, and already caused drift. NSP MDM/Intent Manager uses YANG models, pre-change validation, dry-run, and commit/rollback with an audit trail. For 80 nodes, group them into canary and maintenance groups; apply to 5 first, verify BGP, then the remainder. The 45-minute window is enough if templates are pre-tested. Recommend NSP model-driven change because the requirement is repeatable, auditable, and reversible, not just fast.
3. Outline the pre-checks and rollback plan for the 45-minute window.
Read the worked answer
Pre-checks: capture the running configuration and BGP neighbor state; confirm the peer address is reachable in the correct VRF; check export/import policy, max-prefix, TCP 179 filters, and MD5 if used; ensure NSP has a rollback checkpoint. Rollback: stop at the first canary failure, use NSP rollback to the checkpoint, then verify sessions and route counts. Do not reboot; BGP changes are hitless. After the window, compare intended versus actual configuration for all 80 nodes and record the audit trail.