{"id":18678208,"url":"https://github.com/srl-labs/nokia-segment-routing-lab","last_synced_at":"2025-06-11T05:07:39.242Z","repository":{"id":110641522,"uuid":"544794818","full_name":"srl-labs/nokia-segment-routing-lab","owner":"srl-labs","description":"A lab to demonstrate Flex-Algo use case","archived":false,"fork":false,"pushed_at":"2023-05-24T10:41:36.000Z","size":8976,"stargazers_count":24,"open_issues_count":0,"forks_count":4,"subscribers_count":8,"default_branch":"master","last_synced_at":"2025-06-09T14:17:36.503Z","etag":null,"topics":["clab-topo"],"latest_commit_sha":null,"homepage":"","language":"JavaScript","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/srl-labs.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2022-10-03T08:33:33.000Z","updated_at":"2025-05-02T11:16:02.000Z","dependencies_parsed_at":"2023-05-28T09:45:14.931Z","dependency_job_id":null,"html_url":"https://github.com/srl-labs/nokia-segment-routing-lab","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/srl-labs%2Fnokia-segment-routing-lab","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/srl-labs%2Fnokia-segment-routing-lab/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/srl-labs%2Fnokia-segment-routing-lab/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/srl-labs%2Fnokia-segment-routing-lab/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/srl-labs","download_url":"https://codeload.github.com/srl-labs/nokia-segment-routing-lab/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/srl-labs%2Fnokia-segment-routing-lab/sbom","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":259204810,"owners_count":22821160,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["clab-topo"],"created_at":"2024-11-07T09:36:22.322Z","updated_at":"2025-06-11T05:07:39.219Z","avatar_url":"https://github.com/srl-labs.png","language":"JavaScript","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Nokia SR OS SR-MPLS: low latency service with Flex-Algo\n\nFlexible-Algorithm (Flex-Algo) provides a mechanism for IGPs to compute constraint-based paths across a network. We use a Flexible-Algorithm Definition (FAD) to describe how a particular algorithm should look like by defining what metric-type needs to be used when calculating the shortest path. This metric type can be IGP-metric, TE-metric or delay-metric. In this lab we will be using delay-metric to provide a low-latency service. The **goal** of this lab is to show case that per VPN service we can provide one prefix to use delay-metric and another prefix to use standard IGP-metric to calculate the shortest path. All done with Segment Routing and MPLS in the underlay.\n\nThis is translated into a home user that has access to two services. One service is a low-latency service when gaming while connected to the gaming servers. The other is using standard IGP metric when the user is making use of the internet service.\n\nThis lab also comes with a GPG telemetry stack ([gNMIc][gnmic]/[Prometheus][prom]/[Grafana][grafana]) to easily monitor how traffic is behaving in the network.\n\n![topo](./img/topology.PNG)\n\n## Deploying the lab\n\nStart with cloning the repository:\n\n```bash\ngit clone https://github.com/srl-labs/nokia-segment-routing-lab.git \u0026\u0026 cd nokia-segment-routing-lab\n```\n\nThe lab is deployed with [containerlab](https://containerlab.dev/) project where [`nokia-sr.clab.yml`](nokia-sr.clab.yml) file declaratively describes the lab topology.\n\n```\nclab deploy\n```\n\nSame goes for destroying the lab\n\n```\nclab destroy\n```\n\n## Accessing the network elements\n\nAfter deploying the lab, you will see a summary of the deployed nodes in table format like below. To access a network element with SSH simply use the hostname as described in the table.\n\n```\nssh admin@clab-sr-r1\n```\n\nThe Linux CE clients can be accessed as regular containers, you can connect to them just like to any other container\n\n```\ndocker exec -it clab-sr-client1 bash\n```\n\n## Configuration\n\nAll nodes come preconfigured thanks to startup-config setting in the topology file [`nokia-sr.clab.yml`](nokia-sr.clab.yml), so there is no need to configure the nodes after deployment. Each node has its own config file which you can find [`configs`](/configs).\n\nThis is the high-level overview to enable Flex-Algo for SR-MPLS:\n\n1. Configure and advertise the Flex-Algo Definition (FAD)\n2. Configure Flex-Algo participation\n3. Configure a Flex-Algo prefix node-SID on all routers that will use Flex-Algo\n4. Apply traffic steering with Flex-Algo on VPN service\n\n### 1. Configure and advertise FAD\n\nCreate the FAD with metric-type delay and advertise it into the IGP. In our case we are using ISIS\n\n```\nA:admin@R1# admin show configuration /configure routing-options\n    flexible-algorithm-definitions {\n        flex-algo \"Flex-Algo-128\" {\n            admin-state enable\n            description \"Flex-Algo for Delay Metric\"\n            metric-type delay\n        }\n    }\n```\n\nNext enable Flex-Algo under ISIS. Only one router in the domain needs to advertise the FAD but everyone who wants to be part of the Flex-Algo topology needs to participate. In our case only R1 is advertising the FAD and all other routers are participating.\n\n```\nA:admin@R1# admin show configuration /configure router isis flexible-algorithms\n    admin-state enable\n    flex-algo 128 {\n        participate true\n        advertise \"Flex-Algo-128\"\n    }\n\n```\n\nWe can see R1 is advertising the FAD as an ISIS Sub-Tlv with metric-type delay. All participating routers now know how the Flex-Algo looks like.\n\n\u003cpre\u003e\nA:admin@R1# show router isis database R1.00-00 level 2 detail | match \"FAD Sub-Tlv\" post-lines 5\n    FAD Sub-Tlv:\n        Flex-Algorithm   : 128\n        \u003cb\u003eMetric-Type      : delay\u003c/b\u003e\n        Calculation-Type : 0\n        Priority         : 100\n        Flags: M\n\u003c/pre\u003e\n\n### 2. Configure Flex-Algo participation\n\nLooking into R3 we can see its only participating in the Flex-Algo topology and not advertising the FAD.\n\n```\nA:admin@R3# admin show configuration /configure router isis flexible-algorithms\n    admin-state enable\n    flex-algo 128 {\n        participate true\n    }\n```\n\nIf we investigate the Router Capabilities Tlv of R3 we can see its supporting two SR Algo's, the default SFP algorithm based on IGP-metric and Flex-Algo 128 based on delay-metric\n\n\u003cpre\u003e\nA:admin@R3# show router isis database R3.00-00 level 2 detail | match \"Router Cap\" post-lines 5\n  Router Cap : 192.0.2.3, D:0, S:0\n    TE Node Cap : B E M  P\n    SR Cap: IPv4 MPLS-IPv6\n       SRGB Base:100000, Range:1000\n    \u003cb\u003eSR Alg: metric based SPF, 128\u003c/b\u003e\n    Node MSD Cap: BMI : 12 ERLD : 15\n\u003c/pre\u003e\n\n### 3. Configure a Flex-Algo prefix node-SID on all router that will use Flex-Algo\n\nAssign a prefix node-SID for Segment Routing with Flex-Algo and a prefix node-SID for default Segment Routing.\n\n```\nA:admin@R1# admin show configuration /configure router isis interface \"system\"\n    ipv4-node-sid {\n        index 1\n    }\n    flex-algo 128 \n        ipv4-node-sid {\n            index 11\n        }\n    }\n```\n\nWe can see R1 is advertising into ISIS a Prefix-SID with index 1 for Algo-0, which is the default IGP-based algo, and a Prefix-SID with index 11 for Algo-128 which is our Flex-Algo.\n\n```\nA:admin@R1# show router isis database R1.00-00 level 2 detail | match \"TE IP Reach\" post-lines 12\n  TE IP Reach   :\n\u003csnipp\u003e\n    Prefix   : 192.0.2.1\n    Sub TLV   :\n      Prefix-SID Index:1, Algo:0, Flags:NnP\n      Prefix-SID Index:11, Algo:128, Flags:NnP\n```\n\n### 4. Apply traffic steering with Flex-Algo on VPN service\n\nIn the bgp-ipvpn context of our VPN we define Segment Routing as our tunnel between services, which means we use SPF Segment Routing but not necessarily Flex-Algo. For that we need to define an import policy `customer1-import` to define which prefix will be using Flex-Algo.\n\n```\nA:admin@R1# admin show configuration /configure service vprn \"customer1\"\n    admin-state enable\n    service-id 1\n    customer \"1\"\n    bgp-ipvpn {\n        mpls {\n            admin-state enable\n            route-distinguisher \"1:1\"\n            vrf-target {\n                community \"target:65000:1\"\n            }\n            vrf-import {\n                policy [\"customer1-import\"]\n            }\n            auto-bind-tunnel {\n                resolution filter\n                allow-flex-algo-fallback true\n                resolution-filter {\n                    sr-isis true\n                }\n```\n\nIn our `customer1-import` policy `entry 20` we can see we accept gaming specific routes to use Flex-Algo while in `entry 10` we accept internet specific prefixes to use regular Segment Routing based on IGP-metric.\n\n```\nA:admin@R1# admin show configuration /configure policy-options policy-statement \"customer1-import\"\n    entry 10 {\n        from {\n            prefix-list [\"internet\"]\n            community {\n                name \"customer1-import\"\n            }\n        }\n        action {\n            action-type accept\n        }\n    }\n    entry 20 {\n        from {\n            prefix-list [\"gaming\"]\n            community {\n                name \"customer1-import\"\n            }\n        }\n        action {\n            action-type accept\n            flex-algo 128\n        }\n    }\n    default-action {\n        action-type reject\n    }\n\n```\n\n```\nA:admin@R1# show router 1 route-table\n\n===============================================================================\nRoute Table (Service: 1)\n===============================================================================\nDest Prefix[Flags]                            Type    Proto     Age        Pref\n      Next Hop[Interface Name]                                    Metric\n-------------------------------------------------------------------------------\n10.0.1.0/24                                   Local   Local     02h37m23s  0\n       to_client1                                                   0\n10.0.2.0/24                                   Remote  BGP VPN   02h35m59s  170\n       192.0.2.2 (tunneled:SR-ISIS:524296)                          30\n20.0.1.0/24                                   Local   Local     02h37m23s  0\n       to_gamer1                                                    0\n20.0.2.0/24                                   Remote  BGP VPN   00h41m02s  170\n       192.0.2.2 (tunneled:SR-ISIS:524300)                          60000\n```\n\n### Verify that link delays are advertised into ISIS\n\nThe upper plane (R1-\u003eR3-\u003eR5-R2) configured statically with a 10ms delay. While to lower plane (R1-\u003eR4-\u003eR6-\u003eR2) is configured with 20ms. We can see R1 is advertising a delay of 10ms for its link towards R3. Now all routers are aware how much delay is on each interface in our ISIS area.\n\n\u003cpre\u003e\nA:admin@R1# show router isis database R1.00-00 detail\n\u003csnipp\u003e\n  TE IS Nbrs   :\n    Nbr   : R3.00\n    Default Metric  : 10\n    Sub TLV Len     : 34\n    IF Addr   : 192.168.13.0\n    Nbr IP    : 192.168.13.1\n    TE APP LINK ATTR    :\n      SABML-flag:Non-Legacy SABM-flags:   X\n        \u003cb\u003eDelay Min : 10000 Max : 10000\u003c/b\u003e\n    Adj-SID: Flags:v4VL Weight:0 Label:524285\n\u003c/pre\u003e\n\n## Running traffic\n\nTo run traffic between the home user and the internet services, leverage `traffic.sh` control script.\n\nTo start the traffic from home users to internet service or gaming service:\n\n* `bash traffic.sh start internet` - start traffic from home user to internet service\n* `bash traffic.sh start gamer` - start traffic from gamer to low-latency gaming service\n\nTo stop the traffic:\n\n* `bash traffic.sh stop` - stop traffic generation between all nodes\n\n### 1. Home user starts surfing on the internet\n\nThe traffic path to the internet services follows the default ISIS IGP-metric which is 10.\n\n![traf1](./img/step1-internet-traffic-only.PNG)\n\n### 2. Gamer starts gaming\n\nThe gamer requires a low-latency service and traffic is following the upper plane which has a total latency of 30ms from R1 to R2.\n\n![traf2](./img/step2-add-gamer-traffic.png)\n\n### 3. Adding latency\n\nBy increasing the latency on the link between R3 and R5 to 60ms, we can see traffic shifting to the lower plane. The upper plane has a total delay of 80ms while to lower plane has now a total delay of 60ms. Note that the traffic for the internet user remains the same.\n\n![delay](./img/step3-after-delay-increase.PNG)\n\n## Access details\n\n* Grafana: \u003chttp://localhost:3000\u003e\n* Prometheus: \u003chttp://localhost:9090/graph\u003e\n\n[gnmic]: https://gnmic.openconfig.net\n[prom]: https://prometheus.io/\n[grafana]: https://grafana.com/\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fsrl-labs%2Fnokia-segment-routing-lab","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fsrl-labs%2Fnokia-segment-routing-lab","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fsrl-labs%2Fnokia-segment-routing-lab/lists"}