1. Security Baseline Configuration#

1.1 Objective#

Security baselines are only effective if they are applied consistently across all devices — and kept that way over time. In practice, differences between platforms and configuration drift often result in small gaps that can quickly become security holes. Manually tracking these differences is error-prone, and updating each device configuration one by one is not sustainable.

In this activity, you will tackle this challenge using intent-based networking (IBN). By defining an abstract intent-type for node-level security, you can express what should be enforced while NSP ensures how this is realized across different router families and network operating systems. The result is a scalable way to maintain conformance and avoid drift, with one high-level intent applied network wide.

To get started, a boilerplate custom intent-type for SR OS is provided. You will first install and validate this baseline, then make targeted modifications to extend its functionality. As a final step, you will adapt the same intent-type to support SR Linux, demonstrating how one abstraction can be applied across multiple platforms.

1.2 Tasks#

You should read these tasks from top-to-bottom before beginning the activity.

It is tempting to skip ahead but tasks may require you to have completed previous tasks before tackling them.

1.2.1 Install VS Code and NSP Intent Manager extension#

For this activity, having VS Code with the NSP Intent Manager extension installed is essential. If you cannot install 3^rd party software on your laptop, don't worry you can just use your web-browser and connect to code-server.

Installation Steps:

1. Download and install Visual Studio Code.
2. Install the vsCode extension for Intent Manager.
3. Configure the vsCode extension to authenticate against the SReXperts NSP at nsp.srexperts.net using the credentials (username/password) provided to you.

1.2.2 Create your own Golden Security Config intent-type#

Add a folder to your VS Code workspace to store intent-types. Open the context-menu for this folder and select Create intent-type. Provide a unique name like security-config-group02, provide the author's name and choose the device security template. Please adjust the name with the group, that has been assigned to you during the hackathon. A new folder called security-config-group02_v1 will be created. The folder contains the complete intent-type, while the context menu has the option to Upload intent-type to the connected NSP system.

First, study the intent-type folder and file structure and content. The intent-type follows a decomposed design, minimizing the touchpoints to adjust the behavior. In consequence, most of the JavaScript codebase is static and must not be changed by the intent developer.

The most important concept here are mappers, that can be found in intent-type-resources/mappers. Those are templates (using Apache FreeMarker) to translate the intent-model into the device model.

Explore what is contained in the mapper!

1.2.3 Create/Deploy intents from WebUI#

• Make sure, you've uploaded the new intent-type into your NSP system
• Create an intent for PE1, but don't deploy it yet to the network by keeping the synchronize option unchecked
• Run an audit to understand which configuration would be rolled out
• Synchronize the intent to the network and check if the device config was updated
• Feel free to modify the device configuration via CLI and run audit/sync operations again

1.2.4 Extend the intent-type with something small#

In this task, we explore how to add additional configuration to your intent-type to extend the coverage. The idea with this type of intent is that model-driven node configuration can be easily reused to populate the intent-type. This is exactly what we will try to do for model-driven SR OS nodes in this task.

Change your intent-type in such a way that it creates an additional entry 50 in the management-access-filter that explicitly accepts SNMP Traps (UDP 162 as both destination and source port).

configure {
    system {
        security {
            management-access-filter {
                ip-filter {
                    default-action accept
                    entry 50 {
                        match {
                            dst-port {
                                port 162
                            }
                            src-port {
                                port 162
                            }
                        }
                    }
                }
            }
        }
    }
}

    ...
    {
        "entry-id": 40,
        ...
    },
    {
        "entry-id": 50,
        "description": "Allow SNMP",
        "action": "accept",
        "match": {
            "protocol": "udp",
            "src-port": {
                "port": 162
            },
            "dst-port": {
                "port": 162
            },
            "mgmt-port": {
                "cpm": [null]
            }
        }
    },
    {
        "entry-id": 100,
        ...
    }
    ...

After making your changes in the intent-type, trigger an Audit of the intent from the WebUI.

What result do you expect?

