~开学以来看了一遍的MPLS-TE，只是说说它的概述啦
1．SPF机制及其和CSPF的区别
2．可以使用多重路径选项,会按照偏好的顺序依次进行尝试,
一个接着一个,按照LSP的优先级大小来使用,如果优先级相同,则采用带宽需求.
3．RSVP是贯穿MPLS-TE始终的一种资源预留协议
4．MPLS-TE RSVP的几种消息及其运用，相对与传统的RSVP，它增加了传递标签的功能
5．MPLS-TE的隧道都是单向的，所以如果要做双向的策略或者是备份，还是负载均衡，都要在两边执行相应的命令。
6．区间隧道的使用
7．使用自动路由沿隧道转发流量
8．负载分担
不会在IGP和TE隧道之间进行负载分担
隧道之间的负载分担
对隧道尾端后面的节点的负载分担（这时候可以在IGP和TE隧道之间进行负载分担）
9．在配置负载分担的时候，可以随意的把隧道带宽设置成2，2，4 或者是90，90，180，这没有什么区别，Router都会同等对待，但是如果设置成20：20：30 化简的结果就是1：1：1.5，出现了1.5，这是不允许的，把1.5四舍五入到2，最后得到的流量分担计数为1：1：2
10．IGP的metric和MPLS-TE的隧道Metric使用先后的区别
11．可以用命令手动改变MPLS-TE的隧道Metric
vxr15(config-if)#tunnel mpls traffic-eng autoroute metric ?
<1-4294967295> Set tunnel metric for autoroutes
absolute Set metric for all autoroutes over tunnel,只有ISIS支持这条命令，在OSPF网络上配置这条命令会被忽略
relative Adjust tunnel metric for autoroutes relative to IGP，设置相对于IGP Metric的MPLS-TE的隧道Metric值。
12．基于MPLS-TE的QOS
有3种隧道模式：
统一模式（uniform）：在加入标签的时候，向上拷贝DSCP/EXP;在弹出标签的时候，把移除的EXP向下拷贝到IP分组和MPLS（如果有堆栈）
短管道模式（short-pipe）：在MPLS2MPLS出栈情况下，受到的EXP向下传播，所以使用拿一个EXP确定PHB的问题没有意义，在MPLS2MPLS出栈的情况下，根据标签栈被移除后的IP分组的DSCP确定PHB
管道模式（pipe）:在管道模式的MPLS2IP链路上的PHB是根据移除的EXP进行选择的，而不是根据刚刚露出的DSCP值进行选择，分组底层的DSCP没有被改变，MPLS2IP路径在出口链路排队中并不考虑DSCP
13．MPLS-TE的保护模式和建立多路径选项的区别
建立多路径选项不是保护的概念，因为在失效前没有重新计算或者建立备份资源，配置多重路径选项仅仅是影响基本LSP重路由的一种方式。除非在失效前已经建立了备份资源，否则就没有快速保护。
14．MPLS-TE的保护有路径保护 链路保护和节点保护
15．什么是快速重路由
• FRR allows for temporarily routing around a failed link or node while the head-end may re-optimize the entire LSP
– re-routing under 50ms
– scalable (must support lots of LSPs)
• Controlled by the routers at ends of a failed link
– link protection is configured on a per link basis
– Session_Attribute’s Flag 0x01 allows the use of Link Protection for the signalled LSP
• Uses nested LSPs (stack of labels)
– original LSP nested within link protection LSP
FRR现在只能支持单区域?
DiffServ and LSP Reoptimization
1.为了优化带宽使用, 备份隧道might配置成0kbps
2.虽然backbone 常常没有拥塞情况出现,在re-routing期间,某些local 拥塞还是会出现
3.使用区分服务来解决短时间的拥塞
4.使用LSP 重优化来解决长时间的拥塞
5.备份隧道不能使用受保护的L1/L2/L3 links
6.使用WANDL (loaded with both L3 and L1/2 拓扑)为备份隧道计算最佳路径 作为静态的备份隧道下载到路由器上
16．局部保护的术语表PLR(局部修理点)，MP(汇合点)，NHOP(下一跳路由器),NNHOP（下下一跳路由器）
17．链路保护使用NHOP备份链路，节点保护使用NNHOP备份链路
18．在做备份链路的时候，要保证备份链路不能经过被保护链路的节点，可以用显式路径来确认或者式排除路径来排除声明
19．备份链路的起点和终点必须和被保护链路的起点和终点相同
20．链路备份的原理就是在保护链路失效的情况下，备份链路的起点会在进入备份链路的任何分组（包括原来要从被保护链路发送的标签包，这时候要先压入保护链路的标签值）压入下游映射的标签值，这里使用多层标签栈，在相对与保护链路终点的次末跳的时候弹出这个标签，恢复成原来要在保护链路收到的标签值，实现了透明保护。
LSPs 是单向的,所以如果也配置了反向的保护,相同的保护必须的相反的方向实施
例子：
在受保护隧道没有down的情况下,12008c希望接收到的是33的标签包,当受保护链路down掉后,12008a会在进入备份隧道的任何分组(包括mpls标签包和普通的标签包)中加入标签38,离开12008a发往12008b的分组的标签[38,33],接着12800b根据顶部标签38进行交换,现在离开12800b的分组标签为[35,33],因为12008b用标签35替换掉顶部标签38.当分组到达128008d时,就执行PHP,移除顶部标签35,分组进入12008c时只有一个标签33,从主隧道的标签交换可以知道,12008c受到标签为33的分组后执行PHP,然后转发到7200c
7200a#traceroute 12.12.12.12
Type escape sequence to abort.
Tracing the route to 12.12.12.12
1 10.0.3.5 [MPLS: Label 16 Exp 0] 0 msec 0 msec 0 msec
2 10.0.11.10 [MPLS: Labels 38/33 Exp 0] 0 msec 0 msec 4 msec
3 10.0.9.16 [MPLS: Labels 35/33 Exp 0] 0 msec 0 msec 0 msec
4 10.0.7.11 [MPLS: Label 33 Exp 0] 0 msec 0 msec 0 msec
5 10.0.17.12 4 msec * 0 msec
21．MPLS-TE的保护模式好比远程接入中备份接口的概念（mpls traffic-eng backup-path Tunnel1），不过这里的备份链路的状态是Ready，
12008a#show mpls traffic-eng fast-reroute database
Tunnel head fast reroute information:
Prefix Tunnel In-label Out intf/label FRR intf/label Status
LSP midpoint frr information:
LSP identifier In-label Out intf/label FRR intf/label Status
4.4.4.4 1 [1520] 16 PO1/0:33 Tu1:33 ready
在保护链路被启用的时候：
12008a#show mpls traffic-eng fast-reroute database
Tunnel head fast reroute information:
Prefix Tunnel In-label Out intf/label FRR intf/label Status
LSP midpoint frr information:
LSP identifier In-label Out intf/label FRR intf/label Status
4.4.4.4 1 [1520] 16 PO1/0:33 Tu1:33 active
配置案例
interface Tunnel1000
ip unnumbered Loopback0
tunnel destination R4
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng priority 7 7
tunnel mpls traffic-eng bandwidth 800
tunnel mpls traffic-eng path-option 1
explicit name backuppath1
ip explicit-path name backuppath1 enable
next-address R6
next-address R7
next-address R4
在配置了要被保护链路的Router的debug信息里面可以看到，这时候Router会告知下游的路由器，这条LSP要被保护：
7200a#debug ip rsvp path detail
*Oct 16 14:40:57.124: SESSION_ATTRIBUTE type 7 length 24:
*Oct 16 14:40:57.124: Setup Prio: 7, Holding Prio: 7
*Oct 16 14:40:57.124: Flags: Local Prot desired, Label Recording, SE Style
*Oct 16 14:40:57.124: Session Name: 7200a_t1
标记 | 描述 |
Local Prot desired | Router会告知下游的路由器，这条LSP要被保护（链路或者是节点保护） |
Label Recording | 不用与链路保护，但是用于节点保护 |
SE Style | 和在配置 tunnel mpls traffic-eng fast-reroute 前一样 |
22．MPLS-TE 保护模式中的失效检测
（1针对特定物理层的失效检测机制，如SONET,ATM SONET没有这个功能：pos ais-shut，命令使得当这个接口需要做管理性的shutdown的时候，不必通过比如点到点链路，PPP,HDLC的Keepalive超时机制来发现接口失效，它会发送一个线性告警指示信号（Line Alarm Indication Signal (LAIs)。
Usual PoS alarm detection
PoS driver optimisation to interrupt RP in < 1ms
Expected call to net_cstate(idb, UP/DOWN) identifying the DOWN state of the protected int to start our protection action.
RP updates the master TFIB (replace a swap by a swap-push)
< 1ms
Master TFIB change notified to the linecards
< 1ms
（2点到点链路，PPP,HDLC的Keepalive
（3）RSVP的hello扩展
检测非POS接口上的链路失效
全局和基于接口的RSVP Hello扩展的配置
12008a(config)#ip rsvp signalling hello
12008a(config)#interface pos 1/0
12008a(config-if)#ip rsvp signalling hello ?
missed-acks missed Hello Acks which triggers neighbor down
refresh-interval Time between sending Hello Requests, msec.
<cr>
12008a(config-if)#ip rsvp signalling hello missed-acks ?
<2-10> Hello missed
23．失效后的信令过程
当LSP中的一条链路失效时，失效链路的上游节点会向经过这条失效链路的LSP首端发送一个Patherr信号
没有局部保护的Patherr信息，当LSP的首端收到上述的错误后，首端会把隧道接口关闭，然后尝试为LSP重新寻找一条新的路径，首端会忽略在失效链路周围可能会有可用的局部保护这一事实，结果，通过这条LSP的浏览都如同进入黑洞般丢失了，直到LSP被重新路由。
错误码 | 24 | 路由问题 |
错误值 | 3 | 无到达目的地的可用路由 |
7200a#debug ip rsvp path detail
*Oct 16 12:54:09.469: RSVP: version:1 flags:0000 type:PERR cksum:0000 ttl:25
*Oct 16 12:54:09.469: SESSION type 7 length 16:
*Oct 16 12:54:09.469: Tun Dest 12.12.12.12 Tun ID 1 Ext Tun ID 4.4.4.4
*Oct 16 12:54:09.469: ERROR_SPEC type 1 length 12:
*Oct 16 12:54:09.469: Error Node: 10.0.3.5
*Oct 16 12:54:09.469: Error Code: 24 (Routing Problem)
*Oct 16 12:54:09.469: Error Value: 0x5 (No route available toward destination)
局部保护的Patherr信息，这时候会告诉LSP的首端，在失效链路周围有可用的局部保护，这条路径也许不是到达目的地的最理想的路径，如果还有其他可用的路径，可以使用它，这也叫做出发了重新优化。
当LSP的首端收到这样的消息时，它就知道了不需要停止使用主LSP，只不过在它重路由之前，这条LSP使用了一条非最优路径，首端有机会可以随时为LSP选择新的路由，保护措施所带来的是：在首端找到一条合适的可选的端到端路径之前的这段时间内，流量仍然是沿着备份隧道传输的。收到通知25/3的首端会尝试为隧道计算和建立一条新的路径，在收到新路径的保留消息后，原路径的标签会被新标签取代，知道这时原LSP才会拆除，这样就获得 中断前建立（make-before-break）的机制，而且有助于最大限度的减少分组丢失，如果首端不能为当前被保护的LSP找到一条新路径，这条路径不允许LSP脱离一条失效的链路，或者说只有沿着那条失效的链路才可能满足LSP必要的带宽，只要保护隧道到位，被保护LSP就会一直有效，并且一直发送流量，而首端会周期性地尝试为隧道发现可用的新路径。LSP是被RSVP中的Path消息和Resv消息中的SESSION和SENDER_TEMPLATE对象的组合所标识的，SENDER_TEMPLATE对象是由PLR来更新的，所以现在发送者的IPV4地址包括了PLR的ip地址而不是首端的IP地址，这样做使得尾段认为这条Path消息来自于某个新的发送者，但是仍然属于一个回话。
错误码 | 25 | 通知 |
错误值 | 3 | 隧道局部修复 |
7200a#debug ip rsvp path detail
*Oct 17 08:20:45.420: RSVP: version:1 flags:0000 type:PERR cksum:0000 ttl:255 eserved:0 length:132
*Oct 17 08:20:45.420: SESSION type 7 length 16:
*Oct 17 08:20:45.420: Tun Dest 12.12.12.12 Tun ID 1 Ext Tun ID 4.4.4.4
*Oct 17 08:20:45.420: ERROR_SPEC type 1 length 12:
*Oct 17 08:20:45.420: Error Node: 10.0.3.5
*Oct 17 08:20:45.420: Error Code: 25 (Notify)
*Oct 17 08:20:45.420: Error Value: 0x3 (Tunnel locally repaired)
*Oct 17 08:20:45.420: SENDER_TEMPLATE type 7 length 12:
*Oct 17 08:20:45.420: Tun Sender: 4.4.4.4, LSP ID: 1520.
24. 命令tunnel mpls traffic-eng path-option preference [dynamic | explicit [identifier
identifier | name name]] {lockdown}
关键字 | 说明 |
tunnel mpls traffic-eng path-optionpreference | 定义了隧道的Path-option，preference 的范围是从1 到1000. 按照优先权从低到高尝试不同的Path-option值，在使用多重路径的时候，来标识不同的优先级 |
dynamic | 告诉路由器应该计算满足所配置的隧道约束条件的最佳路径，如带宽和亲和位. |
explicit | 允许定义一条隧道使用的穿越网络的显式路径（单独配置）。这条显式路径也必须匹配所配置的隧道约束，在通告路径前，隧道首端要确认这条显式路径满足的约束条件 |
identifieridentifier | name name | 当显式路径建立的时候，路径被赋予了名字或者数字编号。这个选项定义了使用哪一条路径 |
lockdown | 配置lockdown 防止TE隧道被周期性的重新优化 |
25．隧道的重新优化
（1） 定期重优化
mpls traffic-eng tunnels reoptimize timers frequency 0-604800. 0-604800 (in seconds) 默认是每小时进行一次重优化。
（2） 手工重新优化
mpls traffic-eng reoptimize [tunnel-name]
（3） 事件驱动的重优化
mpls traffic-eng reoptimize events link-up26.高级保护问题
27.只有链路状态路由协议才能用于mpls-te(te信息的泛洪/需要整个网络的信息)
28.Stunnel <= Snetwork bw
29. 发展策略
0. Select a non critical area first
1. Initial collection of a Traffic Matrix
-TMS
-full-mesh of 0-kbps LSPs
2. Adjust BW constraint
95% percentile
Tackling Interface Congestion
under-subscribe a link (ip rsvp ban 100000 on an OC3)
inflate the LSPs
Trade-off: congestion avoidance vs link efficiency
WANDL can make sure all LSPs will be routed
Emergency: manually redirect traffic with explicit routes
3. Periodic update of the LSPs bandwidth
daily, weekly (cron job)
avoid changing bw requirements of all LSPs at the same time
4. Offline CBR
optimize the LSP placement: BW*routing metric
let the largest LSP take the best path
one by one, starting with highest priority LSPs, and according to BW demands for same priority
offline path configured as first path option
30.
1) 启用CEF
2) 配置IGP, RSVP
3) configure TE tunnels around congested links
- one IGP tunnel, one or more explicit-path tunnels
4) turn up tunnels one at a time via ‘autoroute announce’
5) add BW requirements to tunnels
Tunnel BW ratio is important.
31.
Step1: 链路失效检测
O(depends on L2/L1)
Step2a: IGP reaction (ISIS
可以通过Step1的方法或者是通过IGP hello超时 (ISIS默认是30s)
下面就是ISIS的计时器啦
[每5s (默认)生成一个新的LSP , 在改变LSPDB 之前5.5s (default)进行不间断,连续的SPF.下一次的SPF可以只在10s后进行,泛洪时间 (LSP are paced (16ms for first LSP, 33ms between LSPs, depend also on link speed)]
一旦更新了RIB,接着就是更新CEF表
The head-end finally computes the new topology and finds out that some established LSPs are affected; it schedules a re-optimisation for them
Step2b: RSVP signalization
rsvp path states with the failed intf and send tear to head-end
Step2: Either stepA or stepB alarms the head-end
Step3: 重优化
在每个节点进行dijkstra 计算(SPF ): O(0.5)ms
RSVP signalisation time to instal re-routed tunnel
convergence in the order of several seconds (at least).
Fine Tune the IGP convergence
through adequate tuning, ISIS
Several tunnels in parallel with load-balancing
if combined with the IGP convergence, the path resilience could be brought to around 2-3s
One end-2-end tunnel in parallel but in backup mode
feature under development (Fast Path Protection)
32.隧道属性
l 带宽
l 建立优先级和抢占优先级(详见MPLS-TE RSVP.doc 文档)
l 资源类亲和力(结合MPLS-TE RSVP.doc)
资源亲和力属性(resource class affinity) 提供了一种通过管理性包括或者排除网络中特定的链路来应用路径选择策略的方法.资源类亲和属性包含了一个32位的资源亲和力(resource affinity)属性和一个32位的资源类掩码(resource class mask),资源亲和力属性指出在路径计算过程中是否包括或排除特定的链路.每条链路都具有一个资源类属性,除非明确确定,否则默认值都是0x00000000.资源类掩码指出了资源类链路属性中有意义的位.
资源类,资源类掩码,资源类亲和力和关系如下:
资源类&资源类掩码==资源类亲和力
&:逻辑运算符and
==等于
TE隧道路径选择中包含或排除链路的策略
链路的资源类属性 | TE隧道的资料类亲和力 | 在可能的TE隧道路径中包含或排除链路的策略 | |
1 | 资源类掩码 | 资源亲和力 |
|
0 | 1 | 1 | 明确包含 |
0 | 1 | 0 | 明确排除 |
1或0 | 0 | 0 | 无所谓 |
l 路径选择次序(多路径选项)(path select order)
l 适用性(adaptability) :当出现比当前TE隧道路径更好的路径时,是否需要重新优化已有的TE隧道.
l 弹性(resilience)
