Integrate SR-PCE

This chapter contains the following topics:

SR-PCE Integration Workflow

This section explains the steps in integrating Cisco SR-PCE with Crosswork Network Controller.

Please see the Release Notes for Crosswork Network Controller 7.1.0 to know the SR-PCE version compatible with Crosswork Network Controller.

1. Install the compatible version of Cisco SR-PCE

Select the type of SR-PCE (for VMware ESXi) and follow the relevant install instructions in the Cisco IOS XRv 9000 Router Installation Guide.

2. Configure SR-PCE

Follow the instructions in Configure SR-PCE.

3. Add SR-PCE provider and verify connectivity

Follow the instructions in Add Cisco SR-PCE Providers.

Configure SR-PCE

This section explains how to configure SR-PCE after you have installed it.


Note


The Cisco IOS XRv 9000 is the recommended platform to act as the SR-PCE.


Table 1. Configuring SR-PCE with gRPC enabled

Step

Command or Action

Description

1

conf t

Example:

conf t

Enters global configuration mode.

2

lslib-server

Example:

lslib-server
 !

Enables the Link State Library (LSlib) server.

3

grpc

Example:

grpc
 port 57400
 address-family ipv4
 tls profile <profile-name>
 service-layer
 !

Initiates the configuration mode for the gRPC server on the router. It's the top-level command for defining gRPC listener parameters. gRPC configuration enables a management and programmability interface for the router, which can be used to interact with various router components, including SR-PCE related data.

  • port—Specifies the TCP port number that the server will listen on for incoming client connections. Ideally gRPC server listening port is 57400, but it can be configured in the range: 57344-57999.

  • address-family— Specifies the address-family (e.g., IPv4, IPv6) for the gRPC server to listen on.

  • tls profile—Enables TLS for secure communication. For secure gRPC deployment, TLS should be enabled.

  • service-layer—Defines that the gRPC server will expose operational data models and potentially configuration capabilities.

4

linux networking

Example:

linux networking
 vrf default
  address-family ipv4
   default-route software-forwarding

Initiates the configuration mode for the Linux networking subsystem. It ensures that processes running in the Linux environment of the router (which might include the gRPC server) have their default route pointed to the IOS XR forwarding plane.

  • vrf default—Specifies that the subsequent routing configurations apply to the "default" Virtual Routing and Forwarding (VRF) instance.

  • address-family— Specifies the address-family (e.g., IPv4, IPv6) for routing.

  • default-route—Sets the default route for traffic originating from the Linux kernel to be handled by the IOS XR routing engine. If default-route mgmt is not configured, the TPA's default route implicitly points to software-forwarding, which instructs the Linux kernel to use the fwdintf (forward interface) as the next-hop for its default route.

5

pce

Example:

pce
 address ipv4 192.168.0.1
 stateful
 segment-routing
 state-sync ipv4 192.168.0.3
 distribute link-state
 tcp-buffer size 1024000
 password encrypted pwd1

Enables PCE and enters PCE configuration mode.

  • address ipv4 address—Configures a PCE IPv4 address.

  • stateful—Enables the PCE to be stateful.

  • segment-routing—Enables Segment Routing capabilities for the PCE.

  • state-sync ipv4 address—Configures the remote peer for state synchronization.

  • distribute link-state — Instructs the PCE to receive and build its topology database from the local Interior Gateway Protocol (IGP) (for example, OSPF or IS-IS).

  • tcp-buffer size size—Configures the transmit and receive TCP buffer size for each PCEP session, in bytes. The default buffer size is 256000. The valid range is from 204800 to 1024000.

  • password {clear | encrypted} password—Enables TCP MD5 authentication for all PCEP peers. Any TCP segment coming from the PCC that does not contain a MAC matching the configured password will be rejected. Specify if the password is encrypted or clear text. Password can be configured globally under pce or per-peer under peer <address>.

    Note

     

    TCP-AO and TCP MD5 are never permitted to be used simultaneously.

  • tcp-ao key-chain [include-tcp-options] [accept-ao-mismatch-connection]—Enables TCP Authentication Option (TCP-AO) authentication for all PCEP peers. Any TCP segment coming from the PCC that does not contain a MAC matching the configured key chain will be rejected. TCP-AO can be configured globally under pce or per-peer under peer <address>.

    • include-tcp-options—Includes other TCP options in the header for MAC calculation.

    • accept-ao-mismatch-connection—Accepts connection even if there is a mismatch of AO options between peers.

    Note

     

    TCP-AO and TCP MD5 are never permitted to be used simultaneously.

