CCIE SPv5.1 Labs
  • Intro
    • Setup
  • Purpose
  • Video Demonstration
  • Containerlab Tips
  • Labs
    • ISIS
      • Start
      • Topology
      • Prefix Suppression
      • Hello padding
      • Overload Bit
      • LSP size
      • Default metric
      • Hello/Hold Timer
      • Mesh groups
      • Prefix Summarization
      • Default Route Preference
      • ISIS Timers
      • Log Neighbor Changes
      • Troubleshooting 1 - No routes
      • Troubleshooting 2 - Adjacency
      • IPv6 Single Topology
      • IPv6 Single Topology Challenge
      • IPv6 Multi Topology
      • IPv6 Single to Multi Topology
      • Wide Metrics Explained
      • Route Filtering
      • Backdoor Link
      • Non-Optimal Intra-Area routing
      • Multi Area
      • Authentication
      • Conditional ATT Bit
      • Troubleshooting iBGP
      • Troubleshooting TE Tunnel
    • LDP
      • Start
      • Topology
      • LDP and ECMP
      • LDP and Static Routes
      • LDP Timers
      • LDP Authentication
      • LDP Session Protection
      • LDP/IGP Sync (OSPF)
      • LDP/IGP Sync (ISIS)
      • LDP Local Allocation Filtering
      • LDP Conditional Label Advertisement
      • LDP Inbound Label Advertisement Filtering
      • LDP Label Advertisement Filtering Challenge
      • LDP Implicit Withdraw
      • LDP Transport Address Troubleshooting
      • LDP Static Labels
    • MPLS-TE
      • Start
      • Topology
      • Basic TE Tunnel w/ OSPF
      • Basic TE Tunnel w/ ISIS
      • TE Tunnel using Admin Weight
      • TE Tunnel using Link Affinity
      • TE Tunnel with Explicit-Null
      • TE Tunnel with Conditional Attributes
      • RSVP message pacing
      • Reoptimization timer
      • IGP TE Flooding Thresholds
      • CSPF Tiebreakers
      • TE Tunnel Preemption
      • TE Tunnel Soft Preemption
      • Tunneling LDP inside RSVP
      • PE to P TE Tunnel
      • Autoroute Announce Metric (XE)
      • Autoroute Announce Metric (XR)
      • Autoroute Announce Absolute Metric
      • Autoroute Announce Backup Path
      • Forwarding Adjacency
      • Forwarding Adjacency with OSPF
      • TE Tunnels with UCMP
      • Auto-Bandwidth
      • FRR Link Protection (XE, BFD)
      • FRR Link Protection (XE, RSVP Hellos)
      • FRR Node Protection (XR)
      • FRR Path Protection
      • FRR Multiple Backup Tunnels (Node Protection)
      • FRR Multiple Backup Tunnels (Link Protection)
      • FRR Multiple Backup Tunnels (Backwidth/Link Protection)
      • FRR Backup Auto-Tunnels
      • FRR Backup Auto-Tunnels with SRLG
      • Full Mesh Auto-Tunnels
      • Full Mesh Dynamic Auto-Tunnels
      • One-Hop Auto-Tunnels
      • CBTS/PBTS
      • Traditional DS-TE
      • IETF DS-TE with MAM
      • IETF DS-TE with RDM
      • RDM w/ FRR Troubleshooting
      • Per-VRF TE Tunnels
      • Tactical TE Issues
      • Multicast and MPLS-TE
    • SR
      • Start
      • Topology
      • Basic SR with ISIS
      • Basic SR with OSPF
      • SRGB Modifcation
      • SR with ExpNull
      • SR Anycast SID
      • SR Adjacency SID
      • SR LAN Adjacency SID (Walkthrough)
      • SR and RSVP-TE interaction
      • SR Basic Inter-area with ISIS
      • SR Basic Inter-area with OSPF
      • SR Basic Inter-IGP (redistribution)
      • SR Basic Inter-AS using BGP
      • SR BGP Data Center (eBGP)
      • SR BGP Data Center (iBGP)
      • LFA
      • LFA Tiebreakers (ISIS)
      • LFA Tiebreakers (OSPF)
      • Remote LFA
      • RLFA Tiebreakers?
      • TI-LFA
      • Remote LFA or TILFA?
      • TI-LFA Node Protection
      • TI-LFA SRLG Protection
      • TI-LFA Protection Priorities (ISIS)
      • TI-LFA Protection Priorities (OSPF)
      • Microloop Avoidance
      • SR/LDP Interworking
      • SR/LDP SRMS OSPF Inter-Area
      • SR/LDP Design Challenge #1
      • SR/LDP Design Challenge #2
      • Migrate LDP to SR (ISIS)
      • OAM with SR
      • SR-MPLS using IPv6
      • Basic SR-TE with AS
      • Basic SR-TE with AS and ODN
      • SR-TE with AS Primary/Secondary Paths
      • SR-TE Dynamic Policies
      • SR-TE Dynamic Policy with Margin
      • SR-TE Explicit Paths
      • SR-TE Disjoint Planes using Anycast SIDs
      • SR-TE Flex-Algo w/ Latency
      • SR-TE Flex-Algo w/ Affinity
      • SR-TE Disjoint Planes using Flex-Algo
      • SR-TE BSIDs
      • SR-TE RSVP-TE Stitching
      • SR-TE Autoroute Include
      • SR Inter-IGP using PCE
      • SR-TE PCC Features
      • SR-TE PCE Instantiated Policy
      • SR-TE PCE Redundancy
      • SR-TE PCE Redundancy w/ Sync
      • SR-TE Basic BGP EPE
      • SR-TE BGP EPE for Unified MPLS
      • SR-TE Disjoint Paths
      • SR Converged SDN Transport Challenge
      • SR OAM DPM
      • SR OAM Tools
      • Performance-Measurement (Interface Delay)
    • SRv6
      • Start
      • Topology
      • Basic SRv6
      • SRv6 uSID
      • SRv6 uSID w/ EVPN-VPWS and BGP IPv4/IPv6
      • SRv6 uSID w/ SR-TE
      • SRv6 uSID w/ SR-TE Explicit Paths
      • SRv6 uSID w/ L3 IGW
      • SRv6 uSID w/ Dual-Connected PE
      • SRv6 uSID w/ Flex Algo
      • SRv6 uSID - Scale (Pt. 1)
      • SRv6 uSID - Scale (Pt. 2)
      • SRv6 uSID - Scale (Pt. 3) (UPA Walkthrough)
      • SRv6 uSID - Scale (Pt. 4) (Flex Algo)
      • SRv6 uSID w/ TI-LFA
    • Multicast
      • Start
      • Topology
      • Basic PIM-SSM
      • PIM-SSM Static Mapping
      • Basic PIM-SM
      • PIM-SM with Anycast RP
      • PIM-SM with Auto-RP
      • PIM-SM with BSR
      • PIM-SM with BSR for IPv6
      • PIM-BiDir
      • PIM-BiDir for IPv6
      • PIM-BiDir with Phantom RP
      • PIM Security
      • PIM Boundaries with AutoRP
      • PIM Boundaries with BSR
      • PIM-SM IPv6 using Embedded RP
      • PIM SSM Range Note
      • PIM RPF Troubleshooting #1
      • PIM RPF Troubleshooting #2
      • PIM RP Troubleshooting
      • PIM Duplicate Traffic Troubleshooting
      • Using IOS-XR as a Sender/Receiver
      • PIM-SM without Receiver IGMP Joins
      • RP Discovery Methods
      • Basic Interdomain Multicast w/o MSDP
      • Basic Interdomain Multicast w/ MSDP
      • MSDP Filtering
      • MSDP Flood Reduction
      • MSDP Default Peer
      • MSDP RPF Check (IOS-XR)
      • MSDP RPF Check (IOS-XE)
      • Interdomain MBGP Policies
      • PIM Boundaries using MSDP
    • MVPN
      • Start
      • Topology
      • Profile 0
      • Profile 0 with data MDTs
      • Profile 1
      • Profile 1 w/ Redundant Roots
      • Profile 1 with data MDTs
      • Profile 6
      • Profile 7
      • Profile 3
      • Profile 3 with S-PMSI
      • Profile 11
      • Profile 11 with S-PMSI
      • Profile 11 w/ Receiver-only Sites
      • Profile 9 with S-PMSI
      • Profile 12
      • Profile 13
      • UMH (Upstream Multicast Hop) Challenge
      • Profile 13 w/ Configuration Knobs
      • Profile 13 w/ PE RP
      • Profile 12 w/ PE Anycast RP
      • Profile 14 (Partitioned MDT)
      • Profile 14 with Extranet option #1
      • Profile 14 with Extranet option #2
      • Profile 14 w/ IPv6
      • Profile 17
      • Profile 19
      • Profile 21
    • MVPN SR
      • Start
      • Topology
      • Profile 27
      • Profile 27 w/ Constraints
      • Profile 27 w/ FRR
      • Profile 28
      • Profile 28 w/ Constraints and FRR
      • Profile 28 w/ Data MDTs
      • Profile 29
    • VPWS
      • Start
      • Topology
      • Basic VPWS
      • VPWS with Tag Manipulation
      • Redundant VPWS
      • Redundant VPWS (IOS-XR)
      • VPWS with PW interfaces
      • Manual VPWS
      • VPWS with Sequencing
      • Pseudowire Logging
      • VPWS with FAT-PW
      • MS-PS (Pseudowire stitching)
      • VPWS with BGP AD
    • VPLS
      • Start
      • Topology
      • Basic VPLS with LDP
      • VPLS with LDP and BGP
      • VPLS with BGP only
      • Hub and Spoke VPLS
      • Tunnel L2 Protocols over VPLS
      • Basic H-VPLS
      • H-VPLS with BGP
      • H-VPLS with QinQ
      • H-VPLS with Redundancy
      • VPLS with Routing
      • VPLS MAC Protection
      • Basic E-TREE
      • VPLS with LDP/BGP-AD and XRv RR
      • VPLS with BGP and XRv RR
      • VPLS with Storm Control
    • EVPN
      • Start
      • Topology
      • EVPN VPWS
      • EVPN VPWS Multihomed
      • EVPN VPWS Multihomed Single-Active
      • Basic Single-homed EVPN E-LAN
      • EVPN E-LAN Service Label Allocation
      • EVPN E-LAN Ethernet Tag
      • EVPN E-LAN Multihomed
      • EVPN E-LAN on XRv
      • EVPN IRB
      • EVPN-VPWS Multihomed IOS-XR (All-Active)
      • EVPN-VPWS Multihomed IOS-XR (Port-Active)
      • EVPN-VPWS Multihomed IOS-XR (Single-Active)
      • EVPN-VPWS Multihomed IOS-XR (Non-Bundle)
      • PBB-EVPN (Informational)
    • BGP Multi-Homing (XE)
      • Start
      • Topology
      • Lab1 ECMP
      • Lab2 UCMP
      • Lab3 Backup Path
      • Lab4 Shadow Session
      • Lab5 Shadow RR
      • Lab6 RR with Add-Path
      • Lab7 MPLS + Add Path ECMP
      • Lab8 MPLS + Shadow RR
      • Lab9 MPLS + RDs + UCMP
    • BGP Multi-Homing (XR)
      • Start
      • Topology
      • Lab1 ECMP
      • Lab2 UCMP
      • Lab3 Backup Path
      • Lab4 “Shadow Session”
      • Lab5 “Shadow RR”
      • Lab6 RR with Add-Path
      • Lab7 MPLS + Add Path ECMP
      • Lab8 MPLS + “Shadow RR”
      • Lab9 MPLS + RDs + UCMP
      • Lab10 MPLS + Same RD + Add-Path + UCMP
      • Lab11 MPLS + Same RD + Add-Path + Repair Path
    • BGP
      • Start
      • Conditional Advertisement
      • Aggregation and Deaggregation
      • Local AS
      • BGP QoS Policy Propagation
      • Non-Optimal eBGP Routing
      • Multihomed Enterprise Challenge
      • Provider Communities
      • Destination-Based RTBH
      • Destination-Based RTBH (Community-Based)
      • Source-Based RTBH
      • Source-Based RTBH (Community-Based)
      • Multihomed Enterprise Challenge (XRv)
      • Provider Communities (XRv)
      • DMZ Link BW Lab1
      • DMZ Link BW Lab2
      • PIC Edge in the Global Table
      • PIC Edge Troubleshooting
      • PIC Edge for VPNv4
      • AIGP
      • AIGP Translation
      • Cost-Community (iBGP)
      • Cost-Community (confed eBGP)
      • Destination-Based RTBH (VRF Provider-triggered)
      • Destination-Based RTBH (VRF CE-triggered)
      • Source-Based RTBH (VRF Provider-triggered)
      • Flowspec (Global IPv4/6PE)
      • Flowspec (VRF)
      • Flowspec (Global IPv4/6PE w/ Redirect)
      • Flowspec (Global IPv4/6PE w/ Redirect) T-Shoot
      • Flowspec (VRF w/ Redirect)
      • Flowspec (Global IPv4/6PE w/ CE Advertisement)
    • Intra-AS L3VPN
      • Start
      • Partitioned RRs
      • Partitioned RRs with IOS-XR
      • RT Filter
      • Non-Optimal Multi-Homed Routing
      • Troubleshoot #1 (BGP)
      • Troubleshoot #2 (OSPF)
      • Troubleshoot #3 (OSPF)
      • Troubleshoot #4 (OSPF Inter-AS)
      • VRF to Global Internet Access (IOS-XE)
      • VRF to Global Internet Access (IOS-XR)
    • Inter-AS L3VPN
      • Start
      • Inter-AS Option A
      • Inter-AS Option B
      • Inter-AS Option C
      • Inter-AS Option AB (D)
      • CSC
      • CSC with Option AB (D)
      • Inter-AS Option C - iBGP LU
      • Inter-AS Option B w/ RT Rewrite
      • Inter-AS Option C w/ RT Rewrite
      • Inter-AS Option A Multi-Homed
      • Inter-AS Option B Multi-Homed
      • Inter-AS Option C Multi-Homed
    • Russo Inter-AS
      • Start
      • Topology
      • Option A L3NNI
      • Option A L2NNI
      • Option A mVPN
      • Option B L3NNI
      • Option B mVPN
      • Option C L3NNI
      • Option C L3NNI w/ L2VPN
      • Option C mVPN
    • BGP RPKI
      • Start
      • RPKI on IOS-XE (Enabling the feature)
      • RPKI on IOS-XE (Validation)
      • RPKI on IOS-XR (Enabling the feature)
      • Enable SSH in Routinator
      • RPKI on IOS-XR (Validation)
      • RPKI on IOS-XR (RPKI Routes)
      • RPKI on IOS-XR (VRF)
      • RPKI iBGP Mesh (No Signaling)
      • RPKI iBGP Mesh (iBGP Signaling)
    • NAT
      • Start
      • Egress PE NAT44
      • NAT44 within an INET VRF
      • Internet Reachability between VRFs
      • CGNAT
      • NAT64 Stateful
      • NAT64 Stateful w/ Static NAT
      • NAT64 Stateless
      • MAP-T BR
    • BFD
      • Start
      • Topology
      • OSPF Hellos
      • ISIS Hellos
      • BGP Keepalives
      • PIM Hellos
      • Basic BFD for all protocols
      • BFD Asymmetric Timers
      • BFD Templates
      • BFD Tshoot #1
      • BFD for Static Routes
      • BFD Multi-Hop
      • BFD for VPNv4 Static Routes
      • BFD for VPNv6 Static Routes
      • BFD for Pseudowires
    • QoS
      • Start
      • QoS on IOS-XE
      • Advanced QoS on IOS-XE Pt. 1
      • Advanced QoS on IOS-XE Pt. 2
      • MPLS QoS Design
      • Notes - QoS on IOS-XR
    • NSO
      • Start
      • Basic NSO Usage
      • Basic NSO Template Service
      • Advanced NSO Template Service
      • Advanced NSO Template Service #2
      • NSO Template vs. Template Service
      • NSO API using Python
      • NSO API using Python #2
      • NSO API using Python #3
      • Using a NETCONF NED
      • Python Service
      • Nano Services
    • MDT
      • Start
      • MDT Server Setup
      • Basic Dial-Out
      • Filtering Data using XPATH
      • Finding the correct YANG model
      • Finding the correct YANG model #2
      • Event-Driven MDT
      • Basic Dial-In using gNMI
      • Dial-Out with TLS
      • Dial-In with TLS
      • Dial-In with two-way TLS
    • App-Hosting
      • Start
      • Lab - iperf3 Docker Container
      • Notes - LXC Container
      • Notes - Native Applications
      • Notes - Process Scripts
    • ZTP
      • Notes - Classic ZTP
      • Notes - Secure ZTP
    • L2 Connectivity Notes
      • 802.1ad (Q-in-Q)
      • MST-AG
      • MC-LAG
      • G.8032
    • Ethernet OAM
      • Start
      • Topology
      • CFM
      • y1731
      • Notes - y1564
    • Security
      • Start
      • Notes - Security ACLs
      • Notes - Hybrid ACLs
      • Notes - MPP (IOS-XR)
      • Notes - MPP (IOS-XE)
      • Notes - CoPP (IOS-XE)
      • Notes - LPTS (IOS-XR)
      • Notes - WAN MACsec White Paper
      • Notes - WAN MACsec Config Guide
      • Notes - AAA
      • Notes - uRPF
      • Notes - VTY lines (IOS-XR)
      • Lab - uRPF
      • Lab - MPP
      • Lab - AAA (IOS-XE)
      • Lab - AAA (IOS-XR)
      • Lab - CoPP and LPTS
    • Assurance
      • Start
      • Notes - Syslog on IOS-XE
      • Notes - Syslog on IOS-XR
      • Notes - SNMP Traps
      • Syslog (IOS-XR)
      • RMON
      • Netflow (IOS-XE)
      • Netflow (IOS-XR)
