Introduction The Cisco EPN system incorporates a network architecture designed to consolidate multiples services on a single Multiprotocol Label Switching (MPLS) transport network. This network is designed primarily based on Application Engineered Routing (AER), to optionally co-exist with the traditional MPLS technology. The L2VPN / L3VPN service programmability is achieved with NSO, while ensuring the transport programmability using the XTC. The detailed transport design considerations can be found in the EPN5.0 transport guides.   Why we chose NSO? NSO provides a highly customizable framework which adhers to industry drive to have YANG based service abstraction. Also, it provides l ogically centralized network services, t ransaction integrity and  Multi-platform support which empowers our customers with with robust and agile configuration management solution. We are leveraging the NSO ecosystem capabilities of High availability, RBAC etc.   EPN5.0 NSO services function pack: EPN5.0 NSO FP is intended to be a blueprint to help service providers and enterprise customers implement multitude of L2VPN / L3VPN services. Some of the key design considerations were:   a. MPLS VPN services oblivious of Transport network (MPLS or segment routing) b. One functional pack for multitute of MPLS VPN services c. Cohessive service provisioing methodology across multiple service types d. Highly extensible and modular design e. Deployable for both brownfield and green field SP deployments f. Support EPN deployments of IOS-XR and IOS-XE nodes with CLI NED's (as most field deployed releases don't support NETCONF) g. Y.1564 based Service assurance for services terminated on IOS-XE nodes (using inherent capabilities) h. Demonstrate SR transport programmability using XTC.   Latest functional pack release (5.0) supports following functionality:  A. Services terminated on IOS-XE edge devices (Core / aggregation based on IOS-XR):     a. VPWS (with LDP signaling)     b. VPWS (with no-signaling)     c. VPWS EVPN     d. VPLS (with LDP signaling)     e. VPLS (with BGP-AD signaling)     f. VPLS (with LDP signaling), termination on L2 ring     g. VPLS (with  BPG-AD signaling), termination on L2 ring     h. L3VPN with service termination on L2 Ring     i. L3VPN     j. L3VPN-PWHE (PW terminated on IOS-XR)     k. H-VPLS (VPLS ldp-signalling)     l. H-VPLS (VPLS bgp-ad)   B. Services terminated on IOS-XR edge devices (Core / aggregation based on IOS-XR):     a. VPWS (with LDP signaling)     b. VPLS (with LDP signaling)     c. L3VPN     d. PBB-EVPN   Please refer to the "EPN Service Orchestration user guide" for YANG model and the detailed configuration samples.    Package content:  EPN5.0 NSO service consists of YANG model(s) and python mapping logic for all the MPLS VPN scenarios listed above. These can be augmented / customized for specific customer needs.   YANG service model:  This defines the attributes of the service, for example, a Layer-2 VPN service might be defined with virtual circuit id, service identifiers, and interface names. This YANG model renders the NSO CLI and Web-based User Interface (UI). The EPN5.0 YANG models are structured to provide logical modeling of service layer topology over the underlying transport topology. Here is a representative workflow for service creation where one chooses: EPN 5.0 Service Type Service Signaling type (e.g, LDP for VPWS) Service End Point Types and associated endpoint parameters: U-PE / N-PE U-PE association with N-PE (in case of say H-VPLS etc.) Unique Service instance ID The service end points can be dynamically added or removed up to their minimum number (e.g, VPWS service requires minimum of two end points) There are some tacit assumptions on what service parameters will be used e.g, there is support for service access with dot1Q but configuration option for QinQ is planned for next release. EPN 5.0 uses the innate Y.1564 capability of IOS-XE devices for service validation of L2 / L3 services.   Mapping to the device configuration: This allows the required settings to be configured on the devices when a service is created. The EPN Orchestration framework uses Python for service logic and XML for parameter mapping. Please refer to the Orchestration guide for details of Python functions, their parameters and corresponding XML templates.   Functional pack augmentation: The package can be augmented to support additional parameters and support new functionality based on the customer engagement needs. We would appreciate if you can share following details for the high level scoping: a. Customer / opportunity details b. Customer use case list and current service configuration samples / nuances c . Underlying transport network (MPLS/Segment routing; Access / Aggregation / Core design etc.) d. North (NSO CLI / Web GUI / NETCONF etc.) and Southbound interfaces (CLI / NETCONF NED) e. Intergration with external service assurance devices   Detailed Steps: VPWS with LDP Signaling   Virtual Private Wire Service (VPWS) allows two L2VPN Provider Edge Nodes to tunnel the L2VPN traffic over MPLS cloud. The two AC’s connecting at each L2VPN PE are linked by Pseudowire over the MPLS cloud. Each PE needs to have a MPLS label in order to reach the loopback of the remote PE. The label can be learned by Segment routing or LDP. Note: This section provides detailed steps for only one of the service and configuration (via NSO) for the remaining services follows a similar approach.   Configuration Steps Pre-requisites: The network elements (NEs) have been added to the NSO and the configuration sync has been done with the NSO. Step 1: Choose service type admin@ncs(config)# services epn5_0 ? Possible completions:   h-vpls  l3vpn  l3vpn-pwhe  pbb-evpn-vpws  range  vpls  vpws   Step 2: Set the Unique Service Name admin@ncs(config)# services epn5_0 vpws ? % No entries found Possible completions:   Unique service Name admin@ncs(config)# services epn5_0 vpws NCS1251   Step 3:  Set the service specific generic parameters (VPWS signaling type in below example) admin@ncs(config-epn5_0-vpws/NCS1251)# vpws-sig ? Possible completions:   evpn  ldp-sig  no-sig admin@ncs(config-epn5_0-vpws/NCS1251)# vpws-sig ldp-sig   Step 4: Configure service end point (Note: VPWS service requires two end points)   Step 4a: Provide Unique End point numeric identifier (suggest to start from numeric 1) admin@ncs(config-epn5_0-vpws/NCS1251)# endpoint ? Possible completions:   Endpoint identifier  range admin@ncs(config-epn5_0-vpws/NCS1251)# endpoint 1   Step 4b: Choose the NE from the list service end points (this list is extracted from the NE’s existing in the NSO configuration)   admin@ncs(config-epn5_0-vpws/NCS1251)# endpoint 1 ? Possible completions:   AGG-0909-ASR9K   AGG-1003-ASR903  AGG-1004-ASR903  AGG-3003-ASR9K      AGG-3004-ASR9K     AGG-4003-ASR903  AGG-4004-ASR903  AGG-4007-ASR903  CN-ASBR-0008-ASR9K  CN-P-0001-ASR9K    CSG-1102-ASR920  CSG-1103-ASR920  CSG-1104-ASR920  CSG-3102-ASR920     CSG-3103-ASR920    FAN-5303-ASR920  PAN-5606-ASR903  PAN-5607-ASR903  admin@ncs(config-epn5_0-vpws/NCS1251)# endpoint 1 FAN-5303-ASR920   Step 4c: Choose the relevant PE role for the end point for this service admin@ncs(config-epn5_0-vpws/NCS1251)# endpoint 1 FAN-5303-ASR920 pe-role ? Possible completions:   n-pe  u-pe admin@ncs(config-epn5_0-vpws/NCS1251)# endpoint 1 FAN-5303-ASR920 pe-role u-pe   Step 4d: Choose the interface Type and provide interface-number to terminate the service admin@ncs(config-epn5_0-vpws/NCS1251)# endpoint 1 FAN-5303-ASR920 pe-role u-pe if-type Possible completions:   GigabitEthernet  Loopback  PW-Ether  TenGigabitEthernet admin@ncs(config-epn5_0-vpws/NCS1251)# endpoint 1 FAN-5303-ASR920 pe-role u-pe if-type GigabitEthernet if-num ?    Possible completions:   <string> admin@ncs(config-epn5_0-vpws/NCS1251)# endpoint 1 FAN-5303-ASR920 pe-role u-pe if-type GigabitEthernet if-num 0/0/2   Step 4e: Provide Instance-id for the service admin@ncs(config-epn5_0-vpws/NCS1251)# endpoint 1 FAN-5303-ASR920 pe-role u-pe if-type GigabitEthernet if-num 0/0/2 inst-id ?   Possible completions:   <int, 1 .. 4000> admin@ncs(config-epn5_0-vpws/NCS1251)# endpoint 1 FAN-5303-ASR920 pe-role u-pe if-type GigabitEthernet if-num 0/0/2 inst-id 1251   Step 4f: Choose the Service end interface parameters (L2 interface encapsulation type and vlan-id) admin@ncs(config-epn5_0-vpws/NCS1251)# endpoint 1 FAN-5303-ASR920 pe-role u-pe if-type GigabitEthernet if-num 0/0/2 inst-id 1251 encap ? Possible completions:   dot1q  untagged admin@ncs(config-epn5_0-vpws/NCS1251)# endpoint 1 FAN-5303-ASR920 pe-role u-pe if-type GigabitEthernet if-num 0/0/2 inst-id 1251 encap dot1q vlan-id ?   Possible completions:   <int, 1 .. 4000> admin@ncs(config-epn5_0-vpws/NCS1251)# endpoint 1 FAN-5303-ASR920 pe-role u-pe if-type GigabitEthernet if-num 0/0/2 inst-id 1251 encap dot1q vlan-id 1251 Note: Currently there is no check for the VLAN number (if it is allowed on the node or not) Step 5: Repeat Sub-steps for Step 4 for additional end points. (for VPWS service we need exactly two end points; For VPLS / L3VPN, we can have more than two end points) Step 6: Commit the configuration.   Final NSO configuration CLI’s for VPWS with LDP Signaling: Here is summary of all the steps done in Section 6.1.1 services epn5_0 vpws NCS1251 vpws-sig ldp-sig endpoint 1 FAN-5303-ASR920 pe-role u-pe if-type GigabitEthernet if-num 0/0/2 inst-id 1251 encap dot1q vlan-id 1251 endpoint 2 PAN-5607-ASR903 pe-role u-pe if-type GigabitEthernet if-num 0/4/2 inst-id 1251 encap dot1q vlan-id 1251   Native configuration created by NSO: Below is the configuration pushed to the Node in its native format (e.g, IOS-XR or IOS-XE) native {     device {         name FAN-5303-ASR920         data ethernet evc NCS1251              !              interface GigabitEthernet0/0/2               service instance 1251 ethernet NCS1251                encapsulation dot1q 1251                rewrite ingress tag pop 1 symmetric               exit              exit              l2vpn xconnect context NCS1251               interworking ethernet               member GigabitEthernet0/0/2 service-instance 1251               member 100.56.7.0 12510 encapsulation mpls              !     }     device {         name PAN-5607-ASR903         data ethernet evc NCS1251              !              interface GigabitEthernet0/4/2               service instance 1251 ethernet NCS1251                encapsulation dot1q 1251                rewrite ingress tag pop 1 symmetric               exit              exit              l2vpn xconnect context NCS1251               interworking ethernet               member GigabitEthernet0/4/2 service-instance 1251               member 100.53.3.0 12510 encapsulation mpls              !     } }   Show configuration for service:   admin@ncs(config)# show full-configuration services epn5_0 vpws NCS1251 services epn5_0 vpws NCS1251  vpws-sig ldp-sig  endpoint 1 FAN-5303-ASR920   pe-role u-pe   if-type GigabitEthernet   if-num  0/0/2   inst-id 1251   encap   dot1q   vlan-id 1251   l2vpn-xc    rem-pe-lpbk 100.56.7.0   !  !  endpoint 2 PAN-5607-ASR903   pe-role u-pe   if-type GigabitEthernet   if-num  0/4/2   inst-id 1251   encap   dot1q   vlan-id 1251   l2vpn-xc    rem-pe-lpbk 100.53.3.0   !  ! !   Service assurance using NSO (Applicable only for IOS-XE PE’s for VPWS service):   EPN 5.0 services on terminated on IOS-XE devices can be validated out-of-service to assess the proper configuration and performance prior to customer notification and delivery. EPN50 infrastructure leverages the inherent traffic generator and loopback capability on the IOS-XE devices. Note: The traffic generation steps have been pre-defined as 100,200,300,400 and 500Kbps with test duration of 30 seconds. Step 1: Choose the Traffic Generator PE (IOS-XE node resident), remote loopback PE and the Service Performance Type (Ethernet for L2 service).  Enable ip sla and commit the configuration change. Note: The node selection is filtered for the specific service instance.   admin@ncs(config-epn5_0-vpws/NCS1251)# serv-act-y1564 admin@ncs(config-serv-act-y1564)# tgen-pe ? Possible completions:   FAN-5303-ASR920  PAN-5607-ASR903 admin@ncs(config-serv-act-y1564)# tgen-pe FAN-5303-ASR920 ?       Possible completions:   ip-sla  lpbk-pe  serv-perf-type  <cr> admin@ncs(config-serv-act-y1564)# tgen-pe FAN-5303-ASR920 lpbk-pe ? Possible completions:   PAN-5607-ASR903 admin@ncs(config-serv-act-y1564)# tgen-pe FAN-5303-ASR920 lpbk-pe PAN-5607-ASR903 admin@ncs(config-serv-act-y1564)# serv-perf-type ? Possible completions:   ethernet  ip admin@ncs(config-serv-act-y1564)# serv-perf-type ethernet admin@ncs(config-serv-act-y1564)# ip-sla enable admin@ncs(config-serv-act-y1564)# commit Commit complete.   Step 2: Enable traffic internal loopback from Destination PE (the loopback is active for 300 seconds) Note: No commit is required to enable the internal loopback admin@ncs(config-epn5_0-vpws/NCS1251)# ip-sla-remote-lpbk   Value for 'internal' [disable,enable]: enable result   This is an intrusive loopback and the packets matched with the service will not  be able to pass through. Continue? (yes/[no]): yes PAN-5607-ASR903#   Step 3: Start the traffic generator and commit the configuration.   admin@ncs(config-epn5_0-vpws/NCS1251)# serv-act-y1564 ip-sla-tgen enable admin@ncs(config-serv-act-y1564)# commit   Note: The ‘ip-sla enable’ state shows that the service-activation configuration is done. admin@ncs(config)# show full-configuration services epn5_0 vpws NCS1251 services epn5_0 vpws NCS1251  vpws-sig ldp-sig  serv-act-y1564   ip-sla         enable   tgen-pe        FAN-5303-ASR920   lpbk-pe        PAN-5607-ASR903   serv-perf-type ethernet  !  endpoint 1 FAN-5303-ASR920   pe-role u-pe   if-type GigabitEthernet   if-num  0/0/2   inst-id 1251   encap   dot1q   vlan-id 1251   l2vpn-xc    rem-pe-lpbk 100.56.7.0   !  !  endpoint 2 PAN-5607-ASR903   pe-role u-pe   if-type GigabitEthernet   if-num  0/4/2   inst-id 1251   encap   dot1q   vlan-id 1251   l2vpn-xc    rem-pe-lpbk 100.53.3.0   !  ! !     Step 4: Check the ip-sla statistics using the EPN5.0 NSO CLI. (any ios-cmd “<actual command>”). Note:  This command is executed on the Traffic Generator PE. Use the specific service instance id (e.g., 1251 in above config) to get details. Here is sample output for test in progress.  This test sends traffic in 5 steps (from 100Kbps to 500Kbps) for 30 seconds each and measures Frame Loss,  Round Trip Duration and the Frame Receive Deviation for the Tgen Tx packets that are received back on the TGEN PE. Interim result when test is still on: admin@ncs(config-epn5_0-vpws/NCS1251)# any ios-cmd "show ip sla statistics 1251" result IPSLAs Latest Operation Statistics   IPSLA operation id: 1251 Type of operation: Ethernet Service Performance Test mode: Two-way Measurement Steps Tested (kbps): 100 200 300 400 500 Test duration: 30 seconds   Latest measurement:  *13:45:42.034 UTC Wed Jan 25 2017 Latest return code:  OK   Overall Throughput: In Progress   Step 1 (100 kbps): Stats: IR(kbps)  FL          FLR      Avail    FTD Min/Avg/Max      FDV Min/Avg/Max 95        0           0.00%    100.00%  2498.36ms/2417.01ms/2426.27ms  2.72us/9.26ms/65.86ms  Tx Packets: 1392  Tx Bytes: 356352 Rx Packets: 1392  Rx Bytes: 381408 Step Duration: 30 seconds   Step 2 (200 kbps): Stats: IR(kbps)  FL          FLR      Avail    FTD Min/Avg/Max      FDV Min/Avg/Max 190       0           0.00%    100.00%  57.02ms/4275.33ms/4279.98ms  2.64us/4.66ms/33.72ms  Tx Packets: 2781  Tx Bytes: 711936 Rx Packets: 2781  Rx Bytes: 761994 Step Duration: 30 seconds   Step 3 (300 kbps): Stats: IR(kbps)  FL          FLR      Avail    FTD Min/Avg/Max      FDV Min/Avg/Max 285       0           0.00%    100.00%  1046.32ms/2843.73ms/2846.82ms  2.72us/3.09ms/21.86ms  Tx Packets: 2640  Tx Bytes: 675840 Rx Packets: 2640  Rx Bytes: 723360 Step Duration: 18 seconds   Step 4 (400 kbps): Step 5 (500 kbps):     FAN-5303-ASR920#   Final result when the test done (All five statistics bins are available):   admin@ncs(config-epn5_0-vpws/NCS1251)# any ios-cmd "show ip sla statistics 1251" result IPSLAs Latest Operation Statistics   IPSLA operation id: 1251 Type of operation: Ethernet Service Performance Test mode: Two-way Measurement Steps Tested (kbps): 100 200 300 400 500 Test duration: 30 seconds   Latest measurement:  *13:46:55.824 UTC Wed Jan 25 2017 Latest return code:  OK   Overall Throughput: 490 kbps   Step 1 (100 kbps): Stats: IR(kbps)  FL          FLR      Avail    FTD Min/Avg/Max      FDV Min/Avg/Max 95        0           0.00%    100.00%  2498.36ms/2417.01ms/2426.27ms  2.72us/9.26ms/65.86ms  Tx Packets: 1392  Tx Bytes: 356352 Rx Packets: 1392  Rx Bytes: 381408 Step Duration: 30 seconds   Step 2 (200 kbps): Stats: IR(kbps)  FL          FLR      Avail    FTD Min/Avg/Max      FDV Min/Avg/Max 190       0           0.00%    100.00%  57.02ms/4275.33ms/4279.98ms  2.64us/4.66ms/33.72ms  Tx Packets: 2781  Tx Bytes: 711936 Rx Packets: 2781  Rx Bytes: 761994 Step Duration: 30 seconds   Step 3 (300 kbps): Stats: IR(kbps)  FL          FLR      Avail    FTD Min/Avg/Max      FDV Min/Avg/Max 285       0           0.00%    100.00%  1046.32ms/971.33ms/974.41ms  2.72us/3.09ms/21.93ms  Tx Packets: 4170  Tx Bytes: 1067520 Rx Packets: 4170  Rx Bytes: 1142580 Step Duration: 30 seconds   Step 4 (400 kbps): Stats: IR(kbps)  FL          FLR      Avail    FTD Min/Avg/Max      FDV Min/Avg/Max 395       0           0.00%    100.00%  2020.95ms/1943.99ms/1946.22ms  2.72us/2.23ms/15.57ms  Tx Packets: 5790  Tx Bytes: 1482240 Rx Packets: 5790  Rx Bytes: 1586460 Step Duration: 30 seconds   Step 5 (500 kbps): Stats: IR(kbps)  FL          FLR      Avail    FTD Min/Avg/Max      FDV Min/Avg/Max 490       0           0.00%    100.00%  3991.43ms/3915.34ms/3917.14ms  2.64us/1.79ms/12.55ms  Tx Packets: 7179  Tx Bytes: 1837824 Rx Packets: 7179  Rx Bytes: 1967046 Step Duration: 30 seconds       FAN-5303-ASR920#   Step 5: Disable the internal loopback (if it test duration has been less than 300 sec) admin@ncs(config-epn5_0-vpws/NCS1251)# ip-sla-remote-lpbk internal disable   Note: If the traffic internal loopback function has already timed out the result would be: admin@ncs(config-epn5_0-vpws/NCS1251)# ip-sla-remote-lpbk internal disable result Can not find the corresponding session 1 on GigabitEthernet0/4/2 PAN-5607-ASR903#   Step 6: Disable traffic generation admin@ncs(config-epn5_0-vpws/NCS1251)# serv-act-y1564 ip-sla-tgen disable admin@ncs(config-serv-act-y1564)# commit Commit complete.   Step 7: Disable the ip-sla to revert the configuration to the service active state admin@ncs(config-epn5_0-vpws/NCS1251)# serv-act-y1564 ip-sla disable admin@ncs(config-serv-act-y1564)# commit Commit complete.   Confirm that the ip-sla has been disabled with the below show command.   admin@ncs(config)# show full-configuration services epn5_0 vpws NCS1251 services epn5_0 vpws NCS1251  vpws-sig ldp-sig  serv-act-y1564   ip-sla         disable   tgen-pe        FAN-5303-ASR920   lpbk-pe        PAN-5607-ASR903   serv-perf-type ethernet  !  endpoint 1 FAN-5303-ASR920   pe-role u-pe   if-type GigabitEthernet   if-num  0/0/2   inst-id 1251   encap   dot1q   vlan-id 1251   l2vpn-xc    rem-pe-lpbk 100.56.7.0   !  !  endpoint 2 PAN-5607-ASR903   pe-role u-pe   if-type GigabitEthernet   if-num  0/4/2   inst-id 1251   encap   dot1q   vlan-id 1251   l2vpn-xc    rem-pe-lpbk 100.53.3.0   !  ! !   Removing a service using NSO (Applicable only to services created with NSO):   admin@ncs(config)# no services epn5_0 vpws NCS1251 admin@ncs(config)# commit Commit complete.   ... View more

