The article only summary config and test client just now. Will include more info later.

Version: 661

Platform: NCS-5501-SE

Client:  twampy , for the new version, please check original Github: https://github.com/nokia/twampy

NCS 5501 config:

RP/0/RP0/CPU0:test#sh run ipsla 
Fri Jan 25 23:33:41.467 UTC
ipsla
 responder
  twamp
  !
  twamp-light test-session 1
   local-ip 6.6.6.6 local-port 862 remote-ip 100.100.200.200 remote-port 123 vrf default
  !
 !
 server twamp
 !
!

Client

[root@localhost opt]# ./twampy.py controller 6.6.6.6
===============================================================================
Direction         Min         Max         Avg          Jitter     Loss
-------------------------------------------------------------------------------
  Outbound:      480.0min    480.0min    480.0min        36us      0.0%
  Inbound:            0us         0us         0us         0us      0.0%
  Roundtrip:        159us       477us       287us        79us      0.0%
-------------------------------------------------------------------------------
                                                    Jitter Algorithm [RFC1889]
===============================================================================

[root@localhost opt]# 
[root@localhost opt]# 
[root@localhost opt]# 
[root@localhost opt]# ./twampy.py sender 6.6.6.6:862 100.100.200.200:123 
===============================================================================
Direction         Min         Max         Avg          Jitter     Loss
-------------------------------------------------------------------------------
  Outbound:      480.0min    480.0min    480.0min        40us      0.0%
  Inbound:            0us         0us         0us         0us      0.0%
  Roundtrip:        126us       456us       252us        59us      0.0%
-------------------------------------------------------------------------------
                                                    Jitter Algorithm [RFC1889]
===============================================================================

在早期的XR版本是不支持SLA和静态路由联动的，在4.2.1中，已经可以支持了。但需要安装MGBL PIE，下面是9k 4.2.1中SLA的相应配置，配置跟IOS下的差别不大。如果schedule operation不生效，可以重配下。关于更多SLA的相关信息，可以参考我之前的文章《关于IP SLA及与EEM联动的探讨》

2019-8-8 update: NCS5500 workable as follow config too

RP/0/RSP1/CPU0:A9K-1#sh configuration running-config ipsla
ipsla
operation 1
  type icmp echo
   timeout 1000
   source address 192.168.12.2
   destination address 192.168.12.1
   frequency 5
  !
!
schedule operation 1
  start-time now
  life forever

RP/0/RSP1/CPU0:A9K-1#sh configuration running-config track
track 1
type rtr 1 reachability
delay up 10
delay down 3

RP/0/RSP1/CPU0:A9K-1#sh configuration running-config router static
router static
address-family ipv4 unicast
  22.22.22.22/32 192.168.12.1 track 1

根据上篇文章分析的第一种方法到底行不行呢？
经过测试，确实可以规避原丢一个包就启动EEM的问题。
但有个问题，因为要新增一个sla，如777，且其状态为pending，即只有在17丢三个包的情况下才启动777。

有如下两种情况：

1、线路已经开通时，这时配置如上命令时，因17无法连续丢3个包，导致777始终不能启动，导致track17的状态始终为down，最终导致不管丢多少包都不能启动EEM。（想想为什么？）

规避措施：配置完如上命令时需要shut上端或下端端口30s（因每10s探测一次），这时777才能启动，然后再做no shut操作，track17状态才能变为up，才能在专线中断的情况下正常启动EEM。所以在已经开通的线路配置如上命令时都要中断主用线路最少30s。

2、线路尚未开通时，这时需要在配置完如上命令最少30s才能开通此MSTP线路，否则同样会有如上问题。
完整阅读

SLA简介

SLA (Service-Level Agreement)简单的理解，就是测量一些网络性能参数，在超过一些门限值时，结合track或者EEM它可以触发一些操作。例如：
1. 监控下一跳的可达性，如果不可达了, 则让某一静态路由失效
2. 监控领居的接口地址，如果连续三次不可达, 则将端口shutdown

SLA 应用实例

如果客户的线路质量不好，又无法改善时，我们需要一种方法来：当线路质量达到一定阀值时，直接reset端口，用重置链路来改善。
那么我们如何达到这种需求呢，这时SLA就登场了，那么如何部署SLA呢？

分析第一种方法

完整阅读

在上一篇文章中《 关于IP SLA及与EEM联动的探讨<2> 》，我们发现了第一种解决方案有问题，那么如何才能规避这种问题？或者说如何顺利满足要求呢？
其实在track中有非常方便的方法实现客户的要求，如下所示。

Config：

ip sla monitor 17
 type echo protocol ipIcmpEcho 12.1.1.2
 timeout 3000
 frequency 10
ip sla monitor schedule 17 life forever start-time now
!
track 1 rtr 17
 delay down 30
<---用这个可以很简单的实现客户的需求
!
 完整阅读