Powered by GitBook
On this page
  • Answer
  • Explanation
  • Service Carving for Port-Active
  • How do remote PEs know which PE is active?
  1. Labs
  2. EVPN

EVPN-VPWS Multihomed IOS-XR (Port-Active)

PreviousEVPN-VPWS Multihomed IOS-XR (All-Active)NextEVPN-VPWS Multihomed IOS-XR (Single-Active)

Last updated 3 months ago

Load multi.service.init.cfg

configure
load multi.service.init.cfg
commit replace
y

The CEs now have two subinterfaces: BE1.10 and BE1.20.

  • Configure the PEs so that only one port in the bundle is active at a time.

  • For PE1-PE2, force PE1 to be standby.

  • For PE3-PE4, allow the natural DF election to happen.

  • The standby PE for PE3-PE4 should bring the bundle down instead of using an LACP OoS (out of service) signal.

  • Configure two separate VPWS services, one per VLAN.

Answer

#PE1, PE2
int Gi0/0/0/1
 no shut
 bundle id 1 mode active
!
int be1
 lacp system mac 0000.1111.2222
!
int be1.10 l2transport
 encap dot1q 10
 rewrite ingress tag pop 1 symmetric
!
int be1.20 l2transport
 encap dot1q 20
 rewrite ingress tag pop 1 symmetric
!
l2vpn xconnect group VPWS
 p2p 10
  int be1.10
  neighbor evpn evi 10 service 10
 p2p 20
  int be1.20
  neighbor evpn evi 20 service 20

#PE1
evpn
 interface Bundle-Ether1
  ethernet-segment
   identifier type 0 12.12.12.12.12.12.12.12.12
   load-balancing-mode port-active
   service-carving preference-based
    weight 50

#PE2
evpn
 interface Bundle-Ether1
  ethernet-segment
   identifier type 0 12.12.12.12.12.12.12.12.12
   load-balancing-mode port-active
   service-carving preference-based
    weight 100

#PE3, PE4
int Gi0/0/0/1
 no shut
 bundle id 2 mode active
!
int be2
 lacp system mac 0000.3333.4444
!
int be2.10 l2transport
 encap dot1q 10
 rewrite ingress tag pop 1 symmetric
!
int be2.20 l2transport
 encap dot1q 20
 rewrite ingress tag pop 1 symmetric
!
l2vpn xconnect group VPWS
 p2p 10
  int be2.10
  neighbor evpn evi 10 service 10
 p2p 20
  int be2.20
  neighbor evpn evi 20 service 20
!
evpn
 interface Bundle-Ether2
  ethernet-segment
   identifier type 0 34.34.34.34.34.34.34.34.34
   load-balancing-mode port-active
  !
  access-signal bundle-down

