SR-TE PCE Redundancy w/ Sync

Load isis.sr.vpnv4.and.te.enabled.cfg

configure
load bootflash:isis.sr.vpnv4.and.te.enabled.cfg
commit replace
y

Configure R9 and R10 as a PCE and R1 as a PCC. On R1, R10 should be the primary PCE, and R9 should be used as backup.

R9 and R10 should sync LSPs between themselves.

On R1, configure a policy that uses color 10 and endpoint 7.7.7.1 with a dynamic path. This should be PCE-computed.

Answer

#R1
segment-routing
 traffic-eng
  policy POL1
   color 10 end-point ipv4 7.7.7.1
   candidate-paths
    preference 100
     dynamic
      pcep
  !
  pcc
   pce address ipv4 9.9.9.1
    precedence 200
   !
   pce address ipv4 10.10.10.1
    precedence 100

#R9
pce
 address ipv4 9.9.9.1
 state-sync ipv4 10.10.10.1

#R10
pce
 address ipv4 10.10.10.1
 state-sync ipv4 9.9.9.1

Explanation

Even though PCCs can keep PCEs synced themselves, you may still want to add a sync session between PCEs for an additional level of redundancy, and also to handle path disjointness.

If a PCC loses a session to one PCE, but that PCE is still up, then the PCEs will not be insync, as the PCC cannot send Reports to one of the PCEs. A sync session adds protection against this.

Additionally, if PCCs use different PCEs as primary, it’s possible to run into an issue with disjointness. Let’s say PCC1 uses PCE1 as primary, and PCC2 uses PCE2 as primary. PCC1 might request disjointness from PCE1, and then report the LSP to PCE2. Next, PCC2 requests disjointness to PCE2. But PCE2 needs to update PCC1’s path first to solve the disjointness. This is not possible since PCE2 has not been delegated control of PCC1’s LSP.

To solve this issue, the PCEs form a master/slave relationship over the sync session. The master is the PCE with the lowest session IP address. The slave will sub-delegate all disjoint path computation to the master PCE. So if the slave receives a path computation request for disjointness, the PCE forwards this to the master PCE, which does the calculation. The master PCE reports this to the slave PCE, which updates the PCC.

PCE sync is configured easily as follows:

#PCE
 state-sync ipv4 <address>

We can see on the PCEs that they are PCEP peers. They don’t have the ability to update or instantiate policies on each other. Instead they simply forward PCEP Reports to each other:

When a PCE receives a PCEP Report from a PCC, it clears the delegate flag, adds a TLV with the identity of the PCC, and forwards it to all PCEs that it is syncing with. A PCE does not forward a PCE-received PCEP Report onto other PCEs. This essentially implements iBGP behavior, so a full mesh of sync sessions is required among all PCEs.

We can test that this works by configuring a null route to R9’s loopback and then configuring a new policy on R1.

#R1
router static
 address-family ipv4 unicast
  9.9.9.1/32 Null0

commit

segment-routing
 traffic-eng
  policy POL2
   color 10 end-point ipv4 8.8.8.1
   candidate-paths
    preference 100
     dynamic
      pcep

Even though R1’s PCEP Report destined for R9 is lost, R9 still learns this policy over the sync session with R10: