EVPN Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.11.x
Bias-Free Language
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
EVPN Virtual Private Wire Service (VPWS) - Ethernet Line (E-Line) Service
The terms Virtual Private Wire Service (VPWS) and Ethernet Line (E-Line) Service are used interchangeably.
Table 1. Feature History Table
Feature Name
Release Information
Feature Description
Ethernet VPN Virtual Private Wire Service
Release 7.8.1
The Ethernet VPN Virtual Private Wire Service (EVPN-VPWS) is a BGP control plane solution for point-to-point services. It
implements the signaling and encapsulation techniques for establishing an EVPN instance between a pair of PEs. It provides
the service of forwarding L2 Ethernet traffic between network devices without inspecting the MAC header in the Ethernet frame.
The use of EVPN for VPWS eliminates the need for signaling single-segment and multi-segment pseudowire (PW) for point-to-point
Ethernet services.
The EVPN-VPWS (E-Line) technology works on IP and MPLS core; IP core to support BGP and MPLS core for switching packets between
the endpoints.
EVPN-VPWS Single
Homed
The EVPN-VPWS single homed solution requires per EVI Ethernet Auto
Discovery route. EVPN defines a new BGP Network Layer Reachability Information
(NLRI) used to carry all EVPN routes. BGP Capabilities Advertisement used to
ensure that two speakers support EVPN NLRI (AFI 25, SAFI 70) as per RFC 4760.
The architecture for EVPN-VPWS is that the PEs run Multi-Protocol BGP in a control-plane.
The following image describes the EVPN-VPWS configuration:
Figure 1. EVPN-VPWS Single Homed
The VPWS service on PE1 requires the following three elements to be specified at the configuration time:
The VPN ID (EVI).
The local AC identifier (AC1) that identifies the local end of the emulated service.
The remote AC identifier (AC2) that identifies the remote end of the emulated service.
PE1 allocates an MPLS label per local AC for reachability.
The VPWS service on PE2 is set in the same manner as PE1. The three same elements are required and the service configuration
must be symmetric.
PE2 allocates an MPLS label per local AC for reachability.
PE1 advertises a single EVPN per EVI Ethernet AD route for each local endpoint (AC) to remote PEs with the associated MPLS
label.
PE2 performs the same task.
On reception of EVPN per EVI EAD route from PE2, PE1 adds the entry to its local EVPN data base. PE1 knows the path list to
reach AC2, for example, next hop is PE2 IP address and MPLS label for AC2.
PE2 performs the same task.
Restrictions for EVPN-VPWS
EVPN-VPWS does not support Pseudowire Headend (PWHE) configuration.
EVPN-VPWS is supported only on single-homing and is not supported on dual homing. This is applicable for both the local and
remote sides of the network.
EVPN validates if the route is for a single home next hop, otherwise it issues an error message. An Ethernet Segment Identifier
(ESI) is an attribute that is used to enable EVPN multi-homing. EVPN relies on the ESI value being zero to determine if this
is a single home or not. If the AC is a Bundle-Ether interface running LACP, then you need to manually configure the ESI value
to zero to overwrite the auto-sense ESI, as EVPN-VPWS multi-homing is not supported.
To disable EVPN dual homing, configure bundle-Ether AC with ESI value (identifier type) set to zero.
When expanding an existing L2VPN network, users may want to deploy EVPN-VPWS to provide additional Layer 2 point-to-point
Ethernet services, and at the same time some of their customer traffic may still need to be terminated on the existing L2VPN
PEs on their network.
Users can migrate the PE nodes from L2VPN VPWS to EVPN-VPWS, without disruption in traffic. The seamless migration offers
users the option to use either VPWS or EVPN-VPWS services on PE nodes. This allows the coexistence of legacy VPWS and EVPN-VPWS
dual-stack in the core for a given L2 Attachment Circuit (AC) over the same MPLS network.
Although VPWS is a widely deployed Layer 2 VPN technology, some users prefer to migrate to EVPN service in their existing
VPWS networks to leverage the benefits of EVPN services.
With EVPN-VPWS Seamless Integration feature, users can migrate the PE nodes from legacy VPWS service to EVPN-VPWS gradually
and incrementally without any service disruption.
Users can migrate an Attachment Circuit (AC) connected to a legacy VPWS pseudowire (PW), which is using targeted-LDP signaling
or BGP-AD signaling, to an EVPN-VPWS service.
In an EVPN-VPWS network, VPN instances are grouped by EVPN Instance VPN ID (EVI) and identified by an ethernet tag or attachment
circuit ID (AC-ID). EVI is also associated with route-targets and route-distinguisher.
During migration, an EVPN-VPWS PE router performs either VPWS or EVPN-VPWS L2 cross-connect for a given AC. When both EVPN-VPWS
and BGP-AD PWs are configured for the same AC, the EVPN-VPWS PE during migration advertises the BGP VPWS Auto-Discovery (AD)
route as well as the BGP EVPN Auto-Discovery (EVI/EAD) route and gives preference to EVPN-VPWS Pseudowire (PW) over the BGP-AD
VPWS PW.
Let’s understand how a legacy VPWS network can be migrated seamlessly to EVPN-VPWS with the following scenario:
Consider that a user plans to migrate VPWS node to an EVPN node one at a time. The user expects the migration to span over
multiple years.
Figure 2. VPWS Nodes
In this topology, PE1, PE2, PE3 are provider edge devices in the MPLS network and the legacy VPWS cross-connects are up and
running between PE1, PE2, and PE3.
PE1 and PE2 have a legacy PW established between them. (pw1)
PE1 and PE3 have a legacy PW established between them. (pw2)
The user wants to replace PE1 with a new hardware. After replacing the equipment, the user enables EVPN-VPWS on PE1.
Figure 3. PE1 Enabled with EVPN-VPWS
Let’s understand what happens when only PE1 is migrated to EVPN-VPWS:
When EVPN-VPWS is enabled, PE1 starts advertising EVPN EVI or Ethernet-AD route to other PE nodes.
PE1 advertises BGP VPWS Auto-Discovery route and the BGP EVPN Ethernet-AD per EVI route for a given PW.
As PE2 and PE3 aren’t yet migrated, PE1 does not receive any EVI/EAD routes from these PE nodes. Therefore, legacy VPWS runs
between PE1, PE2, and PE3.
PE1 keeps forwarding traffic using legacy VPWS.
After one year, the user decides to upgrade PE2 and wants to migrate from VPWS to EVPN-VPWS.
Figure 4. PE2 enabled with EVPN-VPWS
When the upgrade is completed, PE2 starts advertising EVI/EAD route to other PE nodes.
Both PE1 and PE2 discover each other through EVPN routes.
As a result, EVPN-VPWS service replaces legacy VPWS service between PE1 and PE2. This is called EVPN Seamless Integration
with legacy VPWS.
EVPN-VPWS service takes high-precedence over legacy VPWS network.
PE1 and PE2 shuts down the legacy VPWS between them to prevent ongoing duplicate packets from remote CE.
PE3 device is not yet migrated and still runs legacy VPWS:
At this stage, PE1 keeps running legacy VPWS service with PE3.
The legacy VPWS to EVPN-VPWS migration then continues to remaining PE nodes. The legacy VPWS and EVPN-VPWS dual-stack coexist
in the core for a given L2 Attachment Circuit (AC).
After another year, the user plans to upgrade the PE3 device.
PE3 is now enabled with EVPN-VPWS service.
All the PE devices are replaced with EVPN-VPWS services in the network.
The user plans to retain both legacy and an EVPN-VPWS related configuration on PE1 and PE2 nodes.
If there are any issues in the network, the user can roll back the migration. After the rollback, the migration to VPWS at
node PE2, then PE1 and PE2, will revert to the legacy VPWS between them
Configure EVPN Seamless Integration with Legacy VPWS
To enable the feature, use the vpws-seamless-integration command.
Configuration Example
The following example shows how to migrate each PE at a time. In this example, the following Customer Edge (CE) IDs are used:
PE1 is connected to CE1 and CE3.
PE2 is connected to CE2.
PE3 is connected to CE4.
For legacy VPWS configuration, perform the following tasks:
Configure a cross-connect (xconnect) group for VPWS.
Configure a name for xconnect in the mp2mp mode.
Configure BGP autodiscovery.
Enable BGP signaling.
Configure the local CE ID.
Configure an interface with the remote CE ID.
The VPWS cross-connect is established between the local and remote CEs.
For migrating the PEs from legacy VPWS to EVPN-VPWS, perform the following tasks:
In the existing VPWS cross-connect, enable the VPWS seamless integration on the local CE.
Configure the interface used in VPWS configuration with the remote CE ID.
Configure a cross-connect (xconnect) group for EVPN-VPWS.
Configure a name for xconnect in the p2p mode.
Assign the interface used in VPWS configuration.
Enable EVPN-VPWS on the p2p xconnect.
EVPN-VPWS service is established between the local and remote CEs.
Migration of PE1
In this example, both legacy VPWS and EVPN-VPWS coexist on PE1.
As PE2 and PE3 are not migrated to EVPN-VPWS, legacy VPWS continues to run between the PE devices. The following show output
indicates that only legacy VPWS is up and EVPN-VPWS is down on BE1.1.
Router# show l2vpn xconnect
Legend: ST = State, UP = Up, DN = Down, AD = Admin Down, UR = Unresolved,
SB = Standby, SR = Standby Ready, (PP) = Partially Programmed,
LU = Local Up, RU = Remote Up, CO = Connected, (SI) = Seamless Inactive
XConnect Segment 1 Segment 2
Group Name ST Description ST Description ST
--------------------------- ----------------------------- -----------------------------
evpn-vpws evpn1 DN BE1.1 UP EVPN 4,5,24004 DN
----------------------------------------------------------------------------------------
legacy-vpws vpws1 UP BE1.1 UP 192.168.0.4 534296 UP
----------------------------------------------------------------------------------------
legacy-vpws vpws1 UP BE1.2 UP 192.168.12.110 685694 UP
----------------------------------------------------------------------------------------
Migration of PE1 and PE2
In this example, both legacy VPWS and EVPN-VPWS coexist on PE1. PE2 is migrated to EVPN-VPWS.
After the migration, legacy VPWS and EVPN-VPWS coexist on PE1. PE2 is migrated to EVPN-VPWS and PE3 runs with legacy VPWS.
EVPN-VPWS service runs between PE1 and PE2.
Legacy VPWS service runs between PE1 and PE3.
The following example shows that EVPN-VPWS is up on BE1.1. The legacy VPWS is also advertised on BE1.1 with the status as
Standby ( SB(SI)).
Router# show l2vpn xconnect
Legend: ST = State, UP = Up, DN = Down, AD = Admin Down, UR = Unresolved,
SB = Standby, SR = Standby Ready, (PP) = Partially Programmed,
LU = Local Up, RU = Remote Up, CO = Connected, (SI) = Seamless Inactive
XConnect Segment 1 Segment 2
Group Name ST Description ST Description ST
--------------------------- ----------------------------- -----------------------------
evpn-vpws evpn1 UP BE1.1 UP EVPN 4,5,24004 UP
----------------------------------------------------------------------------------------
legacy-vpws vpws1 DN BE1.1 SB(SI) 192.168.0.4 534296 UP
----------------------------------------------------------------------------------------
legacy-vpws vpws1 UP BE1.2 UP 192.168.12.110 685694 UP
----------------------------------------------------------------------------------------
Use the show l2vpn forwarding interfaceinterface-type interface-path-id detail locationnode-id command to identify whether EVPN-VPWS or VPWS is used for forwarding the traffic.
In this example, evi: 1 indicates that EVPN-VPWS is used for forwarding the traffic.
Router# show l2vpn forwarding interface Bundle-Ether1.1 detail location 0/2/CPU0
Wed Apr 28 09:08:37.512 EDT
Local interface: Bundle-Ether1.1, Xconnect id: 0x800001, Status: up
Segment 1
AC, Bundle-Ether1.1, status: Bound
Statistics:
packets: received 0, sent 0
bytes: received 0, sent 0
Segment 2
MPLS, Destination address: 192.168.0.4, evi: 4, ac-id: 5, status: Bound
Pseudowire label: 24001
Control word enabled
Statistics:
packets: received 0, sent 0
bytes: received 0, sent 0
In this example, pw-id: 1 indicates that VPWS is used for forwarding the traffic.
Router# show l2vpn forwarding interface Bundle-Ether1.1 detail location 0/2/CPU0
Wed Apr 28 09:09:45.204 EDT
Local interface: Bundle-Ether1.1, Xconnect id: 0x800001, Status: up
Segment 1
AC, Bundle-Ether1.1, status: Bound
Statistics:
packets: received 0, sent 0
bytes: received 0, sent 0
Segment 2
MPLS, Destination address: 192.168.0.4, pw-id: 1, status: Bound
Pseudowire label: 24000
Control word disabled
Statistics:
packets: received 0, sent 0
bytes: received 0, sent 0
Use the l2vpn logging pseudowire command to track the migration of AC from one PW to another.
Router(config)# l2vpn logging pseudowire
RP/0/0/CPU0:Jan 18 15:35:15.607 EST:
l2vpn_mgr[1234]: %L2-EVPN-5-VPWS_SEAMLESS_INTEGRATION_STATE_CHANGE :
GigabitEthernet0/2/0/8.1 - Active XC is now service-1:evpn-vpws-1, standby XC is service-1:legacy-vpws-1
Migration of PE1, PE2, and PE3
In this example, both legacy VPWS and EVPN-VPWS coexist on PE1. PE2 and PE3 are migrated to EVPN-VPWS.
After migration, all the PE devices forward traffic between them using EVPN-VPWS.
The following example shows that EVPN-VPWS is up and legacy VPWS is down.
Router# show l2vpn xconnect
Legend: ST = State, UP = Up, DN = Down, AD = Admin Down, UR = Unresolved,
SB = Standby, SR = Standby Ready, (PP) = Partially Programmed,
LU = Local Up, RU = Remote Up, CO = Connected, (SI) = Seamless Inactive
XConnect Segment 1 Segment 2
Group Name ST Description ST Description ST
--------------------------- ----------------------------- -----------------------------
evpn-vpws evpn1 UP BE1.1 UP EVPN 4,5,24004 UP
----------------------------------------------------------------------------------------
legacy-vpws vpws1 DN BE1.1 UP 192.168.0.4 534296 DN
----------------------------------------------------------------------------------------
evpn-vpws evpn2 UP BE1.2 UP EVPN 4,7,24008 UP
----------------------------------------------------------------------------------------
legacy-vpws vpws1 DN BE1.2 UP 192.168.12.110 685694 DN
----------------------------------------------------------------------------------------
TLDP PW to EVPN-VPWS Migration
Similar to migrating VPWS to EVPN, you can also migrate Targeted Label Distribution Protocol (TLDP) PW to EVPN-VPWS on all
the PE routers incrementally.
You can perform this task on all the PE routers incrementaly. The following configuration example shows the TLDP PW to EVPN-VPWS
migration on PE1:
Private Line Emulation over EVPN-VPWS Single Homed
Table 3. Feature History Table
Feature Name
Release Information
Feature Description
Private Line Emulation over EVPN-VPWS Single Homed
Release 7.11.1
Introduced in this release on: Cisco 8011-2X2XP4L PLE Service Endpoint Router.
You can now configure EVPN VPWS to carry the client traffic from ports like FC, OTN, SDH, SONET, or Ethernet and forward the
traffic to the core network by using Private Line Emulation (PLE).
PLE emulates the switching capabilities of FC, OTN, SDH, SONET, or Ethernet ports without needing a dedicated equipment and
allows interconnecting optical networks with Ethernet networks.
This feature introduces the port-mode command.
This release introduces new and modified YANG data models for PLE. For the list of supported data models, see Supported Yang Data Models for PLE. You can access these data models from the Github repository.
PLE service is a mechanism that allows the transparent transfer of packets from different port modes over MPLS networks.
PLE client traffic is carried on EVPN-VPWS single homed service. The PLE endpoints establish a BGP session to exchange EVPN
route information. The pseudowire channel is set up between the endpoints when the L2VPN cross-connect is set up between PLE
client, represented as Circuit Emulation (CEM) interface, and the remote node.
CEM helps PLE endpoints to provide native client interfaces. CEM service is a method through which data can be transmitted
over Ethernet or MPLS networks. CEM over a packet carries circuits over Packet Switched Network (PSN) placing the client bitstreams
into packet payload with appropriate pseudowire emulation headers.
PLE client traffic is encapsulated by PLE initiator and is carried over EVPN-VPWS L2 service running on segment routing or
MPLS tunnels. PLE terminator node extracts the bitstreams from the EVPN packets and places them to the PLE client interface
as defined by the client attribute and CEM profile. The traffic flow between the client and core networks happens with label
imposition and disposition.
PLE Forwarding Flow – Imposition
Imposition is the process of adding an MPLS label to a data packet. A PE router forwards traffic from a client interface by
adding an MPLS label to the packet upon entering an MPLS network. When PLE forwards traffic from client to core network, label
imposition is used to forward the packets.
Figure 5. PLE Forwarding Flow – Imposition
In the diagram, traffic from client may be of any port mode like FC, OTN, SDH, SONET, or Ethernet. Field Programmable Gate
Array (FPGA) acts as a forwarding block. FPGA sends the traffic from the client towards NPU with an assigned internal local
label.
In this example, the traffic from client flows through CEM interface. The internal local label 100 is added to the CEM interface
0/0/0/1 in the FPGA.
NPU receives traffic with assigned internal local label from FPGA and in the forwarding L3 chain, replaces the internal local
label 100 with Virtual Circuit (VC) label 200. VC label is also known as the pseudowire (PW) label.
The traffic is then forwarded towards core network using the transport label 24001.
PLE Forwarding Flow – Disposition
Disposition is the process of removing an MPLS label from a data packet. A PE router receives an MPLS packet, makes a forwarding
decision based on the MPLS label, removes the label, and sends the traffic to the client. When PLE forwards traffic from core
to client network, label disposition is used to forward the packets.
Figure 6. PLE Forwarding Flow – Disposition
In the diagram, NPU receives traffic with VC label.
NPU determines the outgoing interface for the traffic, based on the VC label allocation.
The VC label 200 is replaced with the internal local label 100 and sent to FPGA.
In the FPGA, the internal local label is mapped to CEM interface 0/0/0/1 and traffic is forwarded to the client through the
CEM interface.
PLE Transport Mechanism
You can configure circuit-style segment routing to transport PLE client traffic over the networks. Circuit-style SR-TE supports
the following:
Co-router bidirectional paths
Guaranteed latency
End-to-end path protection
Guaranteed bandwidth
The circuit-style SR-TE policies are configured statically as preferred path within a pseudowire class. An SR-TE policy is
associated per pseudowire by assigning corresponding pseudowire class to working or protected pseudowires.
For more information on SR-TE policies, see the Configure SR-TE Policies section in the Segment Routing Configuration Guide for Cisco 8000 Series Routers, IOS XR.
Supported Hardware for PLE
PLE is supported on Cisco 8011-2X2XP4L PLE Service Endpoint Router with SFP+ optical transceivers and supports the following port mode options:
Ethernet – 10GE
Fiber channel (FC) – 1G, 2G, 4G, 8G, 16G, and 32G
Optical Transport Network (OTN) – OTU2 and OTU2e
Synchronous Digital Hierarchy (SDH) – STM16 and STM64
Synchronous Optical Networking (SONET) – OC48 and OC192
Restrictions for PLE over EVPN VPWS
Note
These following restrictions are applicable only to Cisco 8011-2X2XP4L PLE Service Endpoint Router for IOS XR Release 7.11.1.
Load balancing is not supported for PLE traffic in the core, because PLE does not work with ECMP or core bundle having more
than one member link.
Software offloading is supported only on SR-TE performance monitoring and hence Fast Reroute (FRR) convergence is not possible.
PLE circuit over SR-TE tunnel with deep label stack is not supported, as this may lead to the circuit being down. For more
information on label stacking, see MPLS Configuration Guide for Cisco 8000 Series Routers, IOS XR.
Configure PLE over EVPN VPWS
Prerequisites
Install all the mandatory Cisco RPMS like RSVP for MPLS-TE. For more information, see the Implementing RSVP for MPLS-TE section in the MPLS Configuration Guide for Cisco 8000 Series Routers, IOS XR.
Ensure that the clocks between the routers in the network is synchronized with Synchronous Ethernet (SyncE) or Precision Time
Protocol (PTP), to avoid drop in the data traffic.
Core interface bandwidth must be higher than the access interface. For example, when traffic from CE is 10G, it becomes 12.5G
when it reaches the core. Hence, the core interface bandwidth must be at least 25G.
Topology
Figure 7. PLE over EVPN VPWS
In this topology, CEM interfaces are connected to PLE interfaces. The PLE interfaces, PE1 and PE2, are connected through EVPN-VPWS
single homing. The PLE interface can be: Ethernet, OTN, FC, or SONET/SDH.
Configuration Example
Perform the following tasks to configure EVPN-VPWS over SR-TE policy with explicit path. For more information on SR-TE policies,
see the Configure SR-TE Policies section in the Segment Routing Configuration Guide for Cisco 8000 Series Routers, IOS XR.
Enable Frequency Synchronization to synchronize the clock between the PE routers.
Bring up the Optics Controller in CEM Packet Mode, based on the port mode type.
Configure Access and Core Interfaces.
Configure Loopback Interface to establish BGP-EVPN neighborship.
Configure IS-IS IGP to advertise the loopback and core interfaces.
Configure Performance Measurement to enable liveness monitoring of SR policy.
Configure Segment Routing Traffic Engineering Tunnels with circuit-styled SR-TE tunnels and explicit path.
Configure BGP EVPN Neighbor Session to exchange EVPN route information.
Configure EVPN VPWS with pseudowire class (PW) and cross-connect (xconnect) service to carry the PLE client traffic.
Configure QoS Policy on CEM Interface to manage congestion on PLE client traffic.
(Use the show frequency synchronization interfaces command to verify that the clock is transmitted.)
/* Enable Frequency Synchronization on PLE-PE2 */
Router(config)# frequency synchronization
Router(config-freqsync)# quality itu-t option 1
Router(config-freqsync)# exit
Router(config)# interface TwentyFiveGigE0/0/0/32
Router(config-if)# frequency synchronization
Router(config-if-freqsync)# selection input
Router(config-if-freqsync)# priority 1
Router(config-if-freqsync)# wait-to-restore 0
!
(Use the show frequency synchronization selection command to verify if PLE-PE2 is LOCKED to PLE-PE1's clock.)
Bring up the Optics Controller in CEM Packet Mode
Configure the optics controller and port mode. The examples show port mode configuration for all the types of port modes.
Use the relevant command according to the port mode type of the PLE interface.
/* Bring up the optics controller in CEM packet mode with appropriate speed on PLE-PE1 */
Configure IS-IS IGP to advertise the configured loopback and core interfaces.
Note
You cannot configure Topology-Independent Loop-Free Alternate (TI-LFA) on the links used by circuit-styled SR-TE tunnel. The
adjacency SID label is unprotected for circuit-styled SR-TE, which does not support TI-LFA.
Configure circuit-styled SR-TE tunnels. SR-TE is supported only with explicit path specified by adjacency SID labels. The
adjacency SID labels must be unprotected for circuit-styled SR-TE. This example shows configuration of explicit path between
PE1 and PE2.
/* Configure segment routing traffic engineering tunnels on PLE-PE1 */
Configure QoS policy to manage congestion on PLE client traffic. In QoS for PLE, you can mark the MPLS experimental with only
the topmost label and set the traffic class with only the default class.
/* Configure QoS policy on PLE-PE1 */
Access Interface Configuration
Router(config)# policy-map ple-policy
Router(config-pmap)# class class-default
Router(config-pmap-c)# set mpls experimental topmost 7
Router(config-pmap-c)# set traffic-class 2
Router(config-pmap-c)# end-policy-map
!
Router(config)# interface CEM0/0/1/0
Router(config-if)# l2transport
Router(config-if)# service-policy input ple-policy
!
!
Use the following show commands to view the configuration.
Verify the IS-IS configuration.
Router# show isis neighbors
Fri Nov 12 09:04:13.638 UTC
IS-IS core neighbors:
System Id Interface SNPA State Holdtime Type IETF-NSF
PLE-Core-PE2 TF0/0/0/24 *PtoP* Up 28 L2 Capable
Total neighbor count: 1
Router# show isis segment-routing label table
Fri Nov 12 09:25:18.488 UTC
IS-IS core IS Label Table
Label Prefix Interface
---------- ---------------- ---------
16001 1.1.1.1/32Loopback0
16004 1.1.1.4/32
Router# show mpls forwarding prefix 1.1.1.4/32
Fri Nov 12 09:25:54.898 UTC
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ----------- ------------------ ------------ --------------- ------------
16004 Pop SR Pfx (idx 4) TF0/0/0/24 14.1.0.2 104332
Verify the performance measurement.
Router# show performance-measurement sr-policy color 203
Mon Mar 14 17:54:32.403 IST
------------------------------------------------------------------
0/RP0/CPU0
------------------------------------------------------------------
SR Policy name: srte_c_203_ep_1.1.1.1
Color : 203
Endpoint : 1.1.1.1
Number of candidate-paths : 1
Candidate-Path:
Instance : 8
Preference : 10
Protocol-origin : Configured
Discriminator : 10
Profile Keys:
Profile name : BLUE
Profile type : SR Policy Liveness Detection
Source address : 1.1.1.6
Number of segment-lists : 1
Liveness Detection: Enabled
Session State: Up
Last State Change Timestamp: Mar 14 2022 17:53:45.207
Missed count: 0
---------------------------------------------------------------------
0/0/CPU0
---------------------------------------------------------------------
Verify SR-TE configuration.
Router# show segment-routing traffic-eng policy color 10 tabular
Fri Nov 12 09:15:57.366 UTC
Color Endpoint AdminOper Binding
StateState SID
------ --------------------------------------- ------ ------ -----------------------
10 1.1.1.4 upup 24010
Verify BGP EVPN neighbor session configuration.
Router# show bgp l2vpn evpn neighbors brief
Fri Nov 12 09:10:22.999 UTC
Neighbor Spk AS Description Up/Down NBRState
1.1.1.4 0 100 15:51:52 Established
Verify EVPN VPWS configuration.
Router# show l2vpn xconnect
Fri Nov 12 09:02:44.982 UTC
Legend: ST = State, UP = Up, DN = Down, AD = Admin Down, UR = Unresolved,
SB = Standby, SR = Standby Ready, (PP) = Partially Programmed,
LU = Local Up, RU = Remote Up, CO = Connected, (SI) = Seamless Inactive
XConnect Segment 1 Segment 2
Group Name ST Description ST Description ST
----------------------------------------------------------------------------------------
evpn_vpws p1 UP CE0/0/1/0 UP EVPN 10,1,24012 UP
----------------------------------------------------------------------------------------
Verify QoS policy configuration.
The following show command displays information about interfaces on which the policy maps are applied.
Router# show policy-map targets
Thu Jun 16 21:47:31.407 IST
1) Policymap: ple-p1 Type: qos
Targets (applied as main policy):
CEM0/0/1/0 input
Total targets: 1
Targets (applied as child policy):
Total targets: 0
2) Policymap: core Type: qos
Targets (applied as main policy):
TwentyFiveGigE0/0/0/24
Total targets: 1
Targets (applied as child policy):
Total targets: 0
Use the following show command to view the core interface information and to verify the traffic class (TC) mapping in CEM
interface.
Router# Show policy-map interface TwentyFiveGigE0/0/0/24
Thu Jun 16 21:37:52.915 IST
TwentyFiveGigE0/0/0/24 direction input: Service Policy is not installed
TwentyFiveGigE0/0/0/24 output: core
Class tc2
Classification Statistics (packets/bytes) (rate - kbps)
Matched : 39654778/42113374236 6816279
Transmitted : 39654778/42113374236 6816279
Total Dropped : 0/0 0
Queueing Statistics
Queue ID : 1370
Taildropped(packets/bytes) : 0/0
Class class-default
Classification Statistics (packets/bytes) (rate - kbps)
Matched : 0/0 0
Transmitted : 0/0 0
Total Dropped : 0/0 0
Queueing Statistics
Queue ID : 1368
Taildropped(packets/bytes) : 0/0
Policy Bag Stats time: 1655395669491 [Local Time: 06/16/22 21:37:49:491]
Supported Yang Data Models for PLE
The following is the list of new and modified Yang data models supported for PLE. You can access the data models from the
Github repository.
Feedback