Explanation

There are three types of EVPN multi-homing redundancy modes:

  • All-Active

    • The links in the bundle are all active. The DF election is used to prevent duplication of BUM traffic for a bridged EVPN service.

  • Single-Active

    • Only one link in the bundle is active but on a per-service basis. This gives some load balancing to the bundle, as service X uses link 1 and service Y uses link 2. There is still redundancy, as if link 1 is lost, service X and Y use link 2.

  • Port-Active

    • Only one link in the bundle is used for the ESI in general. All services only use one link.

Port-Active is useful is situations in which you need to do accounting for billing on one PE. You can know that all traffic will always use one single interface. Additionally, port-active can be useful when you specifically want one link to always be standby, because it might have higher latency or some other less desirable trait.

To configure the ESI as port-active, all PEs participating in the ESI define the load-balancing-method as port-active:

evpn
 interface Bundle-Ether1
  ethernet-segment
   load-balancing-mode port-active

The process of electing a PE as primary and all other PEs as standby is called “service carving.” For port-active, this election is not on a per-service basis, it is instead on a per-ESI basis. Left at the defaults, the PEs use a formula to determine which PE is active. We can see that PE3 and PE4 elected PE3 as the primary forwarder for the ESI.

From PE3 (using show evpn ethernet-segment detail):

