{"id":204,"date":"2026-06-26T00:00:00","date_gmt":"2026-06-25T20:30:00","guid":{"rendered":"https:\/\/www.anynet.ir\/blog\/%d8%b4%d8%a8%da%a9%d9%87%d8%b3%d8%a7%d8%b2%db%8c-%d8%ae%d9%88%d8%af%da%a9%d8%a7%d8%b1-%d8%a8%d8%a7-cisco-crosswork-%d9%85%d8%af%db%8c%d8%b1%db%8c%d8%aa-%da%86%d8%b1%d8%ae%d9%87-%d8%ad%db%8c%d8%a7-en\/"},"modified":"2026-10-19T11:07:40","modified_gmt":"2026-10-19T07:37:40","slug":"%d8%b4%d8%a8%da%a9%d9%87%d8%b3%d8%a7%d8%b2%db%8c-%d8%ae%d9%88%d8%af%da%a9%d8%a7%d8%b1-%d8%a8%d8%a7-cisco-crosswork-%d9%85%d8%af%db%8c%d8%b1%db%8c%d8%aa-%da%86%d8%b1%d8%ae%d9%87-%d8%ad%db%8c%d8%a7-en","status":"publish","type":"post","link":"https:\/\/www.anynet.ir\/blog\/en\/%d8%b4%d8%a8%da%a9%d9%87%d8%b3%d8%a7%d8%b2%db%8c-%d8%ae%d9%88%d8%af%da%a9%d8%a7%d8%b1-%d8%a8%d8%a7-cisco-crosswork-%d9%85%d8%af%db%8c%d8%b1%db%8c%d8%aa-%da%86%d8%b1%d8%ae%d9%87-%d8%ad%db%8c%d8%a7-en\/","title":{"rendered":"Autonomous Networking with Cisco Crosswork: Multivendor Device  and Service Lifecycle, Segment Routing, and AI-Ready Operations"},"content":{"rendered":"<div><\/div>\n<div>\n<div><\/div>\n<\/div>\n<div>\n<div>\n<div>\n<p>Autonomous networking depends on a closed operational loop: accurate inventory, transport visibility, intent-based service provisioning, device-side validation, and service-health telemetry that can be trusted by operators and automation systems. This article shows how Cisco Crosswork Network Controller 7.2 can operate in a multivendor environment with IOS XR provider edge routers, a Juniper vMX provider edge router, and Cisco SR-PCE.<\/p>\n<p>The workflow connects inventory discovery, Segment Routing traffic engineering, L3VPN service provisioning, Junos-specific Service Health extensions, and final symptom validation. The result is not only a monitored VPN service, but an AI-ready operational model where Crosswork can expose normalized state across vendors and distinguish real service degradation from collection or package gaps.<\/p>\n<h2 style=\"color: #1a1a1a; font-weight: bold;\">Acknowledgements<\/h2>\n<p>Special Thanks to Krishnan Thirukonda, Michael Maddern, and Nicola Martino for their collaboration, guidance, and contributions to the multivendor CNC 7.2 work described in this article.<\/p>\n<h2 style=\"color: #1a1a1a; font-weight: bold;\">Why This Matters<\/h2>\n<p>In a single-vendor network, inventory, topology, service intent, and health telemetry often align naturally because every layer understands the same device models and command outputs. In a multivendor network, that alignment has to be engineered. The Junos work in this lab shows the pieces required to make Crosswork useful for autonomous operations:<\/p>\n<ul>\n<li>DLM must learn the device with the correct software type, software version, and management capabilities.<\/li>\n<li>Topology and SR-PCE must validate that the transport underlay and PCEP sessions are healthy.<\/li>\n<li>Service provisioning must create equivalent IOS XR and Junos service state.<\/li>\n<li>Service Health must collect the right gNMI, SNMP, and CLI metrics for each vendor.<\/li>\n<li>Remaining alarms must represent real service symptoms, not collection errors.<\/li>\n<\/ul>\n<p>This article walks through a multivendor Cisco Crosswork Network Controller 7.2 lab where an L3VPN service is provisioned across IOS XR provider edge routers and a Juniper vMX provider edge router. The focus is not only service provisioning, but the full chain required to make the service operationally useful for Crosswork automation and future AI-assisted operations:<\/p>\n<ul>\n<li>Device inventory and capability discovery<\/li>\n<li>Topology and traffic-engineering discovery<\/li>\n<li>L3VPN service provisioning<\/li>\n<li>Device-side validation<\/li>\n<li>Custom Service Health development for Junos<\/li>\n<li>Known gaps and enhancement requests observed during the exercise<\/li>\n<\/ul>\n<h2 style=\"color: #1a1a1a; font-weight: bold;\">What This Article Covers<\/h2>\n<p>This write-up follows the full operational path rather than only the final service screen:<\/p>\n<table class=\"english-numbers\">\n<thead>\n<tr>\n<th>Area<\/th>\n<th>What is validated<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Inventory<\/td>\n<td>Junos DLM metadata, software type, capabilities, SNMP\/CLI inventory helpers, and package upload behavior<\/td>\n<\/tr>\n<tr>\n<td>Traffic engineering<\/td>\n<td>SR-PCE, BGP-LS, PCEP, SR-TE ODN, and color-aware path resolution<\/td>\n<\/tr>\n<tr>\n<td>Service provisioning<\/td>\n<td>L3VPN VPN-4003 model, route-policy color 4003, VRF\/interface generation, and device-side validation<\/td>\n<\/tr>\n<tr>\n<td>Service health<\/td>\n<td>Custom HP rules, Junos gNMI\/SNMP\/CLI metrics, PCEP device package, and final monitored state<\/td>\n<\/tr>\n<tr>\n<td>Known gaps<\/td>\n<td>Pipeline enhancements for PROTO\/gNMI bundling and JSON complex type handling<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h2 style=\"color: #1a1a1a; font-weight: bold;\">Lab Topology<\/h2>\n<p>The lab uses Cisco Crosswork Network Controller 7.2 with Cisco IOS XR routers, a Juniper vMX router, and a Cisco SR-PCE node.<\/p>\n<table class=\"english-numbers\">\n<thead>\n<tr>\n<th>Role<\/th>\n<th>Device<\/th>\n<th>Notes<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>CNC<\/td>\n<td>Crosswork Network Controller<\/td>\n<td>CNC 7.2<\/td>\n<\/tr>\n<tr>\n<td>SR-PCE<\/td>\n<td><code>node-10<\/code><\/td>\n<td>PCE address <code>198.19.1.10<\/code><\/td>\n<\/tr>\n<tr>\n<td>IOS XR PE<\/td>\n<td><code>node-3<\/code><\/td>\n<td>IOS XR 25.3.1<\/td>\n<\/tr>\n<tr>\n<td>IOS XR PE<\/td>\n<td><code>node-4<\/code><\/td>\n<td>IOS XR 25.3.1<\/td>\n<\/tr>\n<tr>\n<td>Junos PE<\/td>\n<td><code>node-19<\/code><\/td>\n<td>Junos 22.3R1.11 vMX<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p><img decoding=\"async\" src=\"https:\/\/www.anynet.ir\/blog\/wp-content\/uploads\/2026\/10\/image-1.webp\" alt=\"\" \/><\/p>\n<p align=\"center\"><em>Figure 1: Lab topology overview<\/em><\/p>\n<h2 style=\"color: #1a1a1a; font-weight: bold;\">Device Inventory and Onboarding<\/h2>\n<p>The first requirement is for CNC Device Lifecycle Manager to recognize the Juniper device with the correct software metadata and access capabilities. For <code>node-19<\/code>, DLM showed:<\/p>\n<table class=\"english-numbers\">\n<thead>\n<tr>\n<th>Field<\/th>\n<th>Value<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Hostname<\/td>\n<td><code>node-19<\/code><\/td>\n<\/tr>\n<tr>\n<td>IP address<\/td>\n<td><code>172.20.163.40\/25<\/code><\/td>\n<\/tr>\n<tr>\n<td>Product family<\/td>\n<td>Routers<\/td>\n<\/tr>\n<tr>\n<td>Product series<\/td>\n<td>Juniper Networks vMX Routers<\/td>\n<\/tr>\n<tr>\n<td>Vendor<\/td>\n<td>Juniper Networks<\/td>\n<\/tr>\n<tr>\n<td>Software type<\/td>\n<td><code>Junos<\/code><\/td>\n<\/tr>\n<tr>\n<td>Software version<\/td>\n<td><code>22.3R1.11<\/code><\/td>\n<\/tr>\n<tr>\n<td>Capabilities<\/td>\n<td><code>SNMP;YANG_CLI;GNMI<\/code><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>This software type detail mattered. The original custom health package had some Junos metric implementations keyed on <code>JUNOS<\/code>, while DLM discovered the device as <code>Junos<\/code>. The custom namespace was updated so the HP rules match the discovered DLM software type.<\/p>\n<h3 style=\"color: #1a1a1a; font-weight: bold;\">Junos Device Validation<\/h3>\n<p>On <code>node-19<\/code>, the router version and OpenConfig telemetry paths were validated:<\/p>\n<pre><code>cisco@node-19&gt; show version | no-more\nHostname: node-19\nModel: vmx\nJunos: 22.3R1.11\nJUNOS Openconfig [22.3R1.11]\nJUNOS na telemetry [22.3R1.11]\nJUNOS RPD Telemetry Application [22.3R1.11]\n<\/code><\/pre>\n<p>The SNMP system object ID identified the platform as vMX:<\/p>\n<pre><code>cisco@node-19&gt; show snmp mib walk sysObjectID | no-more\nsysObjectID.0 = jnxProductNameVMX\n<\/code><\/pre>\n<pre><code>cisco@node-19&gt; show snmp mib walk jnxContentsDescr | no-more\njnxContentsDescr.1.1.0.0 = midplane\njnxContentsDescr.7.1.0.0 = FPC: Virtual FPC @ 0\/*\/*\njnxContentsDescr.8.1.1.0 = PIC: Virtual @ 0\/0\/*\njnxContentsDescr.9.1.0.0 = Routing Engine 0\njnxContentsDescr.20.1.1.0 = MIC: Virtual @ 0\/0\/*\n<\/code><\/pre>\n<pre><code>cisco@node-19&gt; show chassis hardware | no-more\nHardware inventory:\nItem Version Part number Serial number Description\nChassis VM67C8CD0653 VMX\nRouting Engine 0 RE-VMX\nCB 0 VMX SCB\nFPC 0 Virtual FPC\nMIC 0 Virtual\nPIC 0 Virtual\n<\/code><\/pre>\n<p>The inventory work used a custom Juniper device inventory package on CNC to learn how to collect physical and logical inventory from third-party Juniper devices. The package uses both CLI and SNMP instrumentation, rather than relying on a single source.<\/p>\n<p>The Juniper inventory helper inputs were:<\/p>\n<pre><code>CLI:\nshow lacp interfaces\nshow interfaces terse\nSNMP:\nJuniper-specific MIBs:\nJUNIPER-MIB\nCommon MIBs:\nENTITY-MIB\nENTITY-STATE-MIB\nIEEE8023-LAG-MIB\nIF-MIB\nIP-MIB\n<\/code><\/pre>\n<p><img decoding=\"async\" src=\"https:\/\/www.anynet.ir\/blog\/wp-content\/uploads\/2026\/10\/image-2.webp\" alt=\"\" \/><\/p>\n<p align=\"center\"><em>Figure 2: Juniper inventory package inputs<\/em><\/p>\n<h3 style=\"color: #1a1a1a; font-weight: bold;\">Interface Discovery<\/h3>\n<p><img decoding=\"async\" src=\"https:\/\/www.anynet.ir\/blog\/wp-content\/uploads\/2026\/10\/image-3.webp\" alt=\"\" \/><\/p>\n<p align=\"center\"><em>Figure 3: Discovered Junos interfaces<\/em><\/p>\n<h3 style=\"color: #1a1a1a; font-weight: bold;\">Device Health Snapshot<\/h3>\n<p><img decoding=\"async\" src=\"https:\/\/www.anynet.ir\/blog\/wp-content\/uploads\/2026\/10\/image-4.webp\" alt=\"\" \/><\/p>\n<p align=\"center\"><em>Figure 4: Device health view for node-19<\/em><\/p>\n<p>Node-19 appeared as IS-IS system ID 0010.0100.0019.00 with its loopback and prefix NLRI: Below output from SR-PCE<\/p>\n<pre><code>RP\/0\/RP0\/CPU0:node-10# show bgp link-state link-state | include 0010.0100.0019.00\n*&gt; [V][L2][I0x0][N[c65000][b0.0.0.0][s0010.0100.0019.00]]\/328\n*&gt; [T][L2][I0x0][N[c65000][b0.0.0.0][s0010.0100.0019.00]][P[p198.19.1.19\/32]]\/400\n*&gt; [T][L2][I0x0][N[c65000][b0.0.0.0][s0010.0100.0019.00]][P[p2010::19\/128]]\/544\n*&gt; [T][L2][I0x0][N[c65000][b0.0.0.0][s0010.0100.0019.00]][P[p2011::19\/128]]\/544\nThe database also included node-19 links to node-7 and node-9, including IPv4 and IPv6 adjacency information:\n*&gt; [E][L2][I0x0][N[c65000][b0.0.0.0][s0010.0100.0007.00]][R[c65000][b0.0.0.0][s0010.0100.0019.00]][L[i17.17.17.7][n17.17.17.19]]\/696\n*&gt; [E][L2][I0x0][N[c65000][b0.0.0.0][s0010.0100.0019.00]][R[c65000][b0.0.0.0][s0010.0100.0007.00]][L[i17.17.17.19][n17.17.17.7][i2001::7:19:19][n2001::7:19:7]]\/1016\n*&gt; [E][L2][I0x0][N[c65000][b0.0.0.0][s0010.0100.0009.00]][R[c65000][b0.0.0.0][s0010.0100.0019.00]][L[i19.19.19.9][n19.19.19.19]]\/696\n*&gt; [E][L2][I0x0][N[c65000][b0.0.0.0][s0010.0100.0019.00]][R[c65000][b0.0.0.0][s0010.0100.0009.00]][L[i19.19.19.19][n19.19.19.9][i2001::9:19:19][n2001::9:19:9]]\/1016\n<\/code><\/pre>\n<p>CNC and SR-PCE discovered L3 links between node-9 and node-19. Similar visibility was confirmed for node-7 to node-19.<\/p>\n<p><img decoding=\"async\" src=\"https:\/\/www.anynet.ir\/blog\/wp-content\/uploads\/2026\/10\/image-5.webp\" alt=\"\" \/><\/p>\n<p align=\"center\"><em>Figure 5: L3 link discovery between Junos and IOS XR nodes<\/em><\/p>\n<h2 style=\"color: #1a1a1a; font-weight: bold;\">Traffic Engineering<\/h2>\n<p>CNC traffic engineering provides the operational view of the SR underlay. It correlates topology learned through BGP-LS, PCEP session state from SR-PCE, SR-TE policy intent, computed paths, and performance-monitoring metrics. This gives operators a single place to confirm whether color-aware transport is healthy before troubleshooting VPN service symptoms.<\/p>\n<h3 style=\"color: #1a1a1a; font-weight: bold;\">SR-PCE Configuration<\/h3>\n<p>The SR-PCE had PCEP peers up, including the Junos node:<\/p>\n<pre><code>RP\/0\/RP0\/CPU0:node-10# show pce ipv4 peer\nPeer address: 198.19.1.3\nState: Up\nCapabilities: Stateful, Segment-Routing, Update, Instantiation, SRv6, SR-P2MP\nPeer address: 198.19.1.4\nState: Up\nCapabilities: Stateful, Segment-Routing, Update, Instantiation, SRv6, SR-P2MP\nPeer address: 198.19.1.19\nState: Up\nCapabilities: Stateful, Segment-Routing, Update, Instantiation\n<\/code><\/pre>\n<p>The PCE LSP database also had operational LSPs for node-19:<\/p>\n<pre><code>RP\/0\/RP0\/CPU0:node-10# show pce lsp summary\nAll peers:\nNumber of LSPs: 91\nOperational: Up: 72 Down: 19\nSetup type: RSVP: 2 Segment routing: 89\nPeer 198.19.1.19:\nNumber of LSPs: 3\nOperational: Up: 3 Down: 0\nSetup type: RSVP: 0 Segment routing: 3\n<\/code><\/pre>\n<h3 style=\"color: #1a1a1a; font-weight: bold;\">PCEP From Junos to SR-PCE<\/h3>\n<p>On <code>node-19<\/code>, Junos reported an active PCE session:<\/p>\n<pre><code>cisco@node-19&gt; show path-computation-client active-pce | no-more\nPCE ID: pce-10\nPCE IP address: 198.19.1.10\nLocal IP address: 198.19.1.19\nPCE status: PCE_STATE_UP\nSession type: PCE_TYPE_STATEFULACTIVE\nLSP provisioning allowed: On\n<\/code><\/pre>\n<p>This was the key device-side validation that PCEP was operational from the Junos PE.<\/p>\n<h2 style=\"color: #1a1a1a; font-weight: bold;\">SR-TE ODN and L3VPN Service Provisioning<\/h2>\n<p>T-SDN FP was extended southbound for Junos. The reference implementation is available at <a style=\"color: #0066cc;\" href=\"https:\/\/github.com\/maddn\/tsdn-tme-multi-vendor\">maddn\/tsdn-tme-multi-vendor<\/a>.<\/p>\n<p><code>VPN-4003<\/code> was provisioned as an L3VPN service across node-3, node-4, and node-19. The service model generated VRF, interface, route-target, and route-policy configuration.<\/p>\n<p>ODN template:<\/p>\n<details>\n<summary>Show ODN template JSON<\/summary>\n<pre><code>{\n \"cisco-sr-te-cfp:sr-te\": {\n \"cisco-sr-te-cfp-sr-odn:odn\": {\n \"odn-template\": [\n {\n \"name\": \"odn_low_latency_4003\",\n \"performance-measurement\": {\n \"delay-measurement\": {\n \"profile\": \"2wayDelay\"\n }\n },\n \"head-end\": [\n {\n \"name\": \"node-19\"\n },\n {\n \"name\": \"node-3\"\n },\n {\n \"name\": \"node-4\"\n }\n ],\n \"color\": 4003,\n \"dynamic\": {\n \"pce\": {},\n \"metric-type\": \"latency\"\n }\n }\n ]\n }\n }\n}\n<\/code><\/pre>\n<\/details>\n<h3 style=\"color: #1a1a1a; font-weight: bold;\">VPN-4003 Service Payload with Route Policy<\/h3>\n<details>\n<summary>Show VPN-4003 service payload JSON<\/summary>\n<pre><code>{\n \"cisco-l3vpn-routing-policy:l3vpn-routing-policy\": {\n \"defined-sets\": {\n \"prefix-sets\": {\n \"dest-prefix-set\": [\n {\n \"name\": \"dest_4003\",\n \"prefixes\": {\n \"prefix-list\": [\n {\n \"ip-prefix\": \"140.43.3.0\/24\"\n },\n {\n \"ip-prefix\": \"140.43.4.0\/24\"\n },\n {\n \"ip-prefix\": \"140.43.19.0\/24\"\n }\n ]\n }\n }\n ]\n },\n \"tag-sets\": {\n \"tag-set\": [\n {\n \"name\": \"color_4003\",\n \"tag-value\": [\n 4003\n ]\n }\n ]\n }\n },\n \"policy-definitions\": {\n \"policy-definition\": [\n {\n \"name\": \"VPN-4003-ROUTE-POLICY\",\n \"statements\": {\n \"statement\": [\n {\n \"name\": \"stmnt_4003\",\n \"conditions\": {\n \"match-dest-prefix-set\": {\n \"prefix-set\": \"dest_4003\"\n }\n },\n \"actions\": {\n \"bgp-actions\": {\n \"set-ext-community\": {\n \"ext-community-set-ref\": \"color_4003\"\n }\n }\n }\n }\n ]\n }\n }\n ]\n }\n }\n}\n{\n \"ietf-l3vpn-ntw:l3vpn-ntw\": {\n \"vpn-services\": {\n \"vpn-service\": [\n {\n \"vpn-id\": \"VPN-4003\",\n \"vpn-service-topology\": \"ietf-vpn-common:any-to-any\",\n \"vpn-instance-profiles\": {\n \"vpn-instance-profile\": [\n {\n \"profile-id\": \"VPN-4003-profile\",\n \"rd\": \"0:65000:4003\",\n \"address-family\": [\n {\n \"address-family\": \"ietf-vpn-common:ipv4\",\n \"vpn-targets\": {\n \"vpn-target\": [\n {\n \"id\": 1,\n \"route-targets\": [\n {\n \"route-target\": \"0:65000:4003\"\n }\n ],\n \"route-target-type\": \"both\"\n }\n ],\n \"vpn-policies\": {\n \"export-policy\": \"VPN-4003-ROUTE-POLICY\"\n }\n }\n }\n ]\n }\n ]\n },\n \"vpn-nodes\": {\n \"vpn-node\": [\n {\n \"vpn-node-id\": \"node-19\",\n \"active-vpn-instance-profiles\": {\n \"vpn-instance-profile\": [\n {\n \"profile-id\": \"VPN-4003-profile\"\n }\n ]\n },\n \"vpn-network-accesses\": {\n \"vpn-network-access\": [\n {\n \"id\": \"vmx-9-vpn4003\",\n \"interface-id\": \"HundredGigE0\/0\/3\",\n \"connection\": {\n \"encapsulation\": {\n \"type\": \"ietf-vpn-common:dot1q\",\n \"dot1q\": {\n \"cvlan-id\": 4003\n }\n }\n },\n \"ip-connection\": {\n \"ipv4\": {\n \"local-address\": \"140.43.19.1\",\n \"prefix-length\": 24\n }\n },\n \"routing-protocols\": {\n \"routing-protocol\": [\n {\n \"id\": \"0\",\n \"type\": \"ietf-vpn-common:bgp-routing\",\n \"bgp\": {\n \"peer-as\": 65002,\n \"address-family\": \"ipv4\",\n \"neighbor\": [\n \"140.43.19.2\"\n ],\n \"redistribute-connected\": [\n {\n \"address-family\": \"ietf-vpn-common:ipv4\",\n \"enable\": true\n }\n ],\n \"cisco-l3vpn-ntw:mpls-deactivation\": false\n }\n }\n ]\n }\n }\n ]\n }\n },\n {\n \"vpn-node-id\": \"node-3\",\n \"active-vpn-instance-profiles\": {\n \"vpn-instance-profile\": [\n {\n \"profile-id\": \"VPN-4003-profile\"\n }\n ]\n },\n \"vpn-network-accesses\": {\n \"vpn-network-access\": [\n {\n \"id\": \"node-3-vpn4003\",\n \"interface-id\": \"TenGigE0\/0\/0\/13\",\n \"connection\": {\n \"encapsulation\": {\n \"type\": \"ietf-vpn-common:dot1q\",\n \"dot1q\": {\n \"cvlan-id\": 4003\n }\n }\n },\n \"ip-connection\": {\n \"ipv4\": {\n \"local-address\": \"140.43.3.1\",\n \"prefix-length\": 24\n }\n },\n \"routing-protocols\": {\n \"routing-protocol\": [\n {\n \"id\": \"0\",\n \"type\": \"ietf-vpn-common:bgp-routing\",\n \"bgp\": {\n \"peer-as\": 65000,\n \"address-family\": \"ipv4\",\n \"neighbor\": [\n \"140.43.3.2\"\n ],\n \"redistribute-connected\": [\n {\n \"address-family\": \"ietf-vpn-common:ipv4\",\n \"enable\": true\n }\n ],\n \"cisco-l3vpn-ntw:mpls-deactivation\": false\n }\n }\n ]\n }\n }\n ]\n }\n },\n {\n \"vpn-node-id\": \"node-4\",\n \"active-vpn-instance-profiles\": {\n \"vpn-instance-profile\": [\n {\n \"profile-id\": \"VPN-4003-profile\"\n }\n ]\n },\n \"vpn-network-accesses\": {\n \"vpn-network-access\": [\n {\n \"id\": \"node-4-vpn4003\",\n \"interface-id\": \"TenGigE0\/0\/0\/16\",\n \"connection\": {\n \"encapsulation\": {\n \"type\": \"ietf-vpn-common:dot1q\",\n \"dot1q\": {\n \"cvlan-id\": 4003\n }\n }\n },\n \"ip-connection\": {\n \"ipv4\": {\n \"local-address\": \"140.43.4.1\",\n \"prefix-length\": 24\n }\n },\n \"routing-protocols\": {\n \"routing-protocol\": [\n {\n \"id\": \"0\",\n \"type\": \"ietf-vpn-common:bgp-routing\",\n \"bgp\": {\n \"peer-as\": 65000,\n \"address-family\": \"ipv4\",\n \"neighbor\": [\n \"140.43.4.2\"\n ],\n \"redistribute-connected\": [\n {\n \"address-family\": \"ietf-vpn-common:ipv4\",\n \"enable\": true\n }\n ],\n \"cisco-l3vpn-ntw:mpls-deactivation\": false\n }\n }\n ]\n }\n }\n ]\n }\n }\n ]\n }\n }\n ]\n }\n }\n}\n<\/code><\/pre>\n<\/details>\n<h3 style=\"color: #1a1a1a; font-weight: bold;\">VPN Service Verification<\/h3>\n<p><img decoding=\"async\" src=\"https:\/\/www.anynet.ir\/blog\/wp-content\/uploads\/2026\/10\/image-6.webp\" alt=\"\" \/><\/p>\n<p align=\"center\"><em>Figure 6: VPN-4003 service verification<\/em><\/p>\n<h3 style=\"color: #1a1a1a; font-weight: bold;\">Node-19 PE-CE Interface Details<\/h3>\n<p><img decoding=\"async\" src=\"https:\/\/www.anynet.ir\/blog\/wp-content\/uploads\/2026\/10\/image-7.webp\" alt=\"\" \/><\/p>\n<p align=\"center\"><em>Figure 7: node-19 PE-CE interface details<\/em><\/p>\n<h3 style=\"color: #1a1a1a; font-weight: bold;\">Junos Provisioned Configuration pushed by CNC<\/h3>\n<p>The Junos service-facing interface was provisioned as logical unit <code>4003<\/code> on <code>et-0\/0\/3<\/code>:<\/p>\n<pre><code>&lt;device&gt;\n &lt;name&gt;node-19&lt;\/name&gt;\n &lt;config&gt;\n &lt;configuration xmlns=\"http:\/\/xml.juniper.net\/xnm\/1.1\/xnm\"&gt;\n &lt;interfaces&gt;\n &lt;interface&gt;\n &lt;name&gt;et-0\/0\/3&lt;\/name&gt;\n &lt;vlan-tagging\/&gt;\n &lt;unit&gt;\n &lt;name&gt;4003&lt;\/name&gt;\n &lt;vlan-id&gt;4003&lt;\/vlan-id&gt;\n &lt;family&gt;\n &lt;inet&gt;\n &lt;address&gt;\n &lt;name&gt;140.43.19.1\/24&lt;\/name&gt;\n &lt;\/address&gt;\n &lt;\/inet&gt;\n &lt;\/family&gt;\n &lt;\/unit&gt;\n &lt;\/interface&gt;\n &lt;\/interfaces&gt;\n &lt;routing-options&gt;\n &lt;dynamic-tunnels&gt;\n &lt;dynamic-tunnel&gt;\n &lt;name&gt;dynamic-tunnel-odn&lt;\/name&gt;\n &lt;spring-te&gt;\n &lt;source-routing-path-template&gt;\n &lt;name&gt;odn_low_latency_4003&lt;\/name&gt;\n &lt;color&gt;4003&lt;\/color&gt;\n &lt;\/source-routing-path-template&gt;\n &lt;destination-networks&gt;\n &lt;name&gt;0.0.0.0\/0&lt;\/name&gt;\n &lt;\/destination-networks&gt;\n &lt;\/spring-te&gt;\n &lt;\/dynamic-tunnel&gt;\n &lt;\/dynamic-tunnels&gt;\n &lt;\/routing-options&gt;\n &lt;policy-options&gt;\n &lt;policy-statement&gt;\n &lt;name&gt;VPN-4003-ROUTE-POLICY-export-add-color&lt;\/name&gt;\n &lt;term&gt;\n &lt;name&gt;color-4003&lt;\/name&gt;\n &lt;from&gt;\n &lt;protocol&gt;direct&lt;\/protocol&gt;\n &lt;\/from&gt;\n &lt;then&gt;\n &lt;community&gt;\n &lt;key1&gt;add&lt;\/key1&gt;\n &lt;community-name&gt;color-4003&lt;\/community-name&gt;\n &lt;\/community&gt;\n &lt;\/then&gt;\n &lt;\/term&gt;\n &lt;\/policy-statement&gt;\n &lt;policy-statement&gt;\n &lt;name&gt;VPN-4003-export&lt;\/name&gt;\n &lt;term&gt;\n &lt;name&gt;ipv4&lt;\/name&gt;\n &lt;from&gt;\n &lt;family&gt;inet&lt;\/family&gt;\n &lt;protocol&gt;bgp&lt;\/protocol&gt;\n &lt;protocol&gt;direct&lt;\/protocol&gt;\n &lt;\/from&gt;\n &lt;then&gt;\n &lt;community&gt;\n &lt;key1&gt;add&lt;\/key1&gt;\n &lt;community-name&gt;VPN-4003-ipv4-community-export&lt;\/community-name&gt;\n &lt;\/community&gt;\n &lt;accept\/&gt;\n &lt;\/then&gt;\n &lt;\/term&gt;\n &lt;\/policy-statement&gt;\n &lt;policy-statement&gt;\n &lt;name&gt;VPN-4003-import&lt;\/name&gt;\n &lt;term&gt;\n &lt;name&gt;ipv4&lt;\/name&gt;\n &lt;from&gt;\n &lt;family&gt;inet&lt;\/family&gt;\n &lt;protocol&gt;bgp&lt;\/protocol&gt;\n &lt;community&gt;VPN-4003-ipv4-community-import&lt;\/community&gt;\n &lt;\/from&gt;\n &lt;then&gt;\n &lt;accept\/&gt;\n &lt;resolution-map&gt;map-ip-color&lt;\/resolution-map&gt;\n &lt;\/then&gt;\n &lt;\/term&gt;\n &lt;\/policy-statement&gt;\n &lt;community&gt;\n &lt;name&gt;VPN-4003-ipv4-community-export&lt;\/name&gt;\n &lt;members&gt;target:41:41&lt;\/members&gt;\n &lt;members&gt;target:65000:4003&lt;\/members&gt;\n &lt;\/community&gt;\n &lt;community&gt;\n &lt;name&gt;VPN-4003-ipv4-community-import&lt;\/name&gt;\n &lt;members&gt;target:41:41&lt;\/members&gt;\n &lt;members&gt;target:65000:4003&lt;\/members&gt;\n &lt;\/community&gt;\n &lt;community&gt;\n &lt;name&gt;color-4003&lt;\/name&gt;\n &lt;members&gt;color:0:4003&lt;\/members&gt;\n &lt;\/community&gt;\n &lt;resolution-map&gt;\n &lt;name&gt;map-ip-color&lt;\/name&gt;\n &lt;mode&gt;ip-color&lt;\/mode&gt;\n &lt;\/resolution-map&gt;\n &lt;\/policy-options&gt;\n &lt;class-of-service&gt;\n &lt;interfaces&gt;\n &lt;interface&gt;\n &lt;name&gt;et-0\/0\/3&lt;\/name&gt;\n &lt;unit&gt;\n &lt;name&gt;4003&lt;\/name&gt;\n &lt;\/unit&gt;\n &lt;\/interface&gt;\n &lt;\/interfaces&gt;\n &lt;\/class-of-service&gt;\n &lt;routing-instances&gt;\n &lt;instance&gt;\n &lt;name&gt;VPN-4003&lt;\/name&gt;\n &lt;instance-type&gt;vrf&lt;\/instance-type&gt;\n &lt;interface&gt;\n &lt;name&gt;et-0\/0\/3.4003&lt;\/name&gt;\n &lt;\/interface&gt;\n &lt;route-distinguisher&gt;\n &lt;rd-type&gt;65000:4003&lt;\/rd-type&gt;\n &lt;\/route-distinguisher&gt;\n &lt;vrf-import&gt;VPN-4003-import&lt;\/vrf-import&gt;\n &lt;vrf-export&gt;VPN-4003-ROUTE-POLICY-export-add-color&lt;\/vrf-export&gt;\n &lt;vrf-export&gt;VPN-4003-export&lt;\/vrf-export&gt;\n &lt;vrf-table-label\/&gt;\n &lt;routing-options&gt;\n &lt;autonomous-system\/&gt;\n &lt;\/routing-options&gt;\n &lt;protocols&gt;\n &lt;bgp&gt;\n &lt;group&gt;\n &lt;name&gt;external-peers&lt;\/name&gt;\n &lt;type&gt;external&lt;\/type&gt;\n &lt;neighbor&gt;\n &lt;name&gt;140.43.19.2&lt;\/name&gt;\n &lt;peer-as&gt;65002&lt;\/peer-as&gt;\n &lt;\/neighbor&gt;\n &lt;\/group&gt;\n &lt;\/bgp&gt;\n &lt;source-packet-routing&gt;\n &lt;compute-profile&gt;\n &lt;name&gt;odn_low_latency_4003-profile&lt;\/name&gt;\n &lt;maximum-computed-segment-lists&gt;1&lt;\/maximum-computed-segment-lists&gt;\n &lt;metric-type&gt;\n &lt;delay&gt;\n &lt;minimum\/&gt;\n &lt;\/delay&gt;\n &lt;\/metric-type&gt;\n &lt;\/compute-profile&gt;\n &lt;source-routing-path-template&gt;\n &lt;name&gt;odn_low_latency_4003&lt;\/name&gt;\n &lt;lsp-external-controller&gt;pccd&lt;\/lsp-external-controller&gt;\n &lt;primary&gt;\n &lt;name&gt;odn_low_latency_4003-dynamic&lt;\/name&gt;\n &lt;compute&gt;\n &lt;compute-profile-name&gt;odn_low_latency_4003-profile&lt;\/compute-profile-name&gt;\n &lt;\/compute&gt;\n &lt;\/primary&gt;\n &lt;\/source-routing-path-template&gt;\n &lt;\/source-packet-routing&gt;\n &lt;\/protocols&gt;\n &lt;\/instance&gt;\n &lt;\/routing-instances&gt;\n &lt;\/configuration&gt;\n &lt;\/config&gt;\n&lt;\/device&gt;\n<\/code><\/pre>\n<h3 style=\"color: #1a1a1a; font-weight: bold;\">Node-19 Verification<\/h3>\n<p>The route table showed reachability to the other VPN sites via the SR core:<\/p>\n<pre><code>cisco@node-19&gt; show route table VPN-4003.inet.0 | no-more\nVPN-4003.inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)\n+ = Active Route, - = Last Active, * = Both\n140.43.3.0\/24 *[BGP\/170] via 198.19.2.6\nLabel operation: Push 25623, Push 15003(top)\n140.43.4.0\/24 *[BGP\/170] via 198.19.2.6\nLabel operation: Push 25622, Push 15009, Push 15003(top)\n140.43.19.1\/32 *[Local\/0] Reject\n140.43.19.19\/32 *[Direct\/0] via lo0.4003\nFinally, the VPN routes in VPN-4003.inet.0 were resolved to the color-specific protocol next hops:\n140.43.3.0\/24\nCommunities: target:41:41 target:65000:4003 color:0:4003\nProtocol next hop: 198.19.1.3-4003&lt;c&gt;\nLabel operation: Push 25623, Push 15003(top)\n140.43.4.0\/24\nCommunities: target:41:41 target:65000:4003 color:0:4003\nProtocol next hop: 198.19.1.4-4003&lt;c&gt;\nLabel operation: Push 25622, Push 15009, Push 15003(top)\n<\/code><\/pre>\n<h3 style=\"color: #1a1a1a; font-weight: bold;\">IOS XR Provisioned Configuration<\/h3>\n<p>On node-3, the VRF and export route-policy were provisioned:<\/p>\n<pre><code>RP\/0\/RP0\/CPU0:node-3# show running-config vrf VPN-4003\nvrf VPN-4003\naddress-family ipv4 unicast\nimport route-target\n41:41\n65000:4003\n!\nexport route-policy VPN-4003-ROUTE-POLICY\nexport route-target\n41:41\n65000:4003\n!\n!\n!\n<\/code><\/pre>\n<p>The route-policy tagged the relevant VPN prefixes with color <code>4003<\/code>, which triggered BGP ODN SR-TE policy creation:<\/p>\n<pre><code>RP\/0\/RP0\/CPU0:node-3# show running-config route-policy VPN-4003-ROUTE-POLICY\nroute-policy VPN-4003-ROUTE-POLICY\nif destination in (140.43.19.0\/24, 140.43.3.0\/24, 140.43.4.0\/24) then\nset extcommunity color COLOR_4003\nendif\nend-policy\n!\n<\/code><\/pre>\n<p>Node-4 had the same VRF and route-policy model:<\/p>\n<pre><code>RP\/0\/RP0\/CPU0:node-4# show running-config vrf VPN-4003\nvrf VPN-4003\naddress-family ipv4 unicast\nimport route-target\n41:41\n65000:4003\n!\nexport route-policy VPN-4003-ROUTE-POLICY\nexport route-target\n41:41\n65000:4003\n!\n!\n!\n<\/code><\/pre>\n<pre><code>RP\/0\/RP0\/CPU0:node-4# show running-config route-policy VPN-4003-ROUTE-POLICY\nroute-policy VPN-4003-ROUTE-POLICY\nif destination in (140.43.19.0\/24, 140.43.3.0\/24, 140.43.4.0\/24) then\nset extcommunity color COLOR_4003\nendif\nend-policy\n!\n<\/code><\/pre>\n<p>The service-facing IOS XR subinterfaces were validated from the running configuration as well.<\/p>\n<p>Node-3:<\/p>\n<pre><code>RP\/0\/RP0\/CPU0:node-3# show running-config interface TenGigE0\/0\/0\/13.4003\ninterface TenGigE0\/0\/0\/13.4003\ndescription T-SDN Interface\nvrf VPN-4003\nipv4 address 140.43.3.1 255.255.255.0\nencapsulation dot1q 4003\n!\n<\/code><\/pre>\n<p>Node-4:<\/p>\n<pre><code>RP\/0\/RP0\/CPU0:node-4# show running-config interface TenGigE0\/0\/0\/16.4003\ninterface TenGigE0\/0\/0\/16.4003\ndescription T-SDN Interface\nvrf VPN-4003\nipv4 address 140.43.4.1 255.255.255.0\nencapsulation dot1q 4003\n!\n<\/code><\/pre>\n<h2 style=\"color: #1a1a1a; font-weight: bold;\">SR-TE ODN Validation<\/h2>\n<p>After the route-policy color was applied, IOS XR created BGP ODN SR-TE policies for VPN reachability.<\/p>\n<p>On node-3, the policy to the Junos PE endpoint <code>198.19.1.19<\/code> was active:<\/p>\n<pre><code>Color: 4003, End-point: 198.19.1.19\nName: srte_c_4003_ep_198.19.1.19\nStatus:\nAdmin: up Operational: up\nCandidate-paths:\nPreference: 100 (BGP ODN) (active)\nDynamic (pce 198.19.1.10) (valid)\nMetric Type: LATENCY\nPath Accumulated Metric: 14\nAttributes:\nBinding SID: 25636\nPath Type: SRMPLSv4\n<\/code><\/pre>\n<p>On node-4, the policy to the Junos PE endpoint was also active:<\/p>\n<pre><code>Color: 4003, End-point: 198.19.1.19\nName: srte_c_4003_ep_198.19.1.19\nStatus:\nAdmin: up Operational: up\nCandidate-paths:\nPreference: 100 (BGP ODN) (active)\nDynamic (pce 198.19.1.10) (valid)\nMetric Type: LATENCY\nPath Accumulated Metric: 25\nAttributes:\nBinding SID: 25631\nPath Type: SRMPLSv4\n<\/code><\/pre>\n<pre><code>cisco@node-19&gt; show spring-traffic-engineering lsp | no-more\nTo State LSPname\n198.19.1.3-4003&lt;c&gt; Up 198.19.1.3:fa3:dt-srte-dynamic-tunnel-odn\n198.19.1.4-4003&lt;c&gt; Up 198.19.1.4:fa3:dt-srte-dynamic-tunnel-odn\nTotal displayed LSPs: 3 (Up: 3, Down: 0)\n<\/code><\/pre>\n<p>The <code>inetcolor.0<\/code> table confirmed that the color-aware next hops for node-3 and node-4 resolved through SPRING-TE:<\/p>\n<pre><code>cisco@node-19&gt; show route table inetcolor.0 | no-more\n198.19.1.3-4003&lt;c&gt;\/64\n*[SPRING-TE\/8] metric 20, metric2 30\n&gt; to 17.17.17.7 via et-0\/0\/0.0, Push 15003\n198.19.1.4-4003&lt;c&gt;\/64\n*[SPRING-TE\/8] metric 30, metric2 30\n&gt; to 17.17.17.7 via et-0\/0\/0.0, Push 15009, Push 15003(top)\ncisco@node-19&gt; show spring-traffic-engineering lsp color 4003 detail\nName: 198.19.1.3:fa3:dt-srte-dynamic-tunnel-odn\nTunnel-source: Dynamic Tunnel Module(DTM)\nTunnel Forward Type: SRMPLS\nTunnel-template: odn_low_latency_4003\nTo: 198.19.1.3-4003&lt;c&gt;\nState: Up\nPath: odn_low_latency_4003-dynamic\nPath Status: NA\nOutgoing interface: NA\nDelegation info:\nControl-status: Externally controlled\nRouting-status: Externally routed\nAuto-translate status: Disabled Auto-translate result: N\/A\nBFD status: N\/A BFD name: N\/A\nSegment ID: 128\nERO Valid: true\nSR-ERO hop count: 2\nHop 1 (Strict):\nNAI: IPv4 Adjacency ID, 17.17.17.19 -&gt; 17.17.17.7\nSID type: 20-bit label, Value: 19\nHop 2 (Strict):\nNAI: IPv4 Adjacency ID, 10.3.7.7 -&gt; 10.3.7.3\nSID type: 20-bit label, Value: 15003\nName: 198.19.1.4:fa3:dt-srte-dynamic-tunnel-odn\nTunnel-source: Dynamic Tunnel Module(DTM)\nTunnel Forward Type: SRMPLS\nTunnel-template: odn_low_latency_4003\nTo: 198.19.1.4-4003&lt;c&gt;\nState: Up\nPath: odn_low_latency_4003-dynamic\nPath Status: NA\nOutgoing interface: NA\nDelegation info:\nControl-status: Externally controlled\nRouting-status: Externally routed\nAuto-translate status: Disabled Auto-translate result: N\/A\nBFD status: N\/A BFD name: N\/A\nSegment ID: 128\nERO Valid: true\nSR-ERO hop count: 3\nHop 1 (Strict):\nNAI: IPv4 Adjacency ID, 17.17.17.19 -&gt; 17.17.17.7\nSID type: 20-bit label, Value: 19\nHop 2 (Strict):\nNAI: IPv4 Adjacency ID, 10.3.7.7 -&gt; 10.3.7.3\nSID type: 20-bit label, Value: 15003\nHop 3 (Strict):\nNAI: IPv4 Adjacency ID, 10.3.4.3 -&gt; 10.3.4.4\nSID type: 20-bit label, Value: 15009\nTotal displayed LSPs: 2 (Up: 2, Down: 0)\ncisco@node-19&gt;\n<\/code><\/pre>\n<h3 style=\"color: #1a1a1a; font-weight: bold;\">SR Performance Measurement on Node-3<\/h3>\n<p>SR Performance Measurement confirms that the SR-TE policy is not only instantiated, but actively measuring path delay and packet loss. In this lab, node-3 reported delay measurements for color 4003 policies toward the Junos endpoint and the IOS XR endpoint, proving that transport telemetry was available for CNC traffic-engineering validation. Also similar output is seen for node-4.<\/p>\n<pre><code>RP\/0\/RP0\/CPU0:node-3# show performance-measurement sr-policy color 4003\nThu Jun 25 22:49:31.839 UTC\n----------------------------------------------------------------------------------------------------------------------------------------------------------------\n0\/RP0\/CPU0\n----------------------------------------------------------------------------------------------------------------------------------------------------------------\nSR Policy name: srte_c_4003_ep_198.19.1.19\nColor: 4003\nSRv6 Encap Source Address: 2010::3\nEndpoint: 198.19.1.19\nNumber of candidate-paths: 1\nCandidate-Path:\nInstance: 6\nPreference: 100\nProtocol-origin: BGP (20)\nDiscriminator: 100\nProfile Keys:\nProfile name: 2wayDelay\nProfile type: Generic Delay Measurement\nSource address: 198.19.1.3\nNumber of segment-lists: 1\nTimestamp source: Hardware (local)\nTimestamp format: PTP\nLast advertisement:\nAdvertised at: Jun 25 2026 22:36:36.117 (775.759 seconds ago)\nAdvertised delays (uSec): avg: 412, min: 99, max: 18246, variance: 313\nPackets sent: 2000, received: 1999, lost: 1\nMin-Max A flag set: False\nAnomaly-Loss A flag set: False\nNext advertisement:\nCheck scheduled at the end of the current computation (roughly every 60 seconds)\nNo probes completed\nRolling average (uSec): 415\nLast computation:\nPackets sent: 2000, received: 2000, lost: 0\nMeasured delays (uSec): avg: 409, min: 116, max: 18877, variance: 293\nMin-Max A flag set: False\nAnomaly-Loss A flag set: False\nCurrent computation:\nStarted at: Jun 25 2026 22:48:57.975 (33.901 seconds ago)\nPackets sent: 1097, received: 1097, lost: 0\nMeasured delays (uSec): avg: 488, min: 112, max: 19622, variance: 376\nNext probe scheduled at: Jun 25 2026 22:49:58.983 (in 27.107 seconds)\nNext packet will be sent in 0.17 seconds\nPacket sent every 0.30000 seconds\nLiveness Detection: Disabled\nSR Policy name: srte_c_4003_ep_198.19.1.4\nColor: 4003\nSRv6 Encap Source Address: 2010::3\nEndpoint: 198.19.1.4\nNumber of candidate-paths: 1\nCandidate-Path:\nInstance: 2\nPreference: 100\nProtocol-origin: BGP (20)\nDiscriminator: 100\nProfile Keys:\nProfile name: 2wayDelay\nProfile type: Generic Delay Measurement\nSource address: 198.19.1.3\nNumber of segment-lists: 1\nTimestamp source: Hardware (local)\nTimestamp format: PTP\nLast advertisement:\nAdvertised at: Jun 25 2026 13:11:05.811 (34706.65 seconds ago)\nAdvertised delays (uSec): avg: 8, min: 6, max: 12, variance: 2\nPackets sent: 2000, received: 1999, lost: 1\nMin-Max A flag set: False\nAnomaly-Loss A flag set: False\nNext advertisement:\nCheck scheduled at the end of the current computation (roughly every 60 seconds)\nNo probes completed\nRolling average (uSec): 8\nLast computation:\nPackets sent: 2000, received: 2000, lost: 0\nMeasured delays (uSec): avg: 8, min: 6, max: 13, variance: 2\nMin-Max A flag set: False\nAnomaly-Loss A flag set: False\nCurrent computation:\nStarted at: Jun 25 2026 22:49:16.688 (15.188 seconds ago)\nPackets sent: 492, received: 492, lost: 0\nMeasured delays (uSec): avg: 8, min: 6, max: 12, variance: 2\nNext probe scheduled at: Jun 25 2026 22:50:17.133 (in 45.257 seconds)\nNext packet will be sent in 0.17 seconds\nPacket sent every 0.30000 seconds\nLiveness Detection: Disabled\n<\/code><\/pre>\n<p>This validates that the SR-TE transport layer and BGP color\/ODN logic were functioning.<\/p>\n<p>CNC traffic-engineering visualization:<\/p>\n<p><img decoding=\"async\" src=\"https:\/\/www.anynet.ir\/blog\/wp-content\/uploads\/2026\/10\/image-8.webp\" alt=\"\" \/><\/p>\n<p align=\"center\"><em>Figure 8: CNC traffic-engineering topology view<\/em><\/p>\n<p><img decoding=\"async\" src=\"https:\/\/www.anynet.ir\/blog\/wp-content\/uploads\/2026\/10\/image-9.webp\" alt=\"\" \/><\/p>\n<p align=\"center\"><em>Figure 9: SR-TE path visualization<\/em><\/p>\n<p><img decoding=\"async\" src=\"https:\/\/www.anynet.ir\/blog\/wp-content\/uploads\/2026\/10\/image-10.webp\" alt=\"\" \/><\/p>\n<p align=\"center\"><em>Figure 10: Color-aware policy visualization<\/em><\/p>\n<p>Performance-monitoring metrics:<\/p>\n<p><img decoding=\"async\" src=\"https:\/\/www.anynet.ir\/blog\/wp-content\/uploads\/2026\/10\/image-11.webp\" alt=\"\" \/><\/p>\n<p align=\"center\"><em>Figure 11: Performance-monitoring metrics<\/em><\/p>\n<h2 style=\"color: #1a1a1a; font-weight: bold;\">Service Health Extension for Junos<\/h2>\n<p>CNC Service Health uses heuristic packages to define rules, subservices, metrics, thresholds, and symptoms. The system namespace already covers Cisco IOS XR behavior. For Junos, a custom HP namespace was needed.<\/p>\n<p>The custom HP work focused on these subservices:<\/p>\n<table class=\"english-numbers\">\n<thead>\n<tr>\n<th>Subservice<\/th>\n<th>Purpose<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><code>subservice.l3vpn.vpn.node.summary custom<\/code><\/td>\n<td>Per-node L3VPN health summary<\/td>\n<\/tr>\n<tr>\n<td><code>subservice.interface.health custom<\/code><\/td>\n<td>VPN access interface health<\/td>\n<\/tr>\n<tr>\n<td><code>subservice.device.health custom<\/code><\/td>\n<td>Device CPU and memory health<\/td>\n<\/tr>\n<tr>\n<td><code>subservice.bgp.nbr.health custom<\/code><\/td>\n<td>Core BGP neighbor health<\/td>\n<\/tr>\n<tr>\n<td><code>subservice.ebgp.nbr.health custom<\/code><\/td>\n<td>VRF eBGP neighbor health<\/td>\n<\/tr>\n<tr>\n<td><code>subservice.vrf.route.health custom<\/code><\/td>\n<td>VRF route reachability health<\/td>\n<\/tr>\n<tr>\n<td><code>subservice.pcep.session.health custom<\/code><\/td>\n<td>PCEP session health<\/td>\n<\/tr>\n<tr>\n<td><code>subservice.dynamic.l3vpn.sr.policy custom<\/code><\/td>\n<td>SR policy health for VPN color\/endpoints<\/td>\n<\/tr>\n<tr>\n<td><code>subservice.sr.policy.pm.health custom<\/code><\/td>\n<td>SR policy performance-monitoring health for IOS XR<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>Details are available on GitHub: <a style=\"color: #0066cc;\" href=\"https:\/\/github.com\/sujmurth\/CNC7.2-Multivendor-Service_Health_Heuristic_Package-Junos\">CNC 7.2 Multivendor Service Health Heuristic Package for Junos<\/a><\/p>\n<h2 style=\"color: #1a1a1a; font-weight: bold;\">Final Service Health State<\/h2>\n<p>After the custom HP and PCEP CLI package updates, CNC showed <code>VPN-4003<\/code> with:<\/p>\n<pre><code>Monitoring status: Success\nSubservices: 27\nGood: 17\nDegraded: 10\nDown: 0\nActive symptoms: 4\n<\/code><\/pre>\n<p><img decoding=\"async\" src=\"https:\/\/www.anynet.ir\/blog\/wp-content\/uploads\/2026\/10\/image-12.webp\" alt=\"\" \/><\/p>\n<p align=\"center\"><em>Figure 12: VPN-4003 service-health summary<\/em><\/p>\n<p><img decoding=\"async\" src=\"https:\/\/www.anynet.ir\/blog\/wp-content\/uploads\/2026\/10\/image-13.webp\" alt=\"\" \/><\/p>\n<p align=\"center\"><em>Figure 13: VPN-4003 subservice health details<\/em><\/p>\n<p><img decoding=\"async\" src=\"https:\/\/www.anynet.ir\/blog\/wp-content\/uploads\/2026\/10\/image-14.webp\" alt=\"\" \/><\/p>\n<p align=\"center\"><em>Figure 14: VPN-4003 active symptoms<\/em><\/p>\n<p>The remaining active symptoms were real service symptoms, not collection failures:<\/p>\n<pre><code>eBGP Session to neighbor 140.43.3.2 is not up for Device: node-3, Vrf: VPN-4003\neBGP Session to neighbor 140.43.19.2 is not up for Device: node-19, Vrf: VPN-4003\nVPN interface HundredGigE0\/0\/3.4003 operational status is not up.\neBGP Session to neighbor 140.43.4.2 is not up for Device: node-4, Vrf: VPN-4003\n<\/code><\/pre>\n<p>The device validation confirmed these symptoms.<\/p>\n<p>On node-19, the CE-facing VPN interface was down and the VRF eBGP neighbor was idle:<\/p>\n<pre><code>cisco@node-19&gt; show bgp summary | no-more\nPeer AS InPkt OutPkt Out\nQ Flaps Last Up\/Dwn State\n140.43.19.2 65002 0 0 0 0 Idle\n<\/code><\/pre>\n<pre><code>cisco@node-19&gt; show bgp neighbor 140.43.19.2 | match \"Peer|State|Error|flap\"\nPeer: 140.43.19.2 AS 65002 Local: unspecified AS 65000\nType: External State: Idle Flags: &lt;PeerInterfaceUnknown&gt;\nLast Error: None\nNumber of flaps: 0\n<\/code><\/pre>\n<p>On node-3, the VPN CE neighbor was Active:<\/p>\n<pre><code>RP\/0\/RP0\/CPU0:node-3# show bgp vrf VPN-4003 ipv4 unicast summary\nNeighbor Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up\/Down St\/PfxRcd\n140.43.3.2 0 65000 0 0 0 0 0 00:00:00 Active\n<\/code><\/pre>\n<p>On node-4, the VPN CE neighbor was also Active:<\/p>\n<pre><code>RP\/0\/RP0\/CPU0:node-4# show bgp vrf VPN-4003 ipv4 unicast summary\nNeighbor Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up\/Down St\/PfxRcd\n140.43.4.2 0 65000 0 0 0 0 0 00:00:00 Active\n<\/code><\/pre>\n<p>This is the desired Service Health behavior and reports the actual degraded service conditions.<\/p>\n<h2 style=\"color: #1a1a1a; font-weight: bold;\">Useful Validation Commands<\/h2>\n<h3 style=\"color: #1a1a1a; font-weight: bold;\">Junos <code>node-19<\/code><\/h3>\n<pre><code>show version | no-more\nshow snmp mib walk sysObjectID | no-more\nshow snmp mib walk entPhysicalDescr | no-more\nshow snmp mib walk jnxContentsDescr | no-more\nshow chassis hardware | no-more\nshow configuration interfaces et-0\/0\/3 | display set | no-more\nshow interfaces et-0\/0\/3.4003 | no-more\nshow configuration routing-instances VPN-4003 | display set | no-more\nshow route table VPN-4003.inet.0 | no-more\nshow bgp summary | no-more\nshow bgp neighbor 140.43.19.2 | no-more\nshow path-computation-client active-pce | no-more\nshow network-agent statistics gnmi brief | no-more\n<\/code><\/pre>\n<h3 style=\"color: #1a1a1a; font-weight: bold;\">IOS XR <code>node-3<\/code> and <code>node-4<\/code><\/h3>\n<pre><code>show running-config vrf VPN-4003\nshow running-config route-policy VPN-4003-ROUTE-POLICY\nshow bgp vrf VPN-4003 ipv4 unicast summary\nshow bgp neighbor brief\nshow route vrf VPN-4003 ipv4 unicast\nshow segment-routing traffic-eng policy\n<\/code><\/pre>\n<h3 style=\"color: #1a1a1a; font-weight: bold;\">SR-PCE <code>node-10<\/code><\/h3>\n<pre><code>show running-config pce\nshow pce ipv4 peer\nshow pce ipv4 peer detail\nshow pce lsp summary\nshow bgp link-state link-state summary\nshow bgp neighbor brief\n<\/code><\/pre>\n<h2 style=\"color: #1a1a1a; font-weight: bold;\">Conclusion<\/h2>\n<p>Autonomous networking and AI-assisted operations require more than automated service provisioning. They depend on a closed operational loop where inventory, topology, traffic engineering, service intent, device validation, and telemetry continuously align. When these data sources agree, automation can make safer decisions, AI systems can reason over trusted network state, and operators can focus on real service impact.<\/p>\n<p>In this lab, Cisco Crosswork Network Controller 7.2 used L3VPN to bring that loop together across IOS XR and Junos. DLM discovered the Juniper vMX with the right software metadata and capabilities, SR-PCE validated the Segment Routing underlay and PCEP state, T-SDN provisioning created the L3VPN service intent, and custom Junos Service Health extensions moved CNC from generic collection failures to actionable service symptoms.<\/p>\n<p>The most important outcome is that CNC can distinguish transport health from service-edge degradation, normalize state across vendors, and report symptoms that match device-side evidence. That is the foundation for an AI-ready operational model: trustworthy inventory, validated transport, intent-aware services, and service-health telemetry that operators and automation systems can act on.<\/p>\n<h2 style=\"color: #1a1a1a; font-weight: bold;\">References<\/h2>\n<ul>\n<li><a style=\"color: #0066cc;\" href=\"https:\/\/www.cisco.com\/c\/en\/us\/products\/cloud-systems-management\/crosswork-network-controller\/index.html\">Cisco Crosswork Network Controller<\/a><\/li>\n<li><a style=\"color: #0066cc;\" href=\"https:\/\/www.cisco.com\/c\/en\/us\/td\/docs\/iosxr\/ncs5500\/segment-routing\/77x\/b-segment-routing-cg-ncs5500-77x.html\">Cisco Segment Routing Configuration Guide for Cisco NCS 5500 Series Routers, IOS XR Release 7.7.x<\/a><\/li>\n<li><a style=\"color: #0066cc;\" href=\"https:\/\/dcloud.cisco.com\/\">Cisco dCloud<\/a> &#8211; CNC 7.2 dCloud content will be available soon.<\/li>\n<li><a style=\"color: #0066cc;\" href=\"https:\/\/github.com\/maddn\/tsdn-tme-multi-vendor\">T-SDN multivendor reference implementation<\/a><\/li>\n<li><a style=\"color: #0066cc;\" href=\"https:\/\/github.com\/sujmurth\/CNC7.2-Multivendor-Service_Health_Heuristic_Package-Junos\">CNC 7.2 Multivendor Service Health Heuristic Package for Junos<\/a><\/li>\n<\/ul>\n<div style=\"display: flex;\" title=\"\u0627\u0646\u062a\u062e\u0627\u0628 \u06a9\u0644 \u0627\u06cc\u0646 \u0628\u062e\u0634\"><\/div>\n<\/div>\n<\/div>\n<\/div>\n","protected":false},"excerpt":{"rendered":"<p>Autonomous networking depends on a closed operational loop: accurate inventory, transport visibility, intent-based service provisioning, device-side validation, and service-health telemetry that can be trusted\u2026<\/p>\n","protected":false},"author":1,"featured_media":202,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[111,106,113,69,148],"tags":[],"class_list":["post-204","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-automation-en","category-crosswork-en","category-crosswork-planning-en","category-iosxr-en-en","category-segment-routing-en"],"_links":{"self":[{"href":"https:\/\/www.anynet.ir\/blog\/wp-json\/wp\/v2\/posts\/204","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.anynet.ir\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.anynet.ir\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.anynet.ir\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.anynet.ir\/blog\/wp-json\/wp\/v2\/comments?post=204"}],"version-history":[{"count":2,"href":"https:\/\/www.anynet.ir\/blog\/wp-json\/wp\/v2\/posts\/204\/revisions"}],"predecessor-version":[{"id":208,"href":"https:\/\/www.anynet.ir\/blog\/wp-json\/wp\/v2\/posts\/204\/revisions\/208"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.anynet.ir\/blog\/wp-json\/wp\/v2\/media\/202"}],"wp:attachment":[{"href":"https:\/\/www.anynet.ir\/blog\/wp-json\/wp\/v2\/media?parent=204"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.anynet.ir\/blog\/wp-json\/wp\/v2\/categories?post=204"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.anynet.ir\/blog\/wp-json\/wp\/v2\/tags?post=204"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}