Objective: Gracefully divert traffic out of the ASR9K node prior to software upgrade. This can be done by changing the routing protocol configuration e.g: a. BGP : "Shutdown" the neighbors / neighbor groups b. ISIS : "Set the overload bit" and "max-link-metric" on per ISIS instance. Automated Solution: This document shows how to use EEM script to automate the node isolation / restoration by parsing the node configuration. This script is agnostic of node specific configuration. The script reads the 'running-config' and creates the new intended configuration. The diff of the two configs is shown to the user. The user has to explicitly provide an intent to commit the configuration.   Setup Pre-requisites: a. Linux / Mac host (Python 2.7) b. Telnet access to the node (for python script to do initial router setup) c . SCP access to the IOS-XR node (to copy the EEM script)   Files: Download GIR_v3.zip and unzip it. The folder should have following two files a. EEM Script: GIR_TCL_v3.tcl b. Initial Router Setup Script: gir_node_env_cfg_v3.py Note: These scripts have been tried mainly on 6.1.3 release. Initial Router Setup: The initial setup is done by running the python script: python gir_node_env_cfg_v3.py Following initial configuration is done automatically by running the EEM script. Please refer to the section 'Running the Initial Setup script'   for detailed steps.   a. Create the EEM policy file location config t event manager directory user policy disk0: commit exit b. Copy the script to the Node Active RSP c. Create EEM user, AAA authorization local and Enable the policy config t username event_manager_user group root-system group cisco-support aaa authorization eventmanager default local aaa authorization commands eem-method none vty-pool eem 100 105 line-template eem-template line template eem-template authorization commands eem-method ! commit event manager policy  GIR_TCL_v3 .tcl username event_manager_user commit   Note: The current version of Initial router setup script copies the EEM script to active RP only. If there are redundant RP's, please copy the script to the standby RP. Running the Initial Router Setup script: The initial setup script arguments:  list of target IOS-XR nodes IP addresses python gir_node_env_cfg_v3.py <ip_address_node_1> <ip_address_node_2> Sample run: python gir_node_env_cfg_v3.py 172.15.0.100 172.15.0.109 Note: The initial router setup script will prompt for telnet and ssh credentials for each node. Initial Router Setup Script Logs: The script saves the initial and final config of the nodes. The script logs are saved in file: ASR9K_<node_ip_address>_date_time How to determine if the EEM policy was successfully registered? Run the IOS-XR command: "show event manager policy registered" and confirm that the policy is registered. RP/0/RSP0/CPU0:AGG-0908-ASR9K#show event manager policy registered   Fri Aug 4 16:48:12.706 PDT No. Class Type Event Type Trap Time Registered Name 1 script user none Off Fri Aug 4 15:48:10 2017 GIR_TCL_v3.tcl policyname   {GIR_TCL_v3.tcl}   sync {yes} nice 0 queue-priority normal maxrun 20.000 scheduler rp_primary Secu none persist_time: 3600 seconds, username: event_manager_user Optionally, check the 'show logging | i GIr_TCL_v3.tcl' RP/0/RSP0/CPU0:ASR9K#show logging | i GIR_TCL_v3.tcl Fri Aug 4 15:48:16.307 PDT RP/0/RSP0/CPU0:Aug 4 15:48:10.503 : eem_policy_dir[207]: %HA-HA_EM-6-FMPD_POLICY_REG_SUCC : fh_reg_unreg_policy: Policy 'GIR_TCL_v3.tcl'   registered successfully, by user event_manager_user, with persist time 3600 and type 2   Running the GIR EEM Script: The GIR EEM script can be invoked on the IOS-XR active RP by invoking the command: event manager run GIR_TCL_v3.tcl <GIR-Mode> <optional commit> The two parameters are: The GIR mode (mandatory):  "insert" / "remove" User intention to commit the configuration (optional) : commit Note: The initial reference configuration is the current 'running configuration'. Sample CLI's: Audit / Get Diff of config changes to remove the node: event manager run GIR_TCL_v3.tcl remove Remove the node: event manager run GIR_TCL_v3.tcl remove commit   GIR EEM Script Logs: The script saves the node SW version and node initial config on the node's harddisk with filename gir-eem-script-log-<date>.txt file   Sample script run output: RP/0/RSP0/CPU0:ASR9K#event manager run GIR_TCL_v3.tcl remove commit Tue Aug 1 18:38:39.103 PDT GIR Action is : remove ISIS Instances are : {router isis ring9} {router isis ring10} {router isis ring30} BGP AS is: router bgp 100 Neighbor List is: { neighbor 100.9.5.0} { neighbor 100.9.6.0} { neighbor 100.0.12.0} { neighbor 100.0.22.0} { neighbor 100.10.3.0} { neighbor 100.10.4.0} Neighbor Group List is: { neighbor-group SvRR} { neighbor-group RR-Ring9} { neighbor-group RRC-Ring10}   ------------------------------------------------------------- show commit changes diff Tue Aug 1 18:38:51.392 PDT Building configuration... !! IOS XR Configuration 6.1.3 router isis ring9 <- set-overload-bit on-startup 360 +> set-overload-bit + max-link-metric ! router isis ring10 <- set-overload-bit on-startup 360 +> set-overload-bit + max-link-metric ! router isis ring30 <- set-overload-bit on-startup 360 +> set-overload-bit + max-link-metric ! router bgp 100 neighbor-group SvRR + shutdown ! neighbor-group RR-Ring9 + shutdown ! neighbor-group RRC-Ring10 + shutdown ! + neighbor 100.9.5.0 + shutdown ! + neighbor 100.9.6.0 + shutdown ! + neighbor 100.0.12.0 + shutdown ! + neighbor 100.0.22.0 + shutdown ! + neighbor 100.10.3.0 + shutdown ! + neighbor 100.10.4.0 + shutdown ! ! end RP/0/RSP0/CPU0:AGG-0908-ASR9K(config-bgp-nbrgrp)# ------------------------------------------------------------- Proceeding with Commit show config commit changes la$ Tue Aug 1 18:38:52.483 PDT Building configuration... !! IOS XR Configuration 6.1.3 router isis ring9 set-overload-bit max-link-metric ! router isis ring10 set-overload-bit max-link-metric ! router isis ring30 set-overload-bit max-link-metric ! router bgp 100 neighbor-group SvRR shutdown ! neighbor-group RR-Ring9 shutdown ! neighbor-group RRC-Ring10 shutdown ! neighbor 100.9.5.0 shutdown ! neighbor 100.9.6.0 shutdown ! neighbor 100.0.12.0 shutdown ! neighbor 100.0.22.0 shutdown ! neighbor 100.10.3.0 shutdown ! neighbor 100.10.4.0 shutdown ! ! end     Caveat : At times, the EEM script fails to register. Try again and if it still does't work, please re-start the eem server. Here is sample error seen while running EEM script on IOS-XR 6.1.3 RP/0/RSP0/CPU0:ASR9K#show logging | i GIR_TCL_v3.tcl Fri Aug 4 15:48:16.307 PDT RP/0/RSP0/CPU0:Aug 4 15:41:14.934 : eem_policy_dir[207]: %HA-HA_EM-4-FMPD_POLICY_APPLY : Could not apply policy 'GIR_TCL_v3.tcl': 'Embedded Event Manager' detected the 'fatal' condition 'Embedded Event Manager configuration' ... View more