From PE4:

This election is essentially random, because the modulo result of the formula means that a PE is determined to be primary simply based on whether the RID is higher or lower than the other PEs.

Also notice that the access signal mode has been changed to bundle down instead of OoS. On CE2, we see that the link to PE4 is defaulted:

Service Carving for Port-Active

Let’s now look at the service carving configuration for PE1 and PE2 which allows us to control which link is placed in active and which links are standby.

There are two ways to configure service carving for an ESI. First, we can specify whether the PE should be active or standby for a list of EVIs. Each EVI represents a service.

evpn
 interface Bundle-Ether1
  ethernet-segment
   service-carving manual
    primary 10-100 secondary 101-200

The above configuration is not applicable to port-active mode though, because with port-active we need to bring the interface down in the bundle. It wouldn’t be possible to bring the interface down on a per-service basis. So instead we use the following configuration:

evpn
 interface Bundle-Ether1
  ethernet-segment
   service-carving preference-based
    weight 50

The higher weight is better. Only the PE with the highest weight will place its link in active. All other PEs (more than two PEs can belong to an ESI) will place their link in standby.

The weight is signaled in the type 4 route for the DF election. We see that PE1’s weight is 50:

PE2’s weight is 100:

Note above that the 2 after DF Election indicates the load-balancing-method.

  • 0 = All-Active

  • 1 = Single-Active

  • 2 = Port-Active

PE1 sees that PE2’s weight is higher, so it places its link in LACP OoS:

Notice above that the preference weight is present under the Peering Details section. (0x32 is 50 and 0x64 is 100).

If we change PE1 to have a higher weight than PE2, PE1 will become active and PE2 will place its interface in standby. Currently, we see on the CE that 0/0/0/2 is active:

#PE1
evpn
 interface Bundle-Ether1
  ethernet-segment
   service-carving preference-based
    weight 150

Now 0/0/0/1 is active:

In summary, port-active allows for a simple way to only use one link in the bundle at a given time. The standby links are ready to take over in case the primary link goes down. This provides for a deterministic way to know which link the traffic is taking. Currently, all traffic is deterministically flowing through CE1-PE1-PE3-CE2.

How do remote PEs know which PE is active?

The standby PE still advertises a type 1 route for the VPWS. I’ve changed PE1’s weight back to 50, so now PE2 is active. On PE3, we see that it only uses PE1 as a backup path. (Indicated by the exclamation point).

In the EVPN L2 extcommunity, the active PE uses 0x02, and the standby PE uses 0x01.

If I change back to all-active on PE1 and PE2, both PEs use value 0x02:

So, value 0x02 means “active” and value 0x01 means “standby.”