4. IS-IS

This chapter provides information to configure Intermediate System to Intermediate System (IS-IS).

4.1. Configuring IS-IS

Intermediate-system-to-intermediate-system (IS-IS) is a link-state interior gateway protocol (IGP) which uses the Shortest Path First (SPF) algorithm to determine routes. Routing decisions are made using the link-state information. IS-IS evaluates topology changes and, if necessary, performs SPF recalculations.

Entities within IS-IS include networks, intermediate systems, and end systems. In IS-IS, a network is an autonomous system (AS), or routing domain, with end systems and intermediate systems. A router is an intermediate system. End systems are network devices which send and receive protocol data units (PDUs), the OSI term for packets. Intermediate systems send, receive, and forward PDUs.

End system and intermediate system protocols allow routers and nodes to identify each other. IS-IS sends out link-state updates periodically throughout the network, so each router can maintain current network topology information.

IS-IS supports large ASs by using a two-level hierarchy. A large AS can be administratively divided into smaller, more manageable areas. A system logically belongs to one area. Level 1 routing is performed within an area. Level 2 routing is performed between areas. Routers can be configured as Level 1, Level 2, or both Level 1/2.

Figure 11 shows an example of an IS-IS routing domain.

Figure 11:  IS-IS Routing Domain 

4.1.1. Routing

OSI IS-IS routing uses two-level hierarchical routing. A routing domain can be partitioned into areas. Level 1 routers know the topology in their area, including all routers and end systems in their area but do not know the identity of routers or destinations outside of their area. Level 1 routers forward traffic with destinations outside of their area to a Level 2 router in their area.

Level 2 routers know the Level 2 topology, and know which addresses are reachable by each Level 2 router. Level 2 routers do not need to know the topology within any Level 1 area, except to the extent that a Level 2 router can also be a Level 1 router within a single area. By default, only Level 2 routers can exchange PDUs or routing information directly with external routers located outside the routing domain.

In IS-IS, there are the following types of routers:

  1. Level 1 intermediate systems
    Routing is performed based on the area ID portion of the ISO address called the network entity title (NET). Level 1 systems route within an area. They recognize, based on the destination address, whether the destination is within the area. If so, they route toward the destination. If not, they route to the nearest Level 2 router.
  2. Level 2 intermediate systems
    Routing is performed based on the area address. They route toward other areas, disregarding other area’s internal structure. A Level 2 intermediate system can also be configured as a Level 1 intermediate system in the same area.

The Level 1 router’s area address portion is manually configured (see ISO Network Addressing). A Level 1 router will not become a neighbor with a node that does not have a common area address. However, if a Level 1 router has area addresses A, B, and C, and a neighbor has area addresses B and D, then the Level 1 router will accept the other node as a neighbor, as address B is common to both routers. Level 2 adjacencies are formed with other Level 2 nodes whose area addresses do not overlap. If the area addresses do not overlap, the link is considered by both routers to be Level 2 only and only Level 2 LSPDUs flow on the link.

Within an area, Level 1 routers exchange LSPs which identify the IP addresses reachable by each router. Specifically, zero or more IP address, subnet mask, and metric combinations can be included in each LSP. Each Level 1 router is manually configured with the IP address, subnet mask, and metric combinations, which are reachable on each interface. A Level 1 router routes as follows:

  1. If a specified destination address matches an IP address, subnet mask, or metric reachable within the area, the PDU is routed via Level 1 routing.
  2. If a specified destination address does not match any IP address, subnet mask, or metric combinations listed as reachable within the area, the PDU is routed toward the nearest Level 2 router.

Level 2 routers include in their LSPs, a complete list of IP address, subnet mask, and metrics specifying all the IP addresses which reachable in their area. This information can be obtained from a combination of the Level 1 LSPs (by Level 1 routers in the same area). Level 2 routers can also report external reachable information, corresponding to addresses reachable by routers in other routing domains or autonomous systems.

4.1.2. IS-IS Frequently Used Terms

  1. Area — An area is a routing sub-domain which maintains detailed routing information about its own internal composition, and also maintains routing information which allows it to reach other routing sub-domains. Areas correspond to the Level 1 sub-domain.
  2. End system — End systems send NPDUs to other systems and receive NPDUs from other systems, but do not relay NPDUs. This International Standard does not specify any additional end system functions beyond those supplied by ISO 8473 and ISO 9542.
  3. Neighbor — A neighbor is an adjacent system reachable by traversing a single sub-network by a PDU.
  4. Adjacency — An adjacency is a portion of the local routing information which pertains to the reachability of a single neighboring end or intermediate system over a single circuit. Adjacencies are used as input to the decision process to form paths through the routing domain. A separate adjacency is created for each neighbor on a circuit and for each level of routing (Level 1 and Level 2) on a broadcast circuit.
  5. Circuit — The subset of the local routing information base pertinent to a single local Subnetwork Point of Attachments (SNPAs).
  6. Link — The communication path between two neighbors. A link is up when communication is possible between the two SNPAs.
  7. Designated IS — The intermediate system on a LAN which is designated to perform additional duties. In particular, the designated IS generates link-state PDUs on behalf of the LAN, treating the LAN as a pseudonode.
  8. Pseudonode — Where a broadcast sub-network has n connected intermediate systems, the broadcast sub-network is considered to be a pseudonode. The pseudonode has links to each of the n intermediate systems and each of the ISs has a single link to the pseudonode (rather than n-1 links to each of the other intermediate systems). Link-state PDUs are generated on behalf of the pseudonode by the designated IS.
  9. Broadcast sub-network — A multi-access subnetwork that supports the capability of addressing a group of attached systems with a single PDU.
  10. General topology sub-network — A topology that is modeled as a set of point-to-point links, each of which connects two systems. There are several generic types of general topology subnetworks, multipoint links, permanent point-to-point links, dynamic and static point-to-point links.
  11. Routing sub-domain — A routing sub-domain consists of a set of intermediate systems and end systems located within the same routing domain.
  12. Level 2 sub-domain — Level 2 sub-domain is the set of all Level 2 intermediate systems in a routing domain.

4.1.3. ISO Network Addressing

IS-IS uses ISO network addresses. Each address identifies a point of connection to the network, such as a router interface, and is called a Network Service Access Point (NSAP).

An end system can have multiple NSAP addresses, in which case the addresses differ only by the last byte (called the n-selector). Each NSAP represents a service that is available at that node. In addition to having multiple services, a single node can belong to multiple areas.

Each network entity has a special network address called a Network Entity Title (NET). Structurally, an NET is identical to an NSAP address but has an n-selector of 00. Most end systems have one NET. Intermediate systems can have up to three area IDs (area addresses).

NSAP addresses are divided into three parts. Only the area ID portion is configurable.

  1. Area ID — A variable length field between 1 and 13 bytes. This includes the Authority and Format Identifier (AFI) as the most significant byte and the area ID.
  2. System ID — A six-byte system identification. This value is not configurable. The system ID is derived from the system or router ID.
  3. Selector ID — A one-byte selector identification that must contain zeros when configuring a NET. This value is not configurable. The selector ID is always 00.

Of the total 20 bytes comprising the NET, only the first 13 bytes, the area ID portion, can be manually configured. As few as one byte can be entered or, at most, 13 bytes. If less than 13 bytes are entered, the rest is padded with zeros.

Routers with common area addresses form Level 1 adjacencies. Routers with no common NET addresses form Level 2 adjacencies, if they are capable (Figure 12).

Figure 12:  Using Area Addresses to Form Adjacencies 

4.1.4. IS-IS PDU Configuration

The following PDUs are used by IS-IS to exchange protocol information:

  1. IS-IS hello PDU — Routers with IS-IS enabled send hello PDUs to IS-IS-enabled interfaces to discover neighbors and establish adjacencies.
  2. Link-state PDUs — Contain information about the state of adjacencies to neighboring IS-IS systems. LSPs are flooded periodically throughout an area.
  3. Complete sequence number PDUs — In order for all routers to maintain the same information, CSNPs inform other routers that some LSPs can be outdated or missing from their database. CSNPs contain a complete list of all LSPs in the current IS-IS database.
  4. Partial sequence number PDUs (PSNPs) — PSNPs are used to request missing LSPs and acknowledge that an LSP was received.

4.1.5. IS-IS Operations

Routers perform IS-IS routing as follows:

  1. Hello PDUs are sent to the IS-IS-enabled interfaces to discover neighbors and establish adjacencies.
  2. IS-IS neighbor relationships are formed if the hello PDUs contain information that meets the criteria for forming an adjacency.
  3. Routers can build a link-state PDU based upon their local interfaces that are configured for IS-IS and prefixes learned from other adjacent routers.
  4. Routers flood LSPs to the adjacent neighbors except the neighbor from which they received the same LSP. The link-state database is constructed from these LSPs.
  5. A Shortest Path Tree (SPT) is calculated by each IS, and from this SPT the routing table is built.

4.1.6. IS-IS Route Summarization

IS-IS IPv4 route summarization allows users to create aggregate IPv4 addresses that include multiple groups of IPv4 addresses for a specific IS-IS level. IPv4 Routes redistributed from other routing protocols also can be summarized. It is similar to the OSPF area-range command. IS-IS IPv4 route summarization helps to reduce the size of the LSDB and the IPv4 routing table, and it also helps to reduce the chance of route flapping.

IPv4 route summarization supports:

  1. Level 1, Level 1-2, and Level 2
  2. Route summarization for the IPv4 routes redistributed from other protocols
  3. Metric used to advertise the summary address will be the smallest metric of all the more specific IPv4 routes.

4.1.7. IS-IS Multi-Topology for IPv6

IS-IS IPv6 Type-Length-Value (TLV) encoding for IPv6 routing is supported in 7210 SAS. This type of routing is considered native IPv6 routing with IS-IS. It has a limitation that IPv4 and IPv6 topologies must be congruent, otherwise traffic may be black holed. Service providers should ensure that the IPv4 topology and IPv6 topology are the same. With IS-IS multi-topology, service providers can use different topologies for IPv4 and IPv6.

The implementation is compliant with draft-ietf-isis-wg-multi-topology-xx.txt, M-ISIS: Multi Topology (MT) Routing in IS-IS.

The following MT topologies are supported:

  1. MT ID #0: equivalent to the standard IS-IS topology
  2. MT ID #2: reserved for IPv6 routing topology

4.1.8. IS-IS Administrative Tags

IS-IS admin tags enable a network administrator to configure route tags to tag IS-IS route prefixes. These tags can subsequently be used to control Intermediate System-to-Intermediate System (IS-IS) route redistribution or route leaking.

The IS-IS support for route tags allows the tagging of IP addresses of an interface and use the tag to apply administrative policy with a route map. A network administrator can also tag a summary route and then use a route policy to match the tag and set one or more attributes for the route.

Using these administrative policies allow the operator to control how a router handles the routes it receives from and sends to its IS-IS neighboring routers. Administrative policies are also used to govern the installation of routes in the routing table.

Route tags allow:

  1. Policies to redistribute routes received from other protocols in the routing table to IS-IS.
  2. Policies to redistribute routes between levels in an IS-IS routing hierarchy.
  3. Policies to summarize routes redistributed into IS-IS or within IS-IS by creating aggregate (summary) addresses.

4.1.8.1. Setting Route Tags

IS-IS route tags are configurable in the following ways:

  1. Setting a route tag for an IS-IS interface.
  2. Setting a route tag on an IS-IS passive interface.
  3. Setting a route tag for a route redistributed from another protocol to IS-IS.
  4. Setting a route tag for a route redistributed from one IS-IS level to another IS-IS level.
  5. Setting a route tag for an IS-IS default route.
  6. Setting a route tag for an IS-IS summary address.

4.1.8.2. Using Route Tags

The IS-IS administrative tags configured on an IS-IS router (or neighbor) will not have any effect until policies are configured to process the specified tag value.

Policies can process route tags that specify ISIS as either the origin or destination protocol, or as both origin and destination protocol.

config>router>policy-options>policy-statement>entry>from
     config>router>policy-options>policy-statement>entry>action tag tag-value
     config>router>policy-options>policy-statement# default-action tag tag-value

4.1.9. Segment Routing in Shortest Path Forwarding

Segment routing (SR) adds to IS-IS and OSPF routing protocols the ability to perform shortest path routing and source routing using the concept of abstract segment. A segment can represent a local prefix of a node, a specific adjacency of the node (interface or next-hop), a service context, or a specific path over the network. For each segment, the IGP advertises an identifier referred to as a segment ID (SID).

When SR is used in combination with the MPLS data plane, the SID acts as a standard MPLS label. A router forwarding a packet using SR therefore pushes one or more MPLS labels. This section describes the SR MPLS feature.

Both shortest path routing and traffic engineering applications can leverage SR MPLS, which encodes a segment as an MPLS label. This section describes the shortest path forwarding applications.

When a received IPv4 prefix SID is resolved, the SR module programs the ILM with a swap operation and the LTN with a push operation, both pointing to the primary/LFA NHLFE. An IPv4 SR tunnel to the prefix destination is also added to the TTM and is available for use by L2 and L3 services.

The SR tunnel in the TTM is available in the following contexts:

  1. IPv4 BGP route label
  2. VLL, LDP VPLS, and RVPLS
  3. BGP-AD VPLS when the use-provisioned-sdp option is enabled in the binding to the PW template
  4. intra-AS BGP VPRN for VPN-IPv4 and VPN-IPv6 prefixes, both auto-bind and explicit SDP

The remote LFA feature included in SR expands the coverage of the LFA by computing and automatically programming the SR tunnels that are used as backup next-hops. The SR shortcut tunnels terminate on a remote alternate node, which provides loop-free forwarding for packets of the resolved prefixes. When the loopfree-alternate option is enabled in an IS-IS or OSPF instance, SR tunnels are protected with an LFA backup next-hop. If the prefix of a specific SR tunnel is not protected by the base LFA, the remote LFA automatically computes a backup next-hop using an SR tunnel if the remote-lfa option is also enabled in the IGP instance.

4.1.9.1. Segment Routing Operational Procedures

4.1.9.1.1. Prefix Advertisement and Resolution

When segment routing is enabled in the IS-IS or OSPF instance, the router performs the following operations. See Control Protocol Changes for detailed information about the TLVs and sub-TLVs for both IS-IS and OSPF protocols.

  1. Advertises the segment routing capability sub-TLV to routers in all areas or levels of this IGP instance. However, only neighbors with which it established an adjacency interprets the SID or label range information and use it for calculating the label to swap to or push for a resolved prefix SID.
  2. Advertises the assigned index for each configured node SID in the new prefix SID sub-TLV with the N-flag (node-SID flag) set. The segment routing module programs the incoming label map (ILM) with a pop operation for each local node SID in the data path.
  3. Automatically assigns and advertises an adjacency SID label for each formed adjacency over a network IP interface in the new adjacency SID sub-TLV. The following points should be considered.
    1. The adjacency SID is advertised for both numbered and unnumbered network IP interfaces.
    2. The adjacency SID for parallel adjacencies between two IGP neighbors is not supported.
    3. The adjacency SID is not advertised for an IES interface because access interfaces do not support MPLS.
    4. The adjacency SID must be unique for each instance and for each adjacency. Also, ISIS MT=0 can establish an adjacency for the IPv4 address family over the same link, and in such a case a different adjacency SID is assigned to each next-hop. However, the existing IS-IS implementation assigns a single protect-group ID (PG-ID) to the adjacency, and when the state machine of a BFD session tracking the IPv4 next-hop times out, an action is triggered for the prefixes of the IPv4 address family over that adjacency.
    5. The segment routing module programs the ILM with a swap to an implicit null label operation for each advertised adjacency SID.
  4. Resolve received prefixes and, if a prefix SID sub-TLV exists, the segment routing module programs the ILM with a swap operation and an LTN with a push operation, both pointing to the primary/LFA NHLFE. An SR tunnel is also added to the TTM. If a node SID resolves over an IES interface, the data path is not programmed and a trap is raised. Therefore, only next-hops of an ECMP set corresponding to network IP interfaces are programmed in the data path; next-hops corresponding to IES interfaces are not programmed. If, however, the user configures the interface as a network on one side and IES on the other side, MPLS packets for the SR tunnel received on the access side are dropped.
Note:

LSA filtering causes SIDs not to be sent in one direction, which means that some node SIDs are resolved in parts of the network upstream of the advertisement suppression.

When the user enables segment routing in an IGP instance, the main SPF and LFA SPF are computed normally and the primary next-hop and LFA backup next-hop for a received prefix are added to RTM without the label information advertised in the prefix SID sub-TLV. In all cases, the segment routing tunnel is not added into the RTM.

4.1.9.1.2. Error and Resource Exhaustion Handling

When the prefix corresponding to a node SID is being resolved, the following procedures are followed.

4.1.9.1.2.1. Procedure 1: Resolving received SID indexes or labels to different routes of the same prefix within the same IGP instance

Two variations of this procedure can occur.

  1. When the 7210 SAS does not allow assigning the same SID index or label to different routes of the same prefix within the same IGP instance, it resolves only one of them if they are received from another SR implementation and they are based on the RTM active route selection.
  2. When the 7210 SAS does not allow assigning different SID indexes or labels to different routes of the same prefix within the same IGP instance, it resolves only one of them if they are received from another SR implementation and they are based on the RTM active route selection.
    The selected SID is used for ECMP resolution to all neighbors. If the route is inter-area and the conflicting SIDs are advertised by different ABRs, ECMP towards all ABRs uses the selected SID.

4.1.9.1.2.2. Procedure 2: Checking for SID error prior to programming ILM and NHLFE

If any of the following conditions are true, the router logs a trap and generates a syslog error message, and it does not program the ILM and NHLFE for the prefix SID.

  1. The received prefix SID index falls outside the locally configured SID range.
  2. One or more resolved ECMP next-hops for a received prefix SID did not advertise SR capability sub-TLV.
  3. The received prefix SID index falls outside the advertised SID range of one or more resolved ECMP next-hops.

4.1.9.1.2.3. Procedure 3: Programming ILM/NHLFE for duplicate prefix-SID indexes/labels for different prefixes

Two variations of this procedure can occur.

  1. For received duplicate prefix-SID indexes or labels for different prefixes within the same IGP instance, the router does the following:
    1. programs ILM/NHLFE for the first prefix
    2. logs a trap and a syslog error message
    3. does not program the subsequent prefix in the data path
  2. For received duplicate prefix-SID indexes for different prefixes across IGP instances, there are two options.
    1. In the global SID index range mode of operation, the resulting ILM label values are the same across the IGP instances. The router does the following:
      1. programs ILM/NHLFE for the prefix of the winning IGP instance based on the RTM route type preference
      1. logs a trap and a syslog error message
      1. does not program the subsequent prefix SIDs in the data path
    2. In the per-instance SID index range mode of operation, the resulting ILM label will have different values across the IGP instances. The router programs ILM/NHLFE for each prefix as expected.

4.1.9.1.2.4. Procedure 4: Programming ILM/NHLFE for the same prefix across IGP instances

In the global SID index range mode of operation, the resulting ILM label values are the same across the IGP instances. The router programs ILM/NHLFE for the prefix of the winning IGP instance based on the RTM route type preference. The router logs a trap and a syslog error message, and does not program the other prefix SIDs in data path.

In the per-instance SID index range mode of operation, the resulting ILM label has different values across the IGP instances. The router programs ILM/NHLFE for each prefix as expected.

Figure 13 shows an IS-IS example of the behavior in the case of a global SID index range.

Figure 13:  Handling of the Same Prefix and SID in Different IS-IS Instances 

Assume that the following route type preference in the RTM and tunnel type preference in the TTM are configured:

  1. ROUTE_PREF_ISIS_L1_INTER (RTM) 15
  2. ROUTE_PREF_ISIS_L2_INTER (RTM) 18
  3. ROUTE_PREF_ISIS_TTM 11
Note:

The TTM tunnel type preference is not used by the SR module. It is put in the TTM and is used by other applications, such a VPRN auto-bind, to select a TTM tunnel.

  1. Router A performs the following resolution within the single IS-IS instance 1, level 2. All metrics are the same, and ECMP = 2.
    1. For prefix N, the RTM entry is the following:
      1. prefix N
      2. nhop1 = B
      3. nhop2 = C
      4. preference 18
    2. For prefix N, the SR tunnel TTM entry is the following:
      1. tunnel-id 1: prefix N-SIDx
      2. nhop1 = B
      3. nhop2 = C
      4. tunl-pref 11 (tunl-pref 10 for OSPF)
  2. Add IS-IS instance 2 (level 1) in the same setup, but in routers A, B, and E only.
    1. For prefix N, the RTM entry is the following:
      1. prefix N
      2. nhop1 = B
      3. preference 15
      RTM prefers the level 1 route over the level 2 route.
    2. For prefix N, there is one SR tunnel entry for level 2 in the TTM:
      1. tunnel-id 1: prefix N-SIDx
      2. nhop1 = B
      3. nhop2 = C
      4. tunl-pref 11 (tunl-pref 10 for OSPF)

4.1.9.1.2.5. Procedure 5: Handling ILM resource exhaustion while assigning an SID index/label

If the system exhausts an ILM resource while assigning an SID index or label to a local loopback interface, index allocation fails and an error is returned in the CLI. In addition, the router logs a trap and generates a syslog error message.

4.1.9.1.2.6. Procedure 6: Handling ILM/NHLFE/other IOM or CPM resource exhaustion while resolving or programming an SID index/label

If the system exhausts an ILM, NHLFE, or any other IOM or CPM resource while resolving and programming a received prefix SID or programming a local adjacency SID, the following occurs.

  1. The IGP instance goes into overload and a trap and syslog error message are generated.
  2. The segment routing module deletes the tunnel.

The user must manually clear the IGP overload condition after freeing resources. After the IGP is brought back up, it attempts to program at the next SPF all tunnels which previously failed the programming operation.

4.1.9.2. Segment Routing Tunnel Management

The segment routing module adds to the TTM a shortest path SR tunnel entry for each resolved remote node SID prefix and programs the data path with the corresponding LTN with the push operation pointing to the primary and LFA backup NHLFEs. The LFA backup next-hop for a prefix that was advertised with a node SID will be computed only if the loopfree-alternate option is enabled in the IS-IS or OSPF instance. The resulting SR tunnel that is populated in the TTM is automatically protected with FRR when an LFA backup next-hop exists for the prefix of the node SID.

With ECMP, a maximum number of primary next-hops (NHLFEs) are programmed for the same tunnel destination per IGP instance. ECMP and LFA next-hops are mutually exclusive as per the existing implementation.

The default preference for shortest path SR tunnels in the TTM is set lower than LDP tunnels but higher than BGP tunnels to allow controlled migration of customers without disrupting their current deployment when they enable segment routing. The following list presents the default preference of the various tunnel types. This includes the preference of both SR tunnels based on shortest path (referred to as SR-ISIS and SR-OSPF).

The global default TTM preference for the tunnel types is as follows:

  1. ROUTE_PREF_RSVP 7
  2. ROUTE_PREF_SR_TE 8
  3. ROUTE_PREF_LDP 9
  4. ROUTE_PREF_OSPF_TTM 10
  5. ROUTE_PREF_ISIS_TTM 11
  6. ROUTE_PREF_BGP_TTM 12
  7. ROUTE_PREF_GRE 255

The default value for SR-ISIS or SR-OSPF is the same regardless of whether one or more IS-IS or OSPF instances are programming a tunnel for the same prefix. The selection of an SR tunnel in this case is based on the lowest IGP instance.

The TTM preference is used in the case of VPRN auto-bind or BGP transport tunnels when the tunnel binding commands are configured to the any value, which parses the TTM for tunnels in the protocol preference order. The user can choose to either use the global TTM preference or list explicitly the tunnel types to be used. When the tunnel types are listed, the TTM preference is still used to select one type over the other. In both cases, a fallback to the next preferred tunnel type is performed if the selected one fails. Also, a reversion to a preferred tunnel type is performed as soon as one is available. See BGP Label Route Resolution Using Segment Routing Tunnels and Service Packet Forwarding with Segment Routing for the detailed service and shortcut binding CLI.

For SR-ISIS and SR-OSPF, the user can configure the preference of each IGP instance in addition to the preceding default values.

CLI Syntax:
configure>router>isis>segment-routing>tunnel-table-pref preference <1..255>
configure>router>ospf>segment-routing>tunnel-table-pref preference <1..255>

SR tunnels in the TTM are available to BPG routes, VPRN auto-bind and explicit SDP binding, and L2 services with PW template auto-bind and explicit SDP binding.

Local adjacency SIDs are not programmed into the TTM, but the remote adjacency SIDs can be used together with a node SID in a tunnel configuration in a directed LFA.

4.1.9.2.1. Tunnel MTU Determination

The MTU of an SR tunnel populated into the TTM is determined the same way as it is for an IGP tunnel; for example, LDP LSP, based on the outgoing interface MTU minus the label stack size. Segment routing, however, supports remote LFA, which programs an LFA backup next-hop adding another label to the tunnel for a total of two labels.

The user must configure the MTU of all SR tunnels within each IGP instance:

CLI Syntax:
configure>router>isis>segment-routing>tunnel-mtu bytes
configure>router>ospf>segment-routing>tunnel-mtu bytes

There is no default value for this new command. If the user does not configure an SR tunnel MTU, the MTU is fully determined by IGP.

The MTU of the SR tunnel, in bytes, is determined as follows:

SR_Tunnel_MTU = MIN {Cfg_SR_MTU, IGP_Tunnel_MTU- (1+ frr-overhead)*4}

Where:

  1. Cfg_SR_MTU is the MTU configured by the user for all SR tunnels within a specific IGP instance using the preceding commands. If no value was configured by the user, the SR tunnel MTU is determined by the IGP interface calculation.
  2. IGP_Tunnel_MTU is the minimum of the IS-IS or OSPF interface MTU among all the ECMP paths or among the primary and LFA backup paths of this SR tunnel.
  3. frr-overhead is set to 1 if segment-routing and remote-lfa options are enabled in the IGP instance. Otherwise, it is set to 0.

The SR tunnel MTU is dynamically updated whenever any of the preceding parameters changes. This includes when the set of the tunnel next-hops changes, or the user changes the configured SR MTU or interface MTU value.

Note:

For the purpose of fragmentation of IP packets forwarded in GRT or in a VPRN over an SR shortest path tunnel, the IOM always deducts the worst case MTU (5 labels or 6 labels if the hash label feature is enabled) from the outgoing interface MTU for the decision to fragment the packet or not. In this case, the preceding formula is not used.

4.1.9.3. Remote LFA with Segment Routing

The remote LFA next-hop calculation by the IGP LFA SPF is enabled by appending the remote-lfa option to the loopfree-alternate command:

CLI Syntax:
configure>router>isis>loopfree-alternate remote-lfa
configure>router>ospf>loopfree-alternate remote-lfa

The SPF calculates the remote LFA after the regular LFA next-hop calculation when the following conditions are met.

  1. The remote-lfa option is enabled in an IGP instance.
  2. The LFA next-hop calculation did not result in protection for one or more prefixes resolved to a specific interface.

Remote LFA extends the loop-free alternate fast reroute (LFA FRR) protection coverage to any topology by automatically computing and establishing or tearing down shortcut tunnels (repair tunnels) to a remote LFA node that puts the packets back on the shortest path without looping them back to the node that forwarded them over the repair tunnel. A repair tunnel can be an RSVP LSP, an LDP-in-LDP tunnel, or an SR tunnel. This feature is restricted to using an SR repair tunnel to the remote LFA node.

Note:

The remote LFA feature can only use an SR repair tunnel to the remote LFA node.

The remote LFA algorithm for link protection is described in RFC 7490, Remote Loop-Free Alternate (LFA) Fast Reroute (FRR). Unlike the regular LFA calculation, which is calculated per prefix, the LFA algorithm for link protection is a per-link LFA SPF calculation. It provides protection for all destination prefixes that share the protected link by using the neighbor on the other side of the protected link as a proxy for all destinations. Figure 14 shows an example of a remote LFA topology.

Figure 14:  Example Topology Remote LFA Algorithm 

When the LFA SPF in node C computes the per-prefix LFA next-hop, prefixes that use link C to B as the primary next-hop have no LFA next-hop because of the ring topology. If node C uses node link C to D as a back-up next-hop, node D loops a packet back to node C. The remote LFA then runs the “PQ Algorithm” as described in RFC 7490.

  1. Computes the extended P space of node C for link C to B. The extended P space is the set of nodes reachable from node C without any path transiting the protected link (C to B). The computation yields nodes D, E, and F.
    The extended P space of node C is determined by running SPF on behalf of each of the neighbors of C; the same computation is used for the regular LFA.
    Note:

    According to the P space concept initially introduced in RFC 7490, node F would be excluded from the P space because, from the node C perspective, a few node C has a couple of ECMP paths would already exist in node C, including a path going through link C to B. However, because the remote LFA next-hop is activated when link C-B fails, this rule can be relaxed to include node F, which then yields the extended P space.

    You can limit the search for candidate P nodes to reduce the number of SPF calculations in topologies where many eligible P nodes may exist. Use the following CLI commands to configure the maximum IGP cost from node C for a P node to be an eligible candidate:
    1. configure>router>isis>loopfree-alternate remote-lfa max-pq-cost value
    2. configure>router>ospf>loopfree-alternate remote-lfa max-pq-cost value
  2. Compute the Q space of node B for link C-B. The Q space is the set of nodes from which the destination proxy (node B) can be reached without a path transiting the protected link (link C-B).
    The Q space calculation is a reverse SPF on node B. A reverse SPF is run on behalf of each neighbor of C to protect all destinations that resolve over the link to the neighbor. This yields nodes F and A in the example shown in Figure 14.
    You can limit the search for candidate Q nodes to reduce the number of SPF calculations in topologies where many eligible Q nodes may exist. Use the CLI commands described in step 1 to configure the maximum IGP cost from node C for a Q node to be an eligible candidate.
  3. Select the best alternate node, which is the intersection of extended P and Q spaces. In the Figure 14 example, the best alternate node (PQ node) is node F. From node F onwards, traffic follows the IGP shortest path.
    If many PQ nodes exist, the lowest IGP cost from node C is used to narrow the selection; if more than one PQ node remains, the node with the lowest router ID is selected.

Figure 15 shows label stack encoding for a packet that is forwarded over the remote LFA next-hop.

Figure 15:  Remote LFA Next-Hop in Segment Routing 

The label corresponding to the node SID of the PQ node is pushed on top of the original label of the SID of the resolved destination prefix. If node C has resolved multiple node SIDs corresponding to different prefixes of the selected PQ node, it pushes the lowest node SID label on the packet when forwarded over the remote LFA backup next-hop.

If the PQ node is also the advertising router for the resolved prefix, the label stack is compressed in the following cases depending on the IGP.

  1. In IS-IS, the label stack is always reduced to a single label, which is the label of the resolved prefix owned by the PQ node.
  2. In OSPF, the label stack is reduced to the single label of the resolved prefix when the PQ node advertises a single node SID in this OSPF instance. If the PQ node advertises a node SID for multiple of its loopback interfaces within the same OSPF instance, the label stack is reduced to a single label only in the case where the SID of the resolved prefix is the lowest SID value.

The following rules and limitations apply to the remote LFA implementation.

  1. LFA policy is supported for IP next-hops only. It is not supported with tunnel next-hops when IGP shortcuts are used for LFA backup. Remote LFA is also a tunnel next-hop and a user-configured LFA policy is not applied in the selection of a remote LFA backup next-hop when multiple candidates are available.
  2. As a result, if an LFA policy is applied and does not find an LFA IP next-hop for a set of prefixes, the remote LFA SPF searches for a remote LFA next-hop for the same prefixes. The selected remote LFA next-hops, if found, may not satisfy the LFA policy constraints.
  3. If the loopfree-alternate-exclude CLI command (IS-IS or OSPF context of the interface) is used to exclude a network IP interface from being used as an LFA next-hop, the interface is also excluded from being used as the outgoing interface for a remote LFA tunnel next-hop.
  4. As with the regular LFA algorithm, the remote LFA algorithm computes a backup next-hop to the ABR advertising an inter-area prefix and not to the destination prefix.