5

For PCEP sessions:

peer Crosswork network controller ip-address

Example:

peer ipv4 209.165.255.2
 source ipv4 209.165.255.1
 password encrypted pwd1

Specifies peer settings.

  • peer— Specifys the IP address of the Crosswork Network Controller.

  • peer source— Specifys the source address the PCE uses when connecting to that specific peer.

  • !—Exits peer mode.

6

segment-routing {strict-sid-only | te-latency}

Example:

segment-routing strict-sid-only

Configures the segment routing algorithm to use strict SID or TE latency.

Note

 

This setting is global and applies to all LSPs that request a path from this controller.

7

timers

Example:

timers
 keepalive 60
 minimum-peer-keepalive 30
 reoptimization 600
 exit

Enters timer configuration mode.

  • keepalive time—Configures the timer value for locally generated keep-alive messages. The default time is 30 seconds.

  • minimum-peer-keepalive time—Configures the minimum acceptable keep-alive timer that the remote peer may propose in the PCEP OPEN message during session establishment. The default time is 20 seconds.

  • reoptimization time—Configures the re-optimization timer. The default timer is 1800 seconds.

  • exit—Exits timer configuration mode and returns to PCE configuration mode.

8

!

Example:

!

Exits PCE mode.

9

commit

Example:

commit

Applies changes and exits the configuration.

What to do next:

Return to the installation workflow:

Sample SR-PCE configurations

The following configurations are examples to guide you in a multiple SR-PCE setup for HA. Please modify accordingly.

Sample SR-PCE configurations

Sample redundant SR-PCE configuration (on PCE with Cisco IOS-XR 7.x.x)


pce
 address ipv4 192.168.0.7
 state-sync ipv4 192.168.0.6
 api
  sibling ipv4 192.168.0.6

Sample PCE configuration for enabling gRPC API on XR 25.2.1.x (IPv4 deployment)


conf t
  lslib-server
  !
  grpc
    port 57400
    no-tls
    address-family ipv4
    service-layer
    !
!
pce
  distribute link-state
  !
!
linux networking
  vrf default
    address-family ipv4
      default-route software-forwarding
    !
    address-family ipv6
      default-route software-forwarding
    !
  !
!
commit

Note


For secure gRPC deployment, remove no-tls.

Configure distribute link-state on all PCEs to inject SR policies into BGP-LS.

.


Sample PCE configuration for enabling gRPC API on XR 25.2.1.x (IPv6 deployment)


conf t
  lslib-server
  !
  grpc
    port 57400
    no-tls
    address-family ipv6
    service-layer
    !
!
pce
  distribute link-state
  !
!
linux networking
  vrf default
    address-family ipv4
      default-route software-forwarding
    !
    address-family ipv6
      default-route software-forwarding
    !
  !
!
commit

Note


For secure gRPC deployment, remove no-tls.

Configure distribute link-state on all PCEs to inject SR policies into BGP-LS.


To verify whether the topology is published in gRPC

sh lslib server topology-db

To verify the SR-MPLS LSP published in gRPC

show lslib server topology-db detail protocol sr

Sample redundant SR-PCE configuration (PCC)

segment-routing
 traffic-eng
  pcc
   source-address ipv4 192.0.2.1
   pce address ipv4 192.0.2.6
    precedence 200
   !
   pce address ipv4 192.0.2.7
    precedence 100
   !
   report-all
   redundancy pcc-centric

Sample redundant SR-PCE configuration (on PCC) for RSVP-TE


Note


Loopback0 represents the TE router ID.



ipv4 unnumbered mpls traffic-eng Loopback0
!
mpls traffic-eng
 pce
  peer source ipv4 209.165.255.1
  peer ipv4 209.165.0.6
   precedence 200
  !
  peer ipv4 209.165.0.7
   precedence 100
  !
  stateful-client
   instantiation
   report
   redundancy pcc-centric
   autoroute-announce
  !
 !
 auto-tunnel pcc
  tunnel-id min 1000 max 1999
 !
!

Telemetry configuations

Sample SR-TM configuation