Synchronize either PE1, make sure that your changes in the intent-type are propagated correctly and verify the result on the node CLI.

1.2.5 Extend the intent-type with something big#

For the previous task, a simple copy-and-paste of what was already in the intent with minor modifications was all that was needed to get the desired result. Kudos to you if you used a different approach already. In either case, a different approach will be required for this task.

The modification required in this task isn't based on existing content of the intent-type, rather requiring entirely new sections to be added to the SR OS.ftl file.

For this task, add basic cpm-filter functionality to your intent. This configuration is to be added (although feel free to add more of your own!)

configure {
    system {
        security {
            cpm-filter {
                default-action accept
                ip-filter {
                    entry 10 {
                        match {
                            protocol icmp
                        }
                        action {
                            accept
                        }
                    }
                    entry 20 {
                        match {
                            protocol tcp-udp
                        }
                        action {
                            accept
                        }
                    }
                }
            }
        }
    }
}

To help you with this task, rely on info json and pwc model-path from the SR OS MD-CLI or use the Model Driven Configurator to see what payloads it sends to approximate what you will need to add to SR OS.ftl.

Notice the presence of merge and replace operations in SR OS.ftl. The merging operation will add your configuration to the specified context and leave the existing configuration intact. Replacing the context will replace the existing context with your payload.

Using what you've seen so far, audit and synchronize the intents with your changes. Try to avoid locking yourself (or NSP) out of the router. Asking for help in case something unexpected happens is encouraged.

Enable the update-fault-tolerance configuration in the global BGP context to bring the configuration in line with Nokia's recommendation and once again align the router configuration.

1.2.6 Extend the intent-type for SR Linux#

Completing this lab requires a magnum opus of sorts. If you've made it this far that means you are well-versed in SR OS as well as the intent principles we are using here. This intent-type is designed to allow simple onboarding of different NOSes. Having SR Linux available in the topology we would be amiss if we do not add coverage for it to our intent-type. As before, open your intent-type. In line with SR OS.ftl, it stands to reason that we will need a similar file for SR Linux. That might be SRL.ftl or SRLinux.ftl or SR Linux.ftl.

In the NSP WebUI or vsCode check for intent-type resources. There is a JavaScript file in the common directory called IntentHandler.mjs, which implements a class called IntentHandler. One method of this class is called getTemplateName which maps the device family to a template name.

Once you've determined the filename to use, create it as an empty file next to SR OS.ftl. A suggested SR Linux configuration to add (but, as before, feel free to use your own) is:

acl {
    acl-filter cpm type ipv4 {
        entry 470 {
            match {
                ipv4 {
                    protocol tcp
                }
                transport {
                    destination-port {
                        value 2200
                    }
                }
            }
        }
    }
    acl-filter cpm type ipv6 {
        entry 520 {
            match {
                ipv4 {
                    protocol tcp
                }
                transport {
                    destination-port {
                        value 2200
                    }
                }
            }
        }
    }
}
system {
    ssh-server mgmt {
        rate-limit 10
    }
    ftp-server {
        network-instance default {
            admin-state disable
        }
        network-instance mgmt {
            admin-state disable
        }
    }
}

Use what you've learned and populate SRLinux.ftl so this configuration will be applied. The first pointer is that the equivalent of info json for SR Linux is info | as json, and this output modifier can be used in general. The second pointer is that the Model Driven Configurator knows which namespaces (or prefixes) to use, and this information is also freely available online.

Once complete, deploy the intent and confirm the changes are applied successfully.

1.3 Summary#

Congratulations! You have completed this activity. Take a moment to review what you have achieved:

• Installed and validated a provided boilerplate intent-type for SR OS.
• Modified the intent-type to enforce node-level security attributes.
• Extended the same construct to also support SR Linux.

The result: a reusable, intent-driven approach that enforces consistent configuration across your network, prevents drift, and keeps your security posture aligned with evolving standards. Beyond security, the same concepts and patterns are universally applicable to other configuration areas, helping you simplify operations, maintain conformance, and scale day-to-day network management with confidence.