4.1.9.4. Data Path Support

A packet received with a label matching either a node SID or an adjacency SID is forwarded according to the ILM type and operation, as described in Table 42.

Table 42:  Data Path Support  

Label type

Operation

Top label is a local node SID

The label is popped and the packet is further processed.

If the SID label of the popped node is at the bottom of the stack label, the IP packet is looked up and forwarded in the appropriate FIB.

Top or next label is a remote node SID

The label is swapped to the calculated label value for the next-hop and forwarded according to the primary or backup NHLFE.

With ECMP, a number of primary next-hops (NHLFEs) are programmed for the same destination prefix and for each IGP instance. ECMP and LFA next-hops are mutually exclusive.

Top or next label is an adjacency SID

The label is popped and the packet is forwarded out of the interface to the next-hop associated with this adjacency SID label.

In effect, the data path operation is modeled like a swap to an implicit-null label instead of a pop.

Next label is BGP 3107 label

The packet is further processed according to the ILM operation.

  1. The BGP label may be popped and the packet looked up in the appropriate FIB.

Next label is a service label

The packet is looked up and forwarded in the Layer 2 or VPRN FIB.

A router forwarding an IP or service packet over an SR tunnel pushes a maximum of three transport labels with a remote LFA next-hop.

4.1.9.4.1. Hash Label

When the hash-label option is enabled in a service context, the hash label is always inserted at the bottom of the stack.

On the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C, hash label is supported only with specific services. Refer to the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C Services Guide for more information on services supported with hash label.

4.1.9.5. Control Protocol Changes

This section describes the IS-IS Control Protocol Changes and OSPF Control Protocol Changes.

4.1.9.5.1. IS-IS Control Protocol Changes

The following TLVs/sub-TLVs are defined in draft-ietf-isis-segment-routing-extensions and are supported in the implementation of SR in IS-IS:

  1. prefix SID sub-TLV
  2. adjacency SID sub-TLV
  3. SID/Label Binding TLV
  4. SR-Capabilities sub-TLV
  5. SR-Algorithm sub-TLV

This section describes the behaviors and limitations of using SR TLVs and sub-TLVs with IS-IS.

The 7210 SAS supports advertising the IS router capability TLV (RFC 4971) only for topology MT=0. As a result, the SR-Capabilities sub-TLV can be advertised only in MT=0, which restricts the segment routing feature to MT=0.

Similarly, if prefix SID sub-TLVs for the same prefix are received in different MT numbers of the same IS-IS instance, only the one in MT=0 is resolved. When the prefix SID index is also duplicated, an error is logged and a trap is generated, as explained in Error and Resource Exhaustion Handling.

The I and V flags are both set to 1 when originating the SR-Capabilities sub-TLV to indicate support for processing SR MPLS encapsulated IPv4 and IPv6 packets on its network interfaces. These flags are not checked when the sub-TLV is received. Only the SRGB range is processed.

The algorithm field is set to 0, meaning it uses the SPF algorithm based on link metric, when the SR-Algorithm sub-TLV is originated but the field is not checked when the sub-TLV is received.

Only an IPv4 prefix and adjacency SID sub-TLVs can be originated within MT=0. An IPv6 prefix and adjacency SID sub-TLVs can, however, be received and ignored. Use the show command to display (dump) the octets of the received but unsupported sub-TLVs.

The 7210 SAS originates a single prefix SID sub-TLV per IS-IS IP reachability TLV and processes the first prefix SID sub-TLV only if multiple prefix SID sub-TLVs are received within the same IS-IS IP reachability TLV.

The 7210 SAS encodes the 32-bit index in the prefix SID sub-TLV. The 24-bit label is not supported.

The 7210 SAS originates a prefix SID sub-TLV with the following flag encoding and processing rules.

  1. The R-flag is set if the prefix SID sub-TLV, along with its corresponding IP reachability TLV, is propagated between levels.
  2. The N-flag is always set because the system supports a prefix SID of type node SID only.
  3. The P-flag (no-PHP flag) is always set, meaning that the label for the prefix SID is pushed by the penultimate hop popping (PHP) router when forwarding to this router. The 7210 SAS PHP router processes a received prefix SID with the P-flag set to zero and uses implicit-null for the outgoing label towards the router that advertised it, as long as the P-flag is also set to 1.
  4. The E-flag (Explicit-Null flag) is always set to zero. The PHP router, however, processes a received prefix SID with the E-flag set to 1 and, when the P-flag is also set to 1, it pushes explicit-null for the outgoing label toward the router that advertised it.
  5. The V-flag is always set to 0 to indicate an index value for the SID.
  6. The L-flag is always set to 0 to indicate that the SID index value is not locally significant.
  7. The algorithm field is always set to zero to indicate that the SPF algorithm is based on the link metric and is not checked on a received prefix SID sub-TLV.
  8. The system resolves a prefix SID sub-TLV received without the N-flag set but with the prefix length equal to 32. A trap, however, is raised by IS-IS.
  9. The system does not resolve a prefix SID sub-TLV received with the N flag set and a prefix length different than 32. A trap is raised by IS-IS.
  10. The system resolves a prefix SID received within an IP reachability TLV based on the following route preference:
    1. SID received via level 1 in a prefix SID sub-TLV part of IP reachability TLV
    2. SID received via level 2 in a prefix SID sub-TLV part of IP reachability TLV
  11. A prefix received in an IP reachability TLV is propagated, along with the prefix SID sub-TLV, by default from level 1 to level 2 by a level 1/2 router. A router in level 2 sets up an SR tunnel to the level 1 router via the level 1/2 router, which acts as an LSR.
  12. A prefix received in an IP reachability TLV is not propagated, along with the prefix SID sub-TLV, by default from level 2 to level 1 by a level 1/2 router. If the user adds a policy to propagate the received prefix, a router in level 1sets up an SR tunnel to the level 2 router via the level 1/2 router, which acts as an LSR.
  13. If a prefix is summarized by an ABR, the prefix SID sub-TLV is not propagated with the summarized route between levels. To propagate the node SID for a /32 prefix, route summarization must be disabled.
  14. The 7210 SAS propagates the prefix SID sub-TLV when exporting the prefix to another IS-IS instance; however, it does not propagate it if the prefix is exported from a different protocol. When the corresponding prefix is redistributed from another protocol, such as OSPF, the prefix SID is removed.