telemetry model-driven
 destination-group crosswork
  address-family ipv4 198.18.1.219 port 9010
   encoding self-describing-gpb
   protocol tcp
  !
 !
 sensor-group SRTM
  sensor-path Cisco-IOS-XR-infra-tc-oper:traffic-collector/afs/af/counters/tunnels
  sensor-path Cisco-IOS-XR-infra-tc-oper:traffic-collector/vrf-table/default-vrf/afs/af/counters/prefixes
 !
 subscription OE
  sensor-group-id SRTM sample-interval 60000
  destination-id crosswork
  source-interface Loopback0
!
traffic-collector
 interface GigabitEthernet0/0/0/3
 !
 statistics
  history-size 10

Note


The destination address uses the southbound data interface (eth1) address of the Crosswork Data Gateway VM.


It is required to push sensor path on telemetry configuration via NSO to get prefix and tunnel counters. It is assumed that the Traffic Collector has been configured with all the traffic ingress interface. This configuration is needed for demands in the Bandwidth on Demand feature pack to work.

Telemetry sensor path

sensor-path Cisco-IOS-XR-infra-tc-oper:traffic-collector/afs/af/counters/tunnels/tunnel
sensor-path Cisco-IOS-XR-infra-tc-oper:traffic-collector/vrf-table/default-vrf/afs/af/counters/prefixes/prefix
 

Telemetry configuration pushed by Crosswork Network Controller to all the headend routers via NSO

telemetry model-driven
  destination-group CW_43dc8a5ea99529715899b4f5218408a785e40fce
    vrf default
    address-family ipv4 172. 19.68.206 port 31500
      encoding self-describing-gpb
      protocol top
    !
  !
destination-group CW_4b3c69a200668b0a8dc155caff295645c684a8f8
  vrf default
  address-family ipv4 172. 19.68.206 port 31500
    encoding self-describing-gpb
    protocol top
  !
!
sensor-group CW_43dc8a5ea99529715899b4f5218408a785e40fce
  sensor-path Cisco-IOS-XR-infra-tc-oper:traffic-collector/afs/af/counters/tunnels/tunnel
!
sensor-group CW_4b3c69a200668b0a8dc155caff295645c684a8f8
  sensor-path Cisco-IOS-XR-infra-tc-oper:traffic-collector/vrf-table/default-vrf/afs/af/counters/prefixes/prefix
!
subscription CW_43dc8a5ea99529715899b4f5218408a785e40fce
  sensor-group-id CW_43dc8a5ea99529715899b4f5218408a785e40fce sample-interval 300000
  destination-id CW_43dc8a5ea99529715899b4f5218408a785e40fce
!
subscription CW_4b3c69a200668b0a8dc155caff295645c684a8f8
  sensor-group-id CW_4b3c69a200668b%a8dc155caff295645c684a8f8 sample-interval 300000
  destination-id CW_463c69a200668b0a8dc155caff295645c684a8f8
  !
!

Traffic Collector configurations

Traffic Collector configurations (all Ingress traffic interface to be added below in the Traffic Collector)

RP/0/RSP0/CPU0:PE1-ASR9k#sh running-config traffic-collector
Fri May 22 01:14:35.845 PDT
traffic-collector
  interface GigabitEthernet0/0/0/0
  !
  statistics
    history-size 1
    collection-interval 1
    history-timeout 1
    history-minute-timeout
  !  
!
Add BGP neighbor next-hop-self for all the prefix (to show TM rate counters)
bgp router-id 5.5.5.5
address-family ipv4 unicast
  network 5.5.5.5/32
  redistribute static
!
address-family link-state link-state
!
neighbor 1.1.1.1
  remote-as 65000
  update-source Loopback0
  address-family ipv4 unicast
   next-hop-self
  !
!

Traffic collector tunnel and prefix counters

RP/0/RSP0/CPU0:PE1-ASR9k#show traffic-collector ipv4 counters prefix
Fri May 22 01:13:51.458 PDT
Prefix              Label         Base rate         TM rate        State
                                  (Bytes/sec)       (Bytes/sec)