Objective: Gracefully divert traffic out of the ASR9K node prior to software upgrade. This can be done by changing the routing protocol configuration e.g: a. BGP : "Shutdown" the neighbors / neighbor groups b. ISIS : "Set the overload bit" and "max-link-metric" on per ISIS instance. Automated Solution: This document shows how to use EEM script to automate the node isolation / restoration by parsing the node configuration. This script is agnostic of node specific configuration. The script reads the 'running-config' and creates the new intended configuration. The diff of the two configs is shown to the user. The user has to explicitly provide an intent to commit the configuration. Setup Pre-requisites: a. Linux / Mac host (Python 2.7) b. Telnet access to the node (for python script to do initial router setup) c . SCP access to the IOS-XR node (to copy the EEM script) Files: Download GIR_v3.zip and unzip it. The folder should have following two files a. EEM Script: GIR_TCL_v3.tcl b. Initial Router Setup Script: gir_node_env_cfg_v3.py Note: These scripts have been tried mainly on 6.1.3 release. Initial Router Setup: The initial setup is done by running the python script: python gir_node_env_cfg_v3.py Following initial configuration is done automatically by running the EEM script. Please refer to the section 'Running the Initial Setup script' for detailed steps. a. Create the EEM policy file location config t event manager directory user policy disk0: commit exit b. Copy the script to the Node Active RSP c. Create EEM user, AAA authorization local and Enable the policy config t username event_manager_user group root-system group cisco-support aaa authorization eventmanager default local aaa authorization commands eem-method none vty-pool eem 100 105 line-template eem-template line template eem-template authorization commands eem-method ! commit event manager policy  GIR_TCL_v3 .tcl username event_manager_user commit Note: The current version of Initial router setup script copies the EEM script to active RP only. If there are redundant RP's, please copy the script to the standby RP. Running the Initial Router Setup script: The initial setup script arguments:  list of target IOS-XR nodes IP addresses python gir_node_env_cfg_v3.py <ip_address_node_1> <ip_address_node_2> Sample run: python gir_node_env_cfg_v3.py 172.15.0.100 172.15.0.109 Note: The initial router setup script will prompt for telnet and ssh credentials for each node. Initial Router Setup Script Logs: The script saves the initial and final config of the nodes. The script logs are saved in file: ASR9K_<node_ip_address>_date_time How to determine if the EEM policy was successfully registered? Run the IOS-XR command: "show event manager policy registered" and confirm that the policy is registered. RP/0/RSP0/CPU0:AGG-0908-ASR9K#show event manager policy registered Fri Aug 4 16:48:12.706 PDT No. Class Type Event Type Trap Time Registered Name 1 script user none Off Fri Aug 4 15:48:10 2017 GIR_TCL_v3.tcl policyname {GIR_TCL_v3.tcl} sync {yes} nice 0 queue-priority normal maxrun 20.000 scheduler rp_primary Secu none persist_time: 3600 seconds, username: event_manager_user Optionally, check the 'show logging | i GIr_TCL_v3.tcl' RP/0/RSP0/CPU0:ASR9K#show logging | i GIR_TCL_v3.tcl Fri Aug 4 15:48:16.307 PDT RP/0/RSP0/CPU0:Aug 4 15:48:10.503 : eem_policy_dir[207]: %HA-HA_EM-6-FMPD_POLICY_REG_SUCC : fh_reg_unreg_policy: Policy 'GIR_TCL_v3.tcl' registered successfully, by user event_manager_user, with persist time 3600 and type 2 Running the GIR EEM Script: The GIR EEM script can be invoked on the IOS-XR active RP by invoking the command: event manager run GIR_TCL_v3.tcl <GIR-Mode> <optional commit> The two parameters are: The GIR mode (mandatory):  "insert" / "remove" User intention to commit the configuration (optional) : commit Note: The initial reference configuration is the current 'running configuration'. Sample CLI's: Audit / Get Diff of config changes to remove the node: event manager run GIR_TCL_v3.tcl remove Remove the node: event manager run GIR_TCL_v3.tcl remove commit GIR EEM Script Logs: The script saves the node SW version and node initial config on the node's harddisk with filename gir-eem-script-log-<date>.txt file Sample script run output: RP/0/RSP0/CPU0:ASR9K#event manager run GIR_TCL_v3.tcl remove commit Tue Aug 1 18:38:39.103 PDT GIR Action is : remove ISIS Instances are : {router isis ring9} {router isis ring10} {router isis ring30} BGP AS is: router bgp 100 Neighbor List is: { neighbor 100.9.5.0} { neighbor 100.9.6.0} { neighbor 100.0.12.0} { neighbor 100.0.22.0} { neighbor 100.10.3.0} { neighbor 100.10.4.0} Neighbor Group List is: { neighbor-group SvRR} { neighbor-group RR-Ring9} { neighbor-group RRC-Ring10} ------------------------------------------------------------- show commit changes diff Tue Aug 1 18:38:51.392 PDT Building configuration... !! IOS XR Configuration 6.1.3 router isis ring9 <- set-overload-bit on-startup 360 +> set-overload-bit + max-link-metric ! router isis ring10 <- set-overload-bit on-startup 360 +> set-overload-bit + max-link-metric ! router isis ring30 <- set-overload-bit on-startup 360 +> set-overload-bit + max-link-metric ! router bgp 100 neighbor-group SvRR + shutdown ! neighbor-group RR-Ring9 + shutdown ! neighbor-group RRC-Ring10 + shutdown ! + neighbor 100.9.5.0 + shutdown ! + neighbor 100.9.6.0 + shutdown ! + neighbor 100.0.12.0 + shutdown ! + neighbor 100.0.22.0 + shutdown ! + neighbor 100.10.3.0 + shutdown ! + neighbor 100.10.4.0 + shutdown ! ! end RP/0/RSP0/CPU0:AGG-0908-ASR9K(config-bgp-nbrgrp)# ------------------------------------------------------------- Proceeding with Commit show config commit changes la$ Tue Aug 1 18:38:52.483 PDT Building configuration... !! IOS XR Configuration 6.1.3 router isis ring9 set-overload-bit max-link-metric ! router isis ring10 set-overload-bit max-link-metric ! router isis ring30 set-overload-bit max-link-metric ! router bgp 100 neighbor-group SvRR shutdown ! neighbor-group RR-Ring9 shutdown ! neighbor-group RRC-Ring10 shutdown ! neighbor 100.9.5.0 shutdown ! neighbor 100.9.6.0 shutdown ! neighbor 100.0.12.0 shutdown ! neighbor 100.0.22.0 shutdown ! neighbor 100.10.3.0 shutdown ! neighbor 100.10.4.0 shutdown ! ! end Caveat : At times, the EEM script fails to register. Try again and if it still does't work, please re-start the eem server. Here is sample error seen while running EEM script on IOS-XR 6.1.3 RP/0/RSP0/CPU0:ASR9K#show logging | i GIR_TCL_v3.tcl Fri Aug 4 15:48:16.307 PDT RP/0/RSP0/CPU0:Aug 4 15:41:14.934 : eem_policy_dir[207]: %HA-HA_EM-4-FMPD_POLICY_APPLY : Could not apply policy 'GIR_TCL_v3.tcl': 'Embedded Event Manager' detected the 'fatal' condition 'Embedded Event Manager configuration' ... View more