The 7210 SAS originates an adjacency SID sub-TLV with the flags encoded as follows.

  1. The F-flag is set to 0 to indicate an IPv4 family and 1 to indicate an IPv6 family for the adjacency encapsulation.
  2. The B-Flag is set to 0 and is not processed on receipt.
  3. The V-flag is always set to 1.
  4. The L-flag is always set to 1.
  5. The S-flag is set to 0 because assigning an adjacency SID to parallel links between neighbors is not supported. A received adjacency SID with the S-flag set is not processed.
  6. The weight octet is not supported and is set to all zeros.

The system does not originate the SID/Label Binding TLV, but can process it if received. The following rules and limitations should be considered.

  1. Only the mapping server prefix-SID sub-TLV within the TLV is processed, and the ILMs are installed if the prefixes in the provided range are resolved.
  2. The range and FEC prefix fields are processed. Each FEC prefix is resolved in the same manner as the prefix SID sub-TLV. In other words, an IP reachability TLV must be received for the exact matching prefix.
  3. If the same prefix is advertised with both a prefix SID sub-TLV and a mapping server prefix-SID sub-TLV, the system uses the following route preference for resolution:
    1. SID received via level 1 in a prefix SID sub-TLV part of the IP reachability TLV
    2. SID received via level 2 in a prefix SID sub-TLV part of the IP reachability TLV
    3. SID received via level 1 in a mapping server prefix-SID sub-TLV
    4. SID received via level 2 in a mapping server prefix-SID sub-TLV
  4. No route leaking of the entire TLV is performed between levels. However, a level 1/2 router will propagate the prefix-SID sub-TLV from the SID/Label Binding TLV (received from a mapping server) into the IP reachability TLV if the latter is propagated between levels.
  5. The mapping server that advertises the SID/Label Binding TLV does not need to be in the shortest path for the FEC prefix.
  6. If the same FEC prefix is advertised in multiple binding TLVs by different routers, the SID in the binding TLV of the first router that is reachable is used. If that router becomes unreachable, the next reachable router is used.
  7. No check is performed of whether the content of the binding TLVs from different mapping servers is consistent.
  8. Other sub-TLV, for example, the SID/Label Sub-TLV, ERO metric, and unnumbered interface ID ERO, are ignored. However, the user can run the IGP show command to get a list of the octets of the received but unsupported sub-TLVs.

4.1.9.5.2. OSPF Control Protocol Changes

The following TLVs/sub-TLVs are defined in draft-ietf-ospf-segment-routing-extensions-04 and are required for the implementation of segment routing in OSPF:

  1. prefix SID sub-TLV part of the OSPFv2 Extended Prefix TLV
  2. prefix SID sub-TLVpart of the OSPFv2 Extended Prefix Range TLV
  3. adjacency SID sub-TLV part of the OSPFv2 Extended Link TLV
  4. SID/Label Range Capability TLV
  5. SR-Algorithm Capability TLV

This section describes the behaviors and limitations of the OSPF support of segment routing TLVs and sub-TLVs.

The 7210 SAS originates a single prefix SID sub-TLV for each OSPFv2 Extended Prefix TLV and processes the first one only if multiple prefix SID sub-TLVs are received within the same OSPFv2 Extended Prefix TLV.

The 7210 SAS encodes the 32-bit index in the prefix SID sub-TLV. The 24-bit label or variable IPv6 SID is not supported.

The 7210 SAS originates a prefix SID sub-TLV with the following flag encoding.

  1. The NP-flag is always set, meaning that the label for the prefix SID is pushed by the PHP router when forwarding to this router. 7210 SAS PHP routers process a received prefix SID with the NP-flag set to zero and use implicit-null for the outgoing label toward the router that advertised it.
  2. The M-flag is always unset because the 7210 SAS does not support originating a mapping server prefix-SID sub-TLV.
  3. The E-flag is always set to 0. The 7210 SAS PHP routers properly process a received prefix SID with the E-flag set to 1, and when the NP-flag is also set to 1, they push explicit-null for the outgoing label towards the router that advertised it.
  4. The V-flag is always set to 0 to indicate an index value for the SID.
  5. The L-flag is always set to 0 to indicate that the SID index value is not locally significant.
  6. The algorithm field is always set to 0 to indicate the SPF algorithm is based on the link metric and is not checked on a received prefix SID sub-TLV.

The system resolves a prefix SID received within an extended prefix TLV based on the following route preference:

  1. SID received via an intra-area route in a prefix SID sub-TLV part of Extended Prefix TLV
  2. SID received via an inter-area route in a prefix SID sub-TLV part of Extended Prefix TLV

The 7210 SAS originates an adjacency SID sub-TLV with the following encoding of the flags.

  1. The F-flag is not set to indicate the adjacency SID refers to an adjacency with outgoing IPv4 encapsulation.
  2. The B-flag is set to 0 and is not processed on receipt.
  3. The V-flag is always set.
  4. The L-flag is always set.
  5. The S-flag is not supported.
  6. The weight octet is not supported and is set to all zeros.

The 7210 SAS does not originate the OSPFv2 Extended Prefix Range TLV but can process it if received. The following rules and limitations should be considered.

  1. Only the prefix SID sub-TLV within the TLV is processed, and the ILMs are installed if the prefixes are resolved.
  2. The range and address prefix fields are processed. Each prefix is resolved separately.
  3. If the same prefix is advertised with both a prefix SID sub-TLV in an IP reachability TLV and a mapping server Prefix-SID sub-TLV, the resolution follows the following route preference:
    1. the SID received via an intra-area route in a prefix SID sub-TLV part of Extended Prefix TLV
    2. the SID received via an inter-area route in a prefix SID sub-TLV part of Extended Prefix TLV
    3. the SID received via an intra-area route in a prefix SID sub-TLV part of an OSPFv2 Extended Range Prefix TLV
    4. the SID received via an inter-area route in a prefix SID sub-TLV part of an OSPFv2 Extended Range Prefix TLV
  4. No route leaking of any part of the TLV is allowed between areas. In addition, an ABR does not propagate the prefix-SID sub-TLV from the Extended Prefix Range TLV (received from a mapping server) into an Extended Prefix TLV if the latter is propagated between areas.
  5. The mapping server that advertised the OSPFv2 extended prefix range TLV does not need to be in the shortest path for the FEC prefix.
  6. If the same FEC prefix is advertised in multiple OSPFv2 extended prefix range TLVs by different routers, the SID in the TLV of the first router that is reachable is used. If that router becomes unreachable, the next reachable one is used.
  7. No check is performed to determine whether the contents of the OSPFv2 Extended Prefix Range TLVs received from different mapping servers are consistent.
  8. Any other sub-TLV (for example, the ERO metric and unnumbered interface ID ERO) is ignored, but the user can get a list of the octets of the received but unsupported sub-TLVs using the existing IGP show command.