-----------------  -------------  ---------------  --------------  -----------------
1.1.1.1/32          650001         3                0              Active
2.2.2.2/32          650002         3                0              Active
3.3.3.3/32          650003         6                0              Active
4.4.4.4/32          650004         1                0              Active
6.6.6.6/32          650200         6326338          6326234        Active
7.7.7.7/32          650007         62763285         62764006       Active
8.8.8.8/32          650008         31129168         31130488       Active
9.9.9.9/32          650009         1                0              Active
10.10.10.10/32      650010         1                0              Active
RP/0/RSP0/CPU0:PE1-ASR9k#stt
RP/0/RSP0/CPU0:PE1-ASR9k#show traffic-collector ipv4 counters tunnel
Fri May 22 01:13:52.169 PDT
RP/0/RSP0/CPU0:PE1-ASR9k#]

Add Cisco SR-PCE Providers

Cisco Segment Routing Path Computation Elements (Cisco SR-PCE) providers:

  • supply device discovery, management, configuration maintenance, and route calculation services to Cisco Crosswork Network Controller components

  • enable system access as part of SDN controllers in the management domain, and

  • support multi-AS topology and path calculations.

Multi-AS topology and path calculations are supported if the complete topology is accessible to both the Crosswork Network Controller and each PCE. A single PCE cannot view a specific AS topology while another PCE views a different topology. Each PCE must have access to the entire topology view. To learn and discover SR policies, Layer 3 links, and devices, at least one SR-PCE provider is required. Additionally, a second SR-PCE can be configured as a backup.

Follow the steps below to add one or more instances of Cisco SR-PCE as providers.

Before you begin

Ensure these requirements are met prior to adding an SR-PCE provider:
  • Configure a device to act as the SR-PCE. See SR configuration documentation for your specific device platform to enable SR (for IS-IS or OSPF protocols) and configure an SR-PCE (for example: Segment Routing Configuration Guide for Cisco NCS 540 Series Routers).


    Note


    SR-PCE is not supported on the ASR 9000 hardware platform.


  • Create a credential profile for the Cisco SR-PCE provider with these connection types. See Create credential profiles in the Cisco Crosswork Network Controller Administration Guide for more details:

    • gRPC—Required to discover topology, SR-MPLS, and SRv6 policies. See Sample PCE configuration for enabling gRPC API on XR for configuration examples.

    • Basic HTTP text-authentication— Required to process for RSVP, TreeSID and PCEP sessions. MD5 authentication is currently not supported.

      If the Cisco SR-PCE server you are adding does not require authentication, you must still supply a credential profile for the provider. The credential profile can be any profile that does not use the HTTP protocol.

  • If you plan to set up gRPC with Transport Layer Security (TLS), a certificate must be generated and added with the Secure gRPC communication role. The certificate is used to secure communication through TLS between gRPC clients and the EMS server. The client should use ems.pem and ca.cert to initiate the TLS authentication. To update the certificate, ensure to copy the new certificate that has been generated earlier to the location and restart the server. See Manage Certificates in the Cisco Crosswork Network Controller Administration Guide for more details.

  • For high availability, ensure that you set up two separate Cisco SR-PCE providers with unique names and IP addresses, but with matching configurations.

  • Know the name you want to assign to the Cisco SR-PCE provider. This is usually the DNS hostname of the Cisco SR-PCE server.

  • Know the Cisco SR-PCE server IP address.

  • Know the interface you want to use to communicate between Cisco SR-PCE and the Cisco Crosswork application server.

  • Know the SSH credentials for the PCE device to enable gRPC communication. Note that PCE API credentials are used exclusively for HTTP-based communication.

  • Determine whether you want to auto-onboard the devices that Cisco SR-PCE discovers and, if so, whether you want the new devices to have their management status set to off, managed or unmanaged when added.

  • If you plan to auto-onboard devices that the Cisco SR-PCE provider discovers, and set them to a managed state when they are added to the database:

    • Assign an existing credential profile for communication with the new managed devices.

    • The credential profile must be configured with an SNMP protocol.

Procedure


Step 1

From the main menu, choose Administration > Manage Provider Access > Add icon .

Step 2