The 7210 SAS supports the propagation on ABR of an external prefix LSA into other areas with the route type set to 3 as per draft-ietf-ospf-segment-routing-extensions-04.

The 7210 SAS supports the propagation on ABR of external prefix LSAs with route type 7 from the NSSA area into other areas with the route type set to 5, as described in draft-ietf-ospf-segment-routing-extensions-04. The system does not support the propagation of the prefix SID sub-TLV between OSPF instances.

If an OSPF import policy is configured, the outcome of the policy applies to prefixes resolved in RTM and the corresponding tunnels in TTM. A prefix that is removed by the policy is removed as both a route in the RTM and as an SR tunnel in the TTM.

4.1.9.6. BGP Label Route Resolution Using Segment Routing Tunnels

Configure the following CLI commands to enable the resolution of RFC 3107 BGP label route prefixes using SR tunnels to BGP next-hops in the TTM:

CLI Syntax:
configure>router>bgp>next-hop-resolution
labeled-route-transport-tunnel
[no] family family
resolution {any | disabled | filter}
resolution-filter
[no] sr-isis
[no] sr-ospf
exit
exit
exit
exit

If the resolution option is explicitly set to disabled, the default binding to LDP tunnel is used. If resolution option is set to any, a supported tunnel type from the BGP label route context is selected following the TTM preference.

The following tunnel types are supported in a BGP label route context and are listed in order of preference:

  1. RSVP
  2. LDP
  3. segment routing

When sr-isis or sr-ospf is configured using the resolution-filter option, a tunnel to the BGP next-hop is selected in the TTM from the lowest numbered IS-IS or OSPF instance.

See the BGP chapter for information about BGP label route resolution using SR tunnels.

4.1.9.7. Service Packet Forwarding with Segment Routing

The following SDP subtypes of the MPLS type allow service binding to an SR tunnel programmed in the TTM by OSPF or IS-IS:

  1. config>service>sdp>sr-isis
  2. config>service>sdp>sr-ospf

SDPs of type sr-isis or sr-ospf can be configured with the far-end CLI command. When the sr-isis or sr-ospf command is enabled, a tunnel to the far-end address is selected in the TTM from the lowest preference IS-IS or OSPF instance. If multiple instances have the same lowest preference from the lowest numbered IS-IS or OSPF instance, the SR-ISIS or SR-OSPF tunnel is selected at the time of the binding, using the tunnel selection rules. If a preferred tunnel is subsequently added to the TTM, the SDP will not automatically switch to the new tunnel until the next time the SDP is being re-resolved.

The tunnel-far-end option is not supported. In addition, the mixed-lsp-mode option does not support the sr-isis and sr-ospf tunnel types.

The signaling protocol for the service labels of an SDP using an SR tunnel can be configured to static (off), T-LDP (tldp), or BGP (bgp).

SR tunnels can be configured in a VPRN service with the auto-bind-tunnel command.

VPN-IPv4 and VPN-IPv6 (6VPE) are supported in a VPRN or BGP EVPN service using segment routing transport tunnels with the auto-bind-tunnel command.

See BGP and refer to the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C Services Guide for more information about the VPRN auto-bind-tunnel CLI command.

The following service contexts are supported with SR tunnels:

  1. VLL, LDP, VPLS, and RVPLS
  2. BGP-AD VPLS when the use-provisioned-sdp option is enabled in PW template binding
  3. intra-AS BGP VPRN for VPN-IPv4 and VPN-IPv6 prefixes with both auto-bind and explicit SDP

The following service contexts are not supported:

  1. inter-AS VPRN
  2. dynamic MS-PW, PW-switching
  3. BGP-AD VPLS with auto-generation of SDP using an SR tunnel when binding to a PW template

4.1.9.8. Mirror Services

Note:

SR tunnels for mirror services are not supported on 7210 SAS platforms.

The user can configure a spoke-SDP bound to an SR tunnel to forward mirrored packets from a mirror source to a remote mirror destination. In the configuration of the mirror destination service at the destination node, the remote-source command must use a spoke-SDP with a VC-ID that matches the VC-ID configured in the mirror destination service at the mirror source node. The far-end option is not supported with an SR tunnel.

Use the following syntax to configure a mirror source node.

CLI Syntax:
config mirror mirror-dest service-id
no spoke-sdp <sdp-id:vc-id>
spoke-sdp <sdp-id:vc-id> [create]
egress
vc-label <egress-vc-label>
Note:

  1. sdp-id matches an SDP that uses an SR tunnel.
  2. For vc-label, both static and T-LDP egress VC labels are supported.

Use the following syntax to configure a mirror destination node.

CLI Syntax:
configure mirror mirror-dest service-id remote-source
spoke-sdp <SDP-ID>:<VC-ID> create <-- VC-ID matching that of spoke-sdp configured in mirror destination context at mirror source node.
ingress
vc-label <ingress-vc-label> <--- optional: both static and t-ldp ingress vc label are supported.
exit
no shutdown
exit
exit
Note:

  1. The far-end command in the config>mirror>mirror-dest>remote-source context is not supported with SR tunnels at a mirror destination node; the user must reference a spoke-SDP using a segment routing SDP coming from a mirror source node.
  2. For vc-label, both static and T-LDP ingress VC labels are supported.

4.1.10. IGP-LDP Synchronization

The 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C support IGP-LDP synchronization on IS-IS routes. For information, refer to “IGP-LDP and Static Route-LDP Synchronization on the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C” in the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C Router Configuration Guide.

4.2. IS-IS Configuration Process Overview

Figure 16 shows the process to provision basic IS-IS parameters.

Figure 16:  IS-IS Configuration and Implementation Flow 

4.3. Configuration Notes

This section describes IS-IS configuration caveats.

4.3.1. General

  1. IS-IS must be enabled on each participating routers.
  2. There are no default network entity titles.
  3. There are no default interfaces.
  4. By default, routers are assigned a Level 1/Level 2 level capability.
  5. In network mode, the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C allow the configuration of a single instance at any specific time. The instance ID can be any number other than 0. This enables the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C devices to be used in a network where multi-instance IS-IS is deployed and the node needs to use an instance ID other than the default instance ID of 0.