Enter the following values for the SR-PCE provider fields:

  1. Required fields:

    • Provider Name: Name of the SR-PCE provider.

    • Credential Profile: Select the previously created Cisco SR-PCE credential profile.

    • Family: Select SR_PCE. All other options should be ignored.

    • Protocol:

      • Select HTTP and enter required fields. HTTP is required to process RSVP, TreeSID and PCEP sessions. The default port is 8080.

      • Select GRPC or GRPC_SECURE (gRPC with Transport Layer Security (TLS)) and enter required fields. These settings are required to process topology, SR-MPLS, and SRv6 policies. Only one of these options can be used. If GRPC_SECURE is selected, you must provide the trusted certificate in the Certificate profile field

    • Provider Properties: Enter property keys and values:

      Property Key

      Value

      auto-onboard

      off

      Note

       
      Use this option if you plan to manually (via UI or CSV import) enter all of your network devices.

      When devices are discovered, the device data is recorded in the Cisco SR-PCE database, but is not registered in Crosswork Network Controller Inventory Management database.

      unmanaged

      If this option is enabled, all devices that Crosswork Network Controller discovers will be registered in the Crosswork Network Controller Inventory Management database, with their configured state set to unmanaged. SNMP polling will be disabled for these devices, and no management IP information will be included. To get these devices into the managed state later, you will need to either edit them via the UI or export them to a CSV make modifications and then import the updated CSV. You can also assign credential profiles by adding them to the device CSV file before import (the credential profiles must already exist).

      managed

      If this option is enabled, all devices that Cisco SR-PCE discovers will be registered in the Crosswork Network Controller Inventory Management database, with their configured state set to managed.

      Typically suitable for an environment that has same device profiles, devices are managed by their TE router-ID, and all devices can be discovered by the Cisco SR-PCE.

      SNMP polling will be enabled for these devices, and Cisco SR-PCE will also report the management IP address (TE Router ID for IPv4, or IPv6 Router ID for IPv6 deployment). The devices will be added with the credential profile associated with the device-profile key in the SR-PCE provider configuration.

      If you enable this option for IPv6 deployment, devices will still register as unmanaged in the inventory.

      When you delete an onboarded device that was added via SR-PCE discovery with auto-onboard set to managed, the topology service adds it again as unmanaged. This ensures that devices that have been removed are not automatically managed again unless they acquire a new TE-ID. To manage a rediscovered device, update its status manually.

      device-profile

      The name of a credential profile that contains SNMP credentials for all the new devices.

      Note

       

      This field is necessary only if auto-onboard is set to managed or unmanaged.

      If the auto-onboard is set to managed and there is no valid device-profile set, the device will instead be onboarded as unmanaged.

      outgoing-interface

      eth1

      Note

       

      You have to set this only if you want to enable Cisco Crosswork application access to SR-PCE via the data network interface when using the two NIC configuration.

      preferred-stack

      ipv4 or ipv6 or NOT SET.

      This property is applicable only for dual stack deployments.

      topology

      off or on.

      This is an optional property. If not specified, the default value is on.

      If value is specified as off, it means that L3 topology is not accessible for the SR-PCE provider.

      pce

      off or on.

      This is an optional property. If not specified, the default value is on.

      If value is specified as off, it means that LSPs and policies are not accessible for the SR-PCE provider.

      Note

       

      Topology can be visualized even with auto-onboard as off and a device-profile is not specified.

      If managed or unmanaged options are set and you want to delete a device later, you must either:.

      • Reconfigure and remove the devices from the network before deleting the device from Crosswork Network Controller. This avoids Crosswork Network Controller from rediscovering and adding the device back.

      • Set auto-onboard to off, and then delete the device from Crosswork Network Controller. However, doing so will not allow Crosswork Network Controller to detect or auto-onboard any new devices in the network.

      It is not recommended to modify auto-onboard options once set. If you need to modify them:

      1. Delete the provider and wait until deletion confirmation is displayed in the Events window.

      2. Re-add the provider with the updated auto-onboard option.

      3. Confirm the provider has been added with the correct auto-onboard option in the Events window.

  2. Optional values:

    • Timeout: The amount of time (in seconds) to wait before timing out the connection to the SR-PCE server. The default is 30 seconds.

Step 3

Click Save to add the SR-PCE provider.

Step 4

Confirm that the SR-PCE provider shows a green Reachability status without any errors. You can also view the Events window (Administration > Events) to see if the provider has been configured correctly.

Step 5

Repeat this process for each SR-PCE provider.


What to do next

  • If auto-onboard is set to off, navigate to Device Management > Network Devices to onboard devices.

  • If you opted to automatically onboard devices, navigate to Device Management > Network Devices to view the device list. To add more node information such as geographical location details, export the device list (.csv), update it, and import it back. If geographical location data is missing, you will only be able to see device topology using the logical map.

Return to the installation workflow: