mpls
ip危机:
90年代中期，路由器技术发展远远滞后于网络的发展速度。当时路由查找算法使用最长匹配原则，必须使用软件查找，而IP本质就是“只关心过程，不注重结果”的“尽力而为”的转发。当时也就出现了，简单的IP技术无法承载网络的未来，基于IP技术的Internet必将在几后之后崩溃。
atm野心：
atm的起初走向了一个极端，以至于定位于完美，它想解决所有IP的问题。但由于它过于复杂的技术实现，且无法与已经广泛应用的IP融合，使atm最终沦为IP链路层协议。
虽然如此，atm还是给以后的协议发展提出了很多有效的技术，大大提高了路由器的转发性能：
1>屏弃了繁琐的路由查找，改为简单快速的标签交换。
2>具有全局意义的路由表改为只有本地意义的标签表。
路由是有全局意义的，标签是只有本地意义的。
mpls（MultiProtocol Label Switch)
充分吸取了atm的精华，也认识到atm失败的原因，它没有定位于一定要取代谁，只是甘愿作IP的承载层，并将自己定位于2.5层。它支持多种协议，并不只是IP协议，从而避免得到atm一样的结果。
一个协议的包大小定义是很有讲究的，它不能设置得太大，否则对链路的负载太大；也不能设置得太小，否则影响可扩展性。
Case Study:mpls报头结构
MPLS包头有32Bit，其中有：
20Bit用作标签(Label)，作用类似于IP地址。可以说它是完全够用的，不会像IPv4一样不够用， 因为MPLS标签它是只有本地意义的，一个路由器有2^20次方(104万左右)条标签路由，可能说完全够用了，因为现在的BGP路由表也才十几万而已。
3Bit的EXP,协议中没有明确，通常用作COS
1Bit的S，用于标识是否是栈底，表明MPLS的标签是可以嵌套的。路由器检测包的时时候，如果先检测到这个S值为0，说明这不是栈底，以后还是MPLS报头。如果S值为1，说明这是最后一个MPLS包头了，以后的是三层信息。
理论上MPLS可以无限嵌套，但它还是受限于MTU。这些嵌套功能可以简单的实现功能的扩展，一个例子就是MPLS/×××。
8Bit的TTL
Case Study:Terminology
Label（标签）:是一个比较短的，定长的，通常只具有本地局部意义的标识，它通常位于数据链路层封装与第三层数据封装之间，标签通过绑定过程同FEC相映射。
FEC（Forwarding Equivalence Class,转发等价类）: 对于一组报文，处理它的沿涂路由器都用一个相同的动作处理它，那么这就叫作一个FEC。即在转发过程中以等价的方式处理一组数据分组的动作。
LSP（标签交换通道）：一个FEC的数据流，在不同的节点被赋予确定的标签，数据转发按照这些标签进行。数据流所走的路径就是LSP。即在转过程中以FEC动作处理过的分组所走的通路。
LSR（Label Switching Router）：LSR是MPLS网络的核心交换机，它提供标签交换和标签分发功能。
LER（Lable Switching Edge Router):MPLS网络边缘的路由器或交换机，进入到MPLS网络的流量由LER分为不同的FEC，并为这些FEC请求相应的标签。它提供流量分类和标签的映射，标签的移除功能。
在MPLS网络入口处LER（Ingress Router)要变IP转发为标签转发，在MPLS网络出口处LER(Egress Router)要变标签转发为IP转发。
Case Study:MPLS vs. IP 路由/转发方式
IP是hop-by-hop逐跳转发，它在每一条都要进行相应的路由表查询，并进行最长的匹配。
MPLS只是由LER进行相应的查询，并通过FEC分配相应的标签，并建立LSP。LSR只需要进行相应的标签查找，并对应转发就行 了。
Case Study:FEC
不同的目的地址（属于相同的网段）的IP报文，在ingress处被划分为相同的FEC，进而具有相同的标签，这样在LSR处，只需要根据标签做快速的交换即可。而对于传统的IP路由，它在每一跳处实际上都重新做一次FEC。
如果一台路由器对于IP路由和标签交换使用了同样的CACHE功能，由于对于路由来说，在CACHE中只能记录主机路由，条目将十分有限，而标签对应的是FEC，可能是一个网段，从而可以做到很少的条目匹配大量的报文。
FEC缺点：
对于一条FEC来说，沿途所有的设备都必须具有相同的路由（前缀和掩码必须完全相同）才可以建成一条LSP。
也就是，MPLS转发的所有沿途设备不能做路由聚合操作。
Case Study:上下层标识
在以太网报文中，以值0x8847(Unicast)和0x8848(Multicast)来表示承载的是MPLS报文（0x0800是IP报文）。
在PPP中，增加了一种新的NCP：MPLSCP，使用0x8281来标识。
Case Study:LDP(Label Distribution Protocol)
这是一个MPLS动态的生成标签的协议，存在有多种标签生成协议可以实现这种标签的生成与分发，最常用的就是LDP。
LDP既然是一个动态的标签生成协议，它就与一些动态的路由协议有着相同之处：
1>报文
2>邻居自动发现和维护机制
3>一套标签计算算法，用来根据搜集到的信息计算最终结果。
LDP消息：
Discovery(发现消息)：用于通行和维护网络中的LSR的存在。
Session（会话消息）：用于建立，维护和结束LDP对等实体之间的传话连接。
Advertisement(通告消息）：用于创建，改变和删除特定FEC-标签绑定信息。
Notification(通知消息）：用于提供消息通告和差错通知。
LDP会话建立过程：
LSR1 ---------------------------------------------> LSR2
<---------------------------------------------
邻居发现：通过互发HELLO报文（UDP:646/IP:224.0.0.2)
<---------------------------------------------
建立TCP连接：由地址大的一方主动发起（TCP:646)
<---------------------------------------------
初始化session,由master发出初始化消息，并携带协商参数
---------------------------------------------->
由slave检查参数能否接受，如果能则发送初始化消息，并携带协商参数。
并随后发送keepalive消息
<---------------------------------------------
master检查参数能否接受，如果能则发送keepalive消息
---------------------------------------------->
相互收到keepalive消息，会话建立。
期间收到任何差错消息，均关闭会话，断开TCP连接。
LDP State Machine（LDP状态机）：
1>non existent
2>initialized
3>opensent
4>openrec
5>operational
Case Study:标签分配和管理
标记分发方式:
DOD(Downstream On Demand)下游按需标记分发
DU(Downstream Unsolicited)下游自主标记分发
DU标签分发：
1>下游路由器主动跟据自己直连的网络发布布标签映射消息。
2>标签分配方式中也存在水平分割。
3>标签是设备随机自动生成的，16以下为系统保留。
标记控制方式：
Odered：有序方式标记控制
Independent：独立方式标记控制
标签保留方式：
保守方式
自由方式
上游与下游：以数据包传送的路径为基准。
在一条LSP上，沿数据包传送的方向，相邻的LSR分别叫上游LSR（upstream LSR)和下游LSR(downstream LSR)。 下游是路由的始发者。
Case Study:LDP标签保留方式（选择方式）
即我从多个邻居收到到同一目的地的标签时，我怎么选择，使用哪一个标签转发的过程。MPLS与IP处理此问题是一样的,都是优选相应的好的标签/路由。
自由方式（Liberal retention mode)
保留来自邻居的所有发送来的标签
优点：当IP路由收敛，下一跳改变时减少了LSP收敛时间
缺点：需要更多的内存和标签空间。
此为当今比较流行的方式。
保守方式(Conservation retention mode)
只保留来自下一跳邻居的标签，丢弃所有非下一跳邻居发来的标签。
优点：节省内存和标签空间。
缺点：当IP路由收敛，下一跳改变时LSP收敛慢。
Case Study:标签控制方式
有序方式（Odered）标记控制：
除非LSR是路由的始发节点，（即此路由为我的直连路由，或我自己定义的静态路由），否则LSR必须等收到下一跳的标记映射后，才能向上游发出标记映射。为了防止标签LSP中间是中断的，类似于IBGP的同步特性。
此为当今比较流行的标签控制方式。
独立方式（Independent）标记控制：
LSR可以向上游发出标记映射，而不必等待来自LSR下一跳的标记映射消息。但这样就不能保证LSP是完整的。
Case Study:LDP标签分配
采用（DU＋自由＋有序）的标签分配及控制方式：
1>发现自己有直连接口路由时会发送标签
2>标签表中会存在大量的非选中的标签。
3>收到下游到某条路由的标签并且该路由生效（也就是说，本地已经存在该条路由，并且路由的下一跳和标签的下一跳机同）时会发送标签。
注：
1＞如果某个网络中只有部分设备运行MPLS（MPLS域嵌在IP域中），则只会对运行MPLS的设备（MPLS域）的直连路由生成标签，对于其他设备（IP域）始发的路由则不会生成标签。
2＞如果没有标签，对于通过MPLS域的目的地址在IP域的报文如何转发？
在Ingress处，会对到来的数据包进行标签选择，如果没有匹配的标签它也不会将数据包丢弃，它还会进行相应的路由表查找，进行进行相应的转发。
Case Study:标签转发表
注：
1>标签转发表中的IN和OUT，是相对于标签转发而言，不是相对于标签分配的IN和OUT。
2>入标签是我分给别人的，出标签是别人分给我的。
我分配的标签是给别人用的，我不会添加到报文中。
3>对于一台设备的标签转发表（全局标签空间）来说：
（1）所有的入标签｛一定是不同的｝：因为入标签是自己随机分配的，它自己也有相应的分配记录，而且自己需要唯一的识别它进而实施相应的转发。
（2）对于相同的路由（下一跳也相同），出标签｛一定是相同的｝：此时，你的下游路由器在分配标签的时候只会给指定你一个路由一个标签，然后你自己再跟据自己的上游路由器个数，再分配IN标签，但它们都是要发给始发这条路由标签的路由器的，也就是给你分配了一个标签的下游路由器。
（3）对于不同的路由（但下一跳相同），出标签｛一定是不同的｝：下一跳相同说明路由标签由同一个下游路由器分配的，因为下游的这个路由器要针对相应的入标签进行选择进而决定出标签，所以他对每一个路由不会分配相同的标签，否则它就不能进行正确的标签转发了，它就不能区别进入的数据包的下一跳。（此题于第一题相似，只是基于的对相不同）
（4）对于不同的路由（下一跳也不同），出标签｛有可能相同｝：它们是由不同的下游路由器随机分配的，当然有可能不同。
（5）对于同一条路由，入标签和出标签｛没有任何关系，有可能相同｝：因为IN标签是我随机分配的，OUT标签是我的下游路由器随机分配的，它们之间没有任何的关系。
Case Study:倒数第二跳弹出（PHP）
在Egress LSR处，本应该变MPLS转发为 IP路由查找转发，但是他收到的仍旧是含有标签的MPLS报文。按常规，这个报文应该送交MPLS模块处理，而此时MPLS模块不需要标签转发，能做的只是去掉标签，然后移交给IP层。
所以说Egress LSR处理MPLS报文是没有任何意义的，最好能保证收到的就是IP报文，而不是MPLS报文。这就需要Egress LSR的上游（倒数第二跳）就把标签给弹出来。
上游设备如何知道自己是倒数第二跳呢？
可以通过在倒数第一跳为其分配一个特殊的标签来实现（分配一个特殊的标签3，注：16以下的标签都是保留的）。
倒数第一跳如何知道自己是倒数第一跳呢？
如果路由是自己直连发布的话，它自然就是倒数第一跳。
倒数第一跳会因免去处理MPLS标签操作而提高运行效率。
Case Study:路由环路的预防与检测
环路预防：
任何涉及到转发或是路由计算的，都有可能引发路由一路，MPLS也不例外。
但LSP的建立是依赖IP路由的，所以环路的预防也就可以直接交给IP来做，自己无需处理。
环路检测：
MPLS做为2.5层协议，它不能完全依赖于IP做环路预防，它自己也要进行相应的检测，以蔽免IP环路预防处理失败，进而发生环路。
MPLS的环路检测手段就是使用TTL，每经过一次MPLS转发，TTL减一，进而将环路带来的影响降到最小。
注：此处，只MPLS报头中的TTL减一，IP报头的TTL不减一。
因为标签转发过程中，根本就不把数据包给IP层，这样才提高的转发速度，所以IP报头TTL不会减一。
Case Study:MPLS的衰落
因为路由交换设备发展到了硬件转发，使用ASIC，NP等价格也相对低廉的硬件技术可以很简单的实现高速的转发，所以MPLS这种软件的转发手段就体现不出高明来了。
还有MPLS本身也存在着一些不足，最大的一个缺点就是：FEC必须在整个LSP路径上都是一致的，这本身是不符合网络的拓扑结构的。
***
按CE与PE的关系×××可分为：
Overlay ×××
Peer-to-Peer ×××
CE（Custom Edge)：直接与ISP相连的用户设备
PE（Provider Edge Router):指ISP骨干网上的边缘路由器，与CE相连，主要负责×××业务的拉入。
P（Provider Router)：指骨干网上的核心路由器，主要完成路由的快速转发功能。
由于网络的规模的不同，网络中可能不存在P路由器，PE路由器也可能同时是P路由器。
C-Network:用户网络
P-Network:ISP网络
Case Study:Overlay ××× - 隧道建立在CE上
特点：CE与CE之间通过ISP的P-Network建立直连的隧道，并直接传递路由信息，路由协议数据总是在客户设备之间交换，ISP对C-Network一无所知，也不知道你传送的是普通数据还是×××包。典型代表是GRE，IPSec
优点：不同的客户的地址空间可以重叠，保密性，安全性非常好。
缺点：需要客户自己创建并维护×××，通常客户不愿意，也没有这个能力。
注：此时PE与CE之间互联的地址是公网地址。因为ISP只是把你CE看做一个普通上网的用户，只是我们自己知道我们配置的是×××。就与我们普通的ADSL上网是一样的，我们会得到ISP分配的一个公网的IP。
Case Study:Overlay ××× -隧道建立在PE上
特点：在PE上为每一个×××用户建立相应的GRE隧道，路由信息在PE与PE之间传递，公网中的P设备不知道私网的路由信息。
优点：客户把×××的创建及维护完全交给ISP，保密性，安全性比较好。
缺点：不同的×××用户不能共享相同的地址空间，即使可以共享，使用基于接口的策略路由，PE与CE之间的地址，tunnel之间的地址一定不能相同，并且必须使用大量的ACL和策略路由，这也是实际中不具备可行性的。它的可管理性与以后的troubleshooting也都是比较困难的。
Case Study:Overlay ×××的本质
Overlay ×××的本质是一种“静态“的×××，它都是需要自己手工配置的，类似于静态路由，所以他也具有类似静态路由的全部缺陷：
1>所有的配置与部署都需要手工完成，而且具有可扩展性问题，如果某个客户的×××中新增加了一个，则需要完全手工的完成：
（1）在这个新增上建立与所有已存在的N个结点的隧道及相关的路由。
（2）对于已存在的N个结点，需要在每个结点上都建立一个与新增结点之间的隧道及相关的路由。
2>由于是“静态”×××，则无法反应网络的实时变化。
而且，如果隧道建立在CE上，则必须由用户维护; 如果建立在PE上，则又无法解决地址冲突问题。
Case Study:Peer-to-Peer ×××
所有的静态性质的×××都不适合大规模的应用与部署，所以为了解决这个问题，就需要将×××的部署及路由发布变为动态的。Peer-to-Peer是指CE -to-PE,也就是要在CE与PE之间交换私网路由信息，然后由PE将这些私网路由在P-Network中传播（P-Network上运行了某种动态路由协议），这样这些私网路由会自动的传播到其他的PE上。进而可以解决动态性的问题。
由于将要将私网路由泄露到公网上，所以必须严格的控制路由使用，即要确保同一个×××的CE路由器上只有本×××用涉及的SITE的路由。同时也不能使用默认路由，即如果私网路由被网络上不法人得到，它进行对网络的***时，因为没有反回的路由，所以连接就会失败。这种×××的安全性是靠双向的路由来保证的。即如果数据包不是去网×××的其它SITE的话，就过滤掉这个包，或根本不建立相应到其它网络的路由。
通常CE与PE之间运行的路由协议与P-Network上运行的路由协议是不同的，即使相同，也要有很好的路由过滤和选择机制。
Case Study:Peer-to-Peer ××× -共享PE方式
所有的×××用户的CE都连到同一台PE上（如一个城市的×××接入点），PE与不同的CE之间运行不同的路由协议（或者是相同的路由协议的不同进程，比如 OSPF）。路由始发PE将这些路由发布到公网上，在接收端的PE上将这些路由过滤后对就相应的××× SITE发给相应的CE端。
缺点：
1>为了防止连接在同一台PE上的不同CE之间互通，因为两个都是直连的路由，所以它们可以互通，必须在PE上配置大量的ACL。
2>它还是没有解决地址空间重叠的问题。即CE之间不能使用相同重叠的地址块。但大型的企业会直接被分到一块公网IP，这样地址空间重叠的问题就可以解决了。
Case Study:Peer-to-Peer ××× -专用PE方式
为每一个×××单独准备一台PE路由器，PE和CE之间可以运行任意的路由协议，与其他×××无关。PE与P之间运行BGP，并使用路由属性进行相应的过滤。
优点：无需配置任何的ACL了。安全性也有所提高。
缺点：每一个×××用户都需要新增一台专用的PE，代价过于昂贵了。
注：在这里的BGP使用的是EBGP，进而可以减少BGP全连接的代价。主要还是EBGP可以使用私有AS。
在专用PE出口怎样区别一条路由呢，这是不是我专有的××× SITE需要的路由呢? 这就要使用到BGP的community属性，对应在入口配置的community决定哪些路由是关于我专有的××× SITE的，其它的只要过滤就可以了。
Case Study:Peer-to-Peer ×××本质
Peer-to-Peer ×××虽说很好的解决了“静态的问题”但是仍旧有很多局限性：
1>没有使用隧道技术，导致私网路由泄露到公网上，安全性很差，几乎没有体现出×××来。
2>×××的“私有”特性完全靠路由来保证，导致在CE设备上无法配置缺省路由。如果你使用了缺省路由，这种×××的特性就完全没有了，这个SITE就完全就是一个普通的上网站点了。
3>仍旧存在所有的设备无法共享相同的地址空间问题。
如果要确保安全性，则必须使用隧道技术，但那些隧道技术如GRE，IPSec都已被证实其“静态性“，必须手工配置。Peer-to-Peer ×××又不能很好的解决地址空间冲突的问题。所有只靠×××自己的技术是不能解决这些隧道×××技术。
Case Study:×××需要解决的问题
因为×××本身是不能解决这些问题的了，所以需要其它的协议共同来实现，现在主要的问题是：
1>可以提供一种动态建立的隧道技术
2>可以解决不同×××共享相同地址空间的问题
第一个问题可以由MPLS来解决，因为它的LSP就是一种动态的隧道。它不把任何数据转给IP层，中途也不进行任何的修改，所以这种动态隧道的安全性就可以完美的解决。
第二个问题，必须要一种动态的路由协议来解决的，但现有的路由协议没有任何一个可以完美的实现此功能的，所以就需要对现有的协议进行相应的修改，这就要求这些协议有很好的可扩展性。
有扩展性的路由协议只有使用TLV的EIGRP，BGP和ISIS。因此它们可以扩展TLV实现支持一些新的特性。
IS-IS:它最早是OSI用来支持CLNS的协议，对IP的融合也是存在一些问题的。
EIGRP:它是CISCO私有的，而×××是一种开放技术，所以这是不合适的。
BGP:
1>由于×××的扩展，路由数目可能非常大，BGP是唯一支持大量路由的路由协议。
2>BGP是基于TCP来建立连接的，这就可以在不直接相连的路由器间交换信息，这使得P路由器中无须包含×××路由信息
3>BGP可扩展性非常的好，可支持多种属性，任何不了解这些属性的BGP路由器都将它们透明的转发，都将只使用它们了解的属性，不会因为某一属性的不支持，而丢弃整个数据分组。
mp-bgp
Case Study:BGP需要解决的第二个问题 -地址冲突
要想解决地址冲突问题，至少要攻克三个难题:
1＞本地路由冲突问题，即：在同一台PE上如何区分不同×××的相同路由。
2>路由在网络中的传播问题，两条相同的路由，都在网络中传播，对于接收者如何分辨彼此
3>报文的转发问题，即使成功的解决了路由表的冲突，但是当PE接收到一个IP报文时，他又如何知道该发给那个×××？
因为IP报文头中唯一可用的信息就是上的地址。而很多×××中都可能存在这个地址。
解决方案：
1>本地路由冲突问题，可以通过在同一台路由器上创建不同的路由表解决，而不 同的接口可以分属不同的路由表中，这就相当于将一台共享PE模拟成多台专用PE。
2>可以在路由传递过程中为这条路由再添加一个标识，用以区别不同的×××。
3>由于IP报文的格式不可更改，但可以在IP报文之外加上一些信息，由始发的×××打上标记，这样PE在接收报文时就可以根据这个标记进行转发。
Case Study:本地路由冲突解决方案 - VRF
对于本地路由冲突问题，也可以使用ACL，策略路由的方式，ip unnumber,NAT等，但这些方法都不是从根本上问题，而且它们自己也有一些本身的局限性。所以要想彻底解决这个问题，就要在理论上有所突破。
从Peer-to-Peer ×××的专用PE得来的启示，专用路由器方式分工明确，每个PE只保留自己×××的路由，可以很好的解决本地路由冲突。
然而现在的问题是我们只有一个PE，所以就要求在软件上实现这种多个PE的方式，这就是VRF。
VRF（××× Routing & Forwarding Instance,×××路由转发实例）：每一个VRF可以看作一个虚拟的路由器，用于模拟一台专用的PE设备，该虚拟路由器包括3个元素：
1>一张独立的路由表，当然也包括了独立的地址空间。
2>一组归属于这个VRF的接口的集合。
3>一组只用于本VRF的路由协议。
4>一个RD和一组RT规则。
对于每个PE，可以维护一个或多个VRF，同时维护一个公网的路由表（也叫全局路由表），多个VRF实例相互分离独立。
实现VRF并不困难，关键在于如何在PE上使用特定的策略规则来协调各VRF和全局路由表之间的关系。
Case Study:本地路由冲突解决方案/路由传递冲突解决方案 Step1 -RT
专有PE的方式中，我们为了区分不同SITE的×××的路由信息，我们在BGP中分配给它们特定的community，进而实现路由的区分。
这里我们实现VRF用的也是这种方式，只是它叫做RT(Route Target)。
扩展的community有两种格式(type=0x0002或0x0102时表示RT)：
RT的本质：
RT的本质是每个VRF表达自己路由的取舍及需要的路由类型，进而通过它可以实现不同的VRF之间的互通。
它可以解决路由在发送和接收时的冲突。
RT不是一个简单的数字，它通常是一个列表，一种路由属性列表。而且它是做为BGP的一种路由属性。
可以分为两部分：Export Target与Import Target
Export Target表示了我发出的路由属性，Import Target表示了我对哪些路由感兴趣。
SITE-A: 我发送的是红色的路由，我也只接收红色的路由。
SITE-B: 我发送的是红色的路由，我也只接收红色的路由。
SITE-C: 我发送的是黑色的路由，我也只接收黑色的路由。
SITE-D: 我发送的是黑色的路由，我也只接收黑色的路由。
这样，SITE-A与SITE-B中就只有自己和对方的路由，进而两者实现互访。同理SITE-C与SITE-D也一样。这时我们就可以把SITE-A与SITE-B称为×××-A,而把SITE-C与SITE-D称为×××-B。
注：在专有PE方式只存在有P路由器的参与，但VRF中无P路由器参与，只有PE路由器。
Case Study:路由传递冲突问题解决 Step2-RD
因为RT不是与IP前缀放在一起的，如果在路由传递时只按RT来区分×××间的路由就有可能出现问题，特别是:BGP的Route Withdraw报文不携带属性，在这种情况下收到的路由就没有RT了，所有就不能区别不同×××之间的路由。
所以还要在路由传递时再定义一个属性，这就是RD，它的格式与 RT基本相同。
注：可以说RD的作用很小，只在BGP使用withdraw报文时才会用到，尽管如此，它还是一个必须的属性值。
RD是用来防止一台PE接收 到远端PE发来的不同VRF的相同路由时不知所措，而加在路由前面的特殊信息。在PE发布路由时加上此RD，在远端PE接收到路由后，将其放在本地路由表中，用来与后来接收到的路由进行比较。
RD本质：
1>在IPv4地址加上RD之后，就变成了×××-IPv4地址族(Address Family)了。
2>通常建议为每个×××都配置相同的RD，不同的×××配置不同的RD。但实际上只要保证存在相同地址的两个VRF的RD是不同即可，不同的×××可以配置相同的RD，相同的×××也可以配置不同的RD。
3>如果两个VRF中存在相同的地址，则一定要配置不同的RD，而且两个VRF一定不能互访，间接互访也不成。
4>同一台PE上的不同VRF不能配置相同的RD。设备用来防止以后的扩展会引起出现相同的地址在两个VRF中。
5>RD并不会影响不同的VRF之间的路由选择以及×××的形成，这些事情由RT搞定。
6>PE从CE接收的标准路由是IPv4路由，如果需要发豐给其他的PE路由器，才需要为这条路由附加一个RD。
7>×××-IPv4地址仅用于ISP内部，在PE发布路由时添加。在PE接收路由后放在本地路由表中，用来与后接收到的路由进行比较。CE不知道使用的是×××-IPv4地址。
8>在数据包其穿越ISP骨干时，×××数据流量的包头中没有携带×××-IPv4地址。即这些RT/RD只用于路由传递，不用于数据传递。
Case Study:报文转发时的冲突解决方案 -私网标签
理论上讲可以使用RD来实现报文转发时的冲突解决方案，但RD是一个64bit长的字段，有些过大了，这会导致转发效率的降低。所以只需要一个短小，定长的标记即可。
由于公网的隧道已经由MPLS来提供了，而且MPLS支持多层标签的嵌套，这个标记定义成MPLS标签的格式最好不过了。
公网的标签是由LDP来分配的，通常MPLS是不参与私网的分发的，所由以MP-BGP来分配，它与私网的路由一同发布出去。
这个私网Label用来防止一台PE接收 到远端PE发给本地不同的VRF的相同地址的主机时不知所措，而加在报头前而的特殊信息。
Case Study:BGP发布路由时需要携带的信息
一个扩展之后的NLRI（Network Layer Reachability Information)增加了地址族的描述，以及私网label和RD。
对于使用了扩展属性MP_REACH_NLRI的BGP，我们称之为MP-BGP。
bgp/mpls ***
Case Study：CE与PE之间如何交换路由
1>在PE上配置VRF
2>PE维护独立的路由表，包括公网和私网(VRF)路由表
公网路由表：包含全部PE和P路由器之间的路由，由骨干网的IGP产生。
私网路由表：包含本×××用户可达信息的路由和转发表。
3>PE和CE通过标准的EBGP，OSPF，RIP或者静态路由交换路由信息
（1）静态路由，RIP都是标准的协议，但是每个VRF运行不同的实例，相互之间没有干扰。与PE的MP-IBGP之间只是简单的redistribute操作。
（2）EBGP也是普通的EBGP，而不是MP-EBGP，只交换经过PE过滤后的本×××路由。
（3） OSPF则做了很多修改，可以将本SITE的LSA放在BGP的扩展community属性中携带，与远端×××中的OSPF之间交换LSA。每个 SITE中的OSPF都可以存在area 0，而骨干网则可以看作是super area 0。此时的OSPF由两极拓扑（骨干区域＋非骨干区域）变为三级拓扑（超级骨干区域＋骨干区域＋非骨干区域）。
Case Study:VRF路由注入到MP-IBGP
PE路由器需要对一条路由进行几个操作：
1>加上RD（手工配置），变为一条×××-IPv4路由
2>更改下一跳属性为自己（通常是自己的loopback地址），类似于BGP的nexthop-self
3>加上私网标签（敌机自动生成，无需要配置）
4>加上RT属性（手工配置），携带的RT为export属性
5>发送给所有PE邻居
Case Study:MP-iBGP路由注入到VRF
远端PE收到路由后会将×××-v4路由变为Ipv4路由，并且根据本地VRF的import RT属性加入到相应的VRF中，私网标签保留，留做转发时使用。再由本VRF的路由协议引入并转发给相应的CE。
此时的私网标签在进入VRF中时是保留的，为了与以后的路由更新比较，来判断是否是相同的。但路由给CE的时候是没有私网标签的。
Case Study:公网标签分配过程
1>PE和P路由器通过骨干网IGP学习到BGP邻居下一跳的地址
2>通过运行LDP协议，分配标签，建立LSP通道。
3>标签栈用于报文转发，外层标签用来指示如何到达BGP下一跳，内层标签表示报亠的出接口或者属于哪个VRF（属于哪个×××）。
4>MPLS节点转发是基于外层标签，而不管内层标签是多少。
5> 所有的公网标签内的路由信息一般都是PE路由器的Loopback地址。由它将这个路由信息给第二跳P路由器，由它做第二跳标签弹出。一般这个第一跳路由器发送的这个路由信息是以一个特殊的标签3来给第二跳的路由器做为OUT LABEL的，有时也称这个特殊的标签3为implicit-null，它指示第二跳路由器它应该做第二跳标签弹出操作。
Case Study:报文转发 - 从CE到Ingress PE
1>CE将报文发给与其相连的VRF接口，PE在本VRF的路由表中进行查找，得到了该路由的公网下一跳（即：对端PE的loopback地址）和私网标签。
2>在把该报文封装一层私网标签后，在公网的标签转发表中查找下一跳地址，再封装一层公网标签后，交与MPLS转发。
Case Study:Ingress PE -> Egress PE -> CE
1>该报文在公网上沿着LSP转发，并根据途径的每一台设备的标签转发表进行标签交换
2>在倒数第二跳处，将外层的公网标签弹出，交给目的PE设备
3>PE设备根据内层的私网标签判断该报文的出接口和下一跳
4>去掉私网标签后，将报文转发给相应的VRF中的CE
ip危机:
90年代中期，路由器技术发展远远滞后于网络的发展速度。当时路由查找算法使用最长匹配原则，必须使用软件查找，而IP本质就是“只关心过程，不注重结果”的“尽力而为”的转发。当时也就出现了，简单的IP技术无法承载网络的未来，基于IP技术的Internet必将在几后之后崩溃。
atm野心：
atm的起初走向了一个极端，以至于定位于完美，它想解决所有IP的问题。但由于它过于复杂的技术实现，且无法与已经广泛应用的IP融合，使atm最终沦为IP链路层协议。
虽然如此，atm还是给以后的协议发展提出了很多有效的技术，大大提高了路由器的转发性能：
1>屏弃了繁琐的路由查找，改为简单快速的标签交换。
2>具有全局意义的路由表改为只有本地意义的标签表。
路由是有全局意义的，标签是只有本地意义的。
mpls（MultiProtocol Label Switch)
充分吸取了atm的精华，也认识到atm失败的原因，它没有定位于一定要取代谁，只是甘愿作IP的承载层，并将自己定位于2.5层。它支持多种协议，并不只是IP协议，从而避免得到atm一样的结果。
一个协议的包大小定义是很有讲究的，它不能设置得太大，否则对链路的负载太大；也不能设置得太小，否则影响可扩展性。
Case Study:mpls报头结构
MPLS包头有32Bit，其中有：
20Bit用作标签(Label)，作用类似于IP地址。可以说它是完全够用的，不会像IPv4一样不够用， 因为MPLS标签它是只有本地意义的，一个路由器有2^20次方(104万左右)条标签路由，可能说完全够用了，因为现在的BGP路由表也才十几万而已。
3Bit的EXP,协议中没有明确，通常用作COS
1Bit的S，用于标识是否是栈底，表明MPLS的标签是可以嵌套的。路由器检测包的时时候，如果先检测到这个S值为0，说明这不是栈底，以后还是MPLS报头。如果S值为1，说明这是最后一个MPLS包头了，以后的是三层信息。
理论上MPLS可以无限嵌套，但它还是受限于MTU。这些嵌套功能可以简单的实现功能的扩展，一个例子就是MPLS/×××。
8Bit的TTL
|
标签<?XML:NAMESPACE PREFIX = O />
|
CoS
|
S
|
TTL
|
\ /
\ /
|
2
层头部
|
MPLS
头部
|
IP
头部
|
数据
|
|
2
层头部
|
MPLS
头部
|
MPLS
头部
|
IP
头部
|
数据
|
Case Study:Terminology
Label（标签）:是一个比较短的，定长的，通常只具有本地局部意义的标识，它通常位于数据链路层封装与第三层数据封装之间，标签通过绑定过程同FEC相映射。
FEC（Forwarding Equivalence Class,转发等价类）: 对于一组报文，处理它的沿涂路由器都用一个相同的动作处理它，那么这就叫作一个FEC。即在转发过程中以等价的方式处理一组数据分组的动作。
LSP（标签交换通道）：一个FEC的数据流，在不同的节点被赋予确定的标签，数据转发按照这些标签进行。数据流所走的路径就是LSP。即在转过程中以FEC动作处理过的分组所走的通路。
LSR（Label Switching Router）：LSR是MPLS网络的核心交换机，它提供标签交换和标签分发功能。
LER（Lable Switching Edge Router):MPLS网络边缘的路由器或交换机，进入到MPLS网络的流量由LER分为不同的FEC，并为这些FEC请求相应的标签。它提供流量分类和标签的映射，标签的移除功能。
在MPLS网络入口处LER（Ingress Router)要变IP转发为标签转发，在MPLS网络出口处LER(Egress Router)要变标签转发为IP转发。
Case Study:MPLS vs. IP 路由/转发方式
IP是hop-by-hop逐跳转发，它在每一条都要进行相应的路由表查询，并进行最长的匹配。
MPLS只是由LER进行相应的查询，并通过FEC分配相应的标签，并建立LSP。LSR只需要进行相应的标签查找，并对应转发就行 了。
Case Study:FEC
不同的目的地址（属于相同的网段）的IP报文，在ingress处被划分为相同的FEC，进而具有相同的标签，这样在LSR处，只需要根据标签做快速的交换即可。而对于传统的IP路由，它在每一跳处实际上都重新做一次FEC。
如果一台路由器对于IP路由和标签交换使用了同样的CACHE功能，由于对于路由来说，在CACHE中只能记录主机路由，条目将十分有限，而标签对应的是FEC，可能是一个网段，从而可以做到很少的条目匹配大量的报文。
FEC缺点：
对于一条FEC来说，沿途所有的设备都必须具有相同的路由（前缀和掩码必须完全相同）才可以建成一条LSP。
也就是，MPLS转发的所有沿途设备不能做路由聚合操作。
Case Study:上下层标识
在以太网报文中，以值0x8847(Unicast)和0x8848(Multicast)来表示承载的是MPLS报文（0x0800是IP报文）。
在PPP中，增加了一种新的NCP：MPLSCP，使用0x8281来标识。
Case Study:LDP(Label Distribution Protocol)
这是一个MPLS动态的生成标签的协议，存在有多种标签生成协议可以实现这种标签的生成与分发，最常用的就是LDP。
LDP既然是一个动态的标签生成协议，它就与一些动态的路由协议有着相同之处：
1>报文
2>邻居自动发现和维护机制
3>一套标签计算算法，用来根据搜集到的信息计算最终结果。
LDP消息：
Discovery(发现消息)：用于通行和维护网络中的LSR的存在。
Session（会话消息）：用于建立，维护和结束LDP对等实体之间的传话连接。
Advertisement(通告消息）：用于创建，改变和删除特定FEC-标签绑定信息。
Notification(通知消息）：用于提供消息通告和差错通知。
LDP会话建立过程：
LSR1 ---------------------------------------------> LSR2
<---------------------------------------------
邻居发现：通过互发HELLO报文（UDP:646/IP:224.0.0.2)
<---------------------------------------------
建立TCP连接：由地址大的一方主动发起（TCP:646)
<---------------------------------------------
初始化session,由master发出初始化消息，并携带协商参数
---------------------------------------------->
由slave检查参数能否接受，如果能则发送初始化消息，并携带协商参数。
并随后发送keepalive消息
<---------------------------------------------
master检查参数能否接受，如果能则发送keepalive消息
---------------------------------------------->
相互收到keepalive消息，会话建立。
期间收到任何差错消息，均关闭会话，断开TCP连接。
LDP State Machine（LDP状态机）：
1>non existent
2>initialized
3>opensent
4>openrec
5>operational
Case Study:标签分配和管理
标记分发方式:
DOD(Downstream On Demand)下游按需标记分发
DU(Downstream Unsolicited)下游自主标记分发
DU标签分发：
1>下游路由器主动跟据自己直连的网络发布布标签映射消息。
2>标签分配方式中也存在水平分割。
3>标签是设备随机自动生成的，16以下为系统保留。
标记控制方式：
Odered：有序方式标记控制
Independent：独立方式标记控制
标签保留方式：
保守方式
自由方式
上游与下游：以数据包传送的路径为基准。
在一条LSP上，沿数据包传送的方向，相邻的LSR分别叫上游LSR（upstream LSR)和下游LSR(downstream LSR)。 下游是路由的始发者。
Case Study:LDP标签保留方式（选择方式）
即我从多个邻居收到到同一目的地的标签时，我怎么选择，使用哪一个标签转发的过程。MPLS与IP处理此问题是一样的,都是优选相应的好的标签/路由。
自由方式（Liberal retention mode)
保留来自邻居的所有发送来的标签
优点：当IP路由收敛，下一跳改变时减少了LSP收敛时间
缺点：需要更多的内存和标签空间。
此为当今比较流行的方式。
保守方式(Conservation retention mode)
只保留来自下一跳邻居的标签，丢弃所有非下一跳邻居发来的标签。
优点：节省内存和标签空间。
缺点：当IP路由收敛，下一跳改变时LSP收敛慢。
Case Study:标签控制方式
有序方式（Odered）标记控制：
除非LSR是路由的始发节点，（即此路由为我的直连路由，或我自己定义的静态路由），否则LSR必须等收到下一跳的标记映射后，才能向上游发出标记映射。为了防止标签LSP中间是中断的，类似于IBGP的同步特性。
此为当今比较流行的标签控制方式。
独立方式（Independent）标记控制：
LSR可以向上游发出标记映射，而不必等待来自LSR下一跳的标记映射消息。但这样就不能保证LSP是完整的。
Case Study:LDP标签分配
采用（DU＋自由＋有序）的标签分配及控制方式：
1>发现自己有直连接口路由时会发送标签
2>标签表中会存在大量的非选中的标签。
3>收到下游到某条路由的标签并且该路由生效（也就是说，本地已经存在该条路由，并且路由的下一跳和标签的下一跳机同）时会发送标签。
注：
1＞如果某个网络中只有部分设备运行MPLS（MPLS域嵌在IP域中），则只会对运行MPLS的设备（MPLS域）的直连路由生成标签，对于其他设备（IP域）始发的路由则不会生成标签。
2＞如果没有标签，对于通过MPLS域的目的地址在IP域的报文如何转发？
在Ingress处，会对到来的数据包进行标签选择，如果没有匹配的标签它也不会将数据包丢弃，它还会进行相应的路由表查找，进行进行相应的转发。
Case Study:标签转发表
|
interface
|
IN label
|
prefix/mask
|
out interface(nexthop)
|
out label
|
|
s0
|
50
|
10.1.1.0/24
|
eth0(3.3.3.3)
|
80
|
|
s1
|
51
|
10.1.1.0/24
|
eth0(3.3.3.3)
|
80
|
|
s1
|
62
|
70.1.2.0/24
|
eth0(3.3.3.3)
|
52
|
|
s1
|
52
|
20.1.2.0/24
|
eth1(4.4.4.4)
|
52
|
|
s2
|
77
|
30.1.2.0/24
|
s3(5.5.5.5)
|
3(pop)
|
注：
1>标签转发表中的IN和OUT，是相对于标签转发而言，不是相对于标签分配的IN和OUT。
2>入标签是我分给别人的，出标签是别人分给我的。
我分配的标签是给别人用的，我不会添加到报文中。
3>对于一台设备的标签转发表（全局标签空间）来说：
（1）所有的入标签｛一定是不同的｝：因为入标签是自己随机分配的，它自己也有相应的分配记录，而且自己需要唯一的识别它进而实施相应的转发。
（2）对于相同的路由（下一跳也相同），出标签｛一定是相同的｝：此时，你的下游路由器在分配标签的时候只会给指定你一个路由一个标签，然后你自己再跟据自己的上游路由器个数，再分配IN标签，但它们都是要发给始发这条路由标签的路由器的，也就是给你分配了一个标签的下游路由器。
（3）对于不同的路由（但下一跳相同），出标签｛一定是不同的｝：下一跳相同说明路由标签由同一个下游路由器分配的，因为下游的这个路由器要针对相应的入标签进行选择进而决定出标签，所以他对每一个路由不会分配相同的标签，否则它就不能进行正确的标签转发了，它就不能区别进入的数据包的下一跳。（此题于第一题相似，只是基于的对相不同）
（4）对于不同的路由（下一跳也不同），出标签｛有可能相同｝：它们是由不同的下游路由器随机分配的，当然有可能不同。
（5）对于同一条路由，入标签和出标签｛没有任何关系，有可能相同｝：因为IN标签是我随机分配的，OUT标签是我的下游路由器随机分配的，它们之间没有任何的关系。
Case Study:倒数第二跳弹出（PHP）
在Egress LSR处，本应该变MPLS转发为 IP路由查找转发，但是他收到的仍旧是含有标签的MPLS报文。按常规，这个报文应该送交MPLS模块处理，而此时MPLS模块不需要标签转发，能做的只是去掉标签，然后移交给IP层。
所以说Egress LSR处理MPLS报文是没有任何意义的，最好能保证收到的就是IP报文，而不是MPLS报文。这就需要Egress LSR的上游（倒数第二跳）就把标签给弹出来。
上游设备如何知道自己是倒数第二跳呢？
可以通过在倒数第一跳为其分配一个特殊的标签来实现（分配一个特殊的标签3，注：16以下的标签都是保留的）。
倒数第一跳如何知道自己是倒数第一跳呢？
如果路由是自己直连发布的话，它自然就是倒数第一跳。
|
|
标签分配方式（改革前）
|
标签分配方式
（改革后）
|
转发方式（改革前）
|
转发方式（改革后）
|
|
倒数第一跳
|
随机分配
|
分配特定的标签3
|
标签弹出，IP路由转发
|
IP
路由转发
|
|
倒数第二跳
|
随机分配
|
随机分配
|
标签交换
|
标签弹出
|
倒数第一跳会因免去处理MPLS标签操作而提高运行效率。
Case Study:路由环路的预防与检测
环路预防：
任何涉及到转发或是路由计算的，都有可能引发路由一路，MPLS也不例外。
但LSP的建立是依赖IP路由的，所以环路的预防也就可以直接交给IP来做，自己无需处理。
环路检测：
MPLS做为2.5层协议，它不能完全依赖于IP做环路预防，它自己也要进行相应的检测，以蔽免IP环路预防处理失败，进而发生环路。
MPLS的环路检测手段就是使用TTL，每经过一次MPLS转发，TTL减一，进而将环路带来的影响降到最小。
注：此处，只MPLS报头中的TTL减一，IP报头的TTL不减一。
因为标签转发过程中，根本就不把数据包给IP层，这样才提高的转发速度，所以IP报头TTL不会减一。
Case Study:MPLS的衰落
因为路由交换设备发展到了硬件转发，使用ASIC，NP等价格也相对低廉的硬件技术可以很简单的实现高速的转发，所以MPLS这种软件的转发手段就体现不出高明来了。
还有MPLS本身也存在着一些不足，最大的一个缺点就是：FEC必须在整个LSP路径上都是一致的，这本身是不符合网络的拓扑结构的。
***
按CE与PE的关系×××可分为：
Overlay ×××
Peer-to-Peer ×××
CE（Custom Edge)：直接与ISP相连的用户设备
PE（Provider Edge Router):指ISP骨干网上的边缘路由器，与CE相连，主要负责×××业务的拉入。
P（Provider Router)：指骨干网上的核心路由器，主要完成路由的快速转发功能。
由于网络的规模的不同，网络中可能不存在P路由器，PE路由器也可能同时是P路由器。
C-Network:用户网络
P-Network:ISP网络
Case Study:Overlay ××× - 隧道建立在CE上
特点：CE与CE之间通过ISP的P-Network建立直连的隧道，并直接传递路由信息，路由协议数据总是在客户设备之间交换，ISP对C-Network一无所知，也不知道你传送的是普通数据还是×××包。典型代表是GRE，IPSec
优点：不同的客户的地址空间可以重叠，保密性，安全性非常好。
缺点：需要客户自己创建并维护×××，通常客户不愿意，也没有这个能力。
注：此时PE与CE之间互联的地址是公网地址。因为ISP只是把你CE看做一个普通上网的用户，只是我们自己知道我们配置的是×××。就与我们普通的ADSL上网是一样的，我们会得到ISP分配的一个公网的IP。
Case Study:Overlay ××× -隧道建立在PE上
特点：在PE上为每一个×××用户建立相应的GRE隧道，路由信息在PE与PE之间传递，公网中的P设备不知道私网的路由信息。
优点：客户把×××的创建及维护完全交给ISP，保密性，安全性比较好。
缺点：不同的×××用户不能共享相同的地址空间，即使可以共享，使用基于接口的策略路由，PE与CE之间的地址，tunnel之间的地址一定不能相同，并且必须使用大量的ACL和策略路由，这也是实际中不具备可行性的。它的可管理性与以后的troubleshooting也都是比较困难的。
Case Study:Overlay ×××的本质
Overlay ×××的本质是一种“静态“的×××，它都是需要自己手工配置的，类似于静态路由，所以他也具有类似静态路由的全部缺陷：
1>所有的配置与部署都需要手工完成，而且具有可扩展性问题，如果某个客户的×××中新增加了一个，则需要完全手工的完成：
（1）在这个新增上建立与所有已存在的N个结点的隧道及相关的路由。
（2）对于已存在的N个结点，需要在每个结点上都建立一个与新增结点之间的隧道及相关的路由。
2>由于是“静态”×××，则无法反应网络的实时变化。
而且，如果隧道建立在CE上，则必须由用户维护; 如果建立在PE上，则又无法解决地址冲突问题。
Case Study:Peer-to-Peer ×××
所有的静态性质的×××都不适合大规模的应用与部署，所以为了解决这个问题，就需要将×××的部署及路由发布变为动态的。Peer-to-Peer是指CE -to-PE,也就是要在CE与PE之间交换私网路由信息，然后由PE将这些私网路由在P-Network中传播（P-Network上运行了某种动态路由协议），这样这些私网路由会自动的传播到其他的PE上。进而可以解决动态性的问题。
由于将要将私网路由泄露到公网上，所以必须严格的控制路由使用，即要确保同一个×××的CE路由器上只有本×××用涉及的SITE的路由。同时也不能使用默认路由，即如果私网路由被网络上不法人得到，它进行对网络的***时，因为没有反回的路由，所以连接就会失败。这种×××的安全性是靠双向的路由来保证的。即如果数据包不是去网×××的其它SITE的话，就过滤掉这个包，或根本不建立相应到其它网络的路由。
通常CE与PE之间运行的路由协议与P-Network上运行的路由协议是不同的，即使相同，也要有很好的路由过滤和选择机制。
Case Study:Peer-to-Peer ××× -共享PE方式
所有的×××用户的CE都连到同一台PE上（如一个城市的×××接入点），PE与不同的CE之间运行不同的路由协议（或者是相同的路由协议的不同进程，比如 OSPF）。路由始发PE将这些路由发布到公网上，在接收端的PE上将这些路由过滤后对就相应的××× SITE发给相应的CE端。
缺点：
1>为了防止连接在同一台PE上的不同CE之间互通，因为两个都是直连的路由，所以它们可以互通，必须在PE上配置大量的ACL。
2>它还是没有解决地址空间重叠的问题。即CE之间不能使用相同重叠的地址块。但大型的企业会直接被分到一块公网IP，这样地址空间重叠的问题就可以解决了。
Case Study:Peer-to-Peer ××× -专用PE方式
为每一个×××单独准备一台PE路由器，PE和CE之间可以运行任意的路由协议，与其他×××无关。PE与P之间运行BGP，并使用路由属性进行相应的过滤。
优点：无需配置任何的ACL了。安全性也有所提高。
缺点：每一个×××用户都需要新增一台专用的PE，代价过于昂贵了。
注：在这里的BGP使用的是EBGP，进而可以减少BGP全连接的代价。主要还是EBGP可以使用私有AS。
在专用PE出口怎样区别一条路由呢，这是不是我专有的××× SITE需要的路由呢? 这就要使用到BGP的community属性，对应在入口配置的community决定哪些路由是关于我专有的××× SITE的，其它的只要过滤就可以了。
Case Study:Peer-to-Peer ×××本质
Peer-to-Peer ×××虽说很好的解决了“静态的问题”但是仍旧有很多局限性：
1>没有使用隧道技术，导致私网路由泄露到公网上，安全性很差，几乎没有体现出×××来。
2>×××的“私有”特性完全靠路由来保证，导致在CE设备上无法配置缺省路由。如果你使用了缺省路由，这种×××的特性就完全没有了，这个SITE就完全就是一个普通的上网站点了。
3>仍旧存在所有的设备无法共享相同的地址空间问题。
如果要确保安全性，则必须使用隧道技术，但那些隧道技术如GRE，IPSec都已被证实其“静态性“，必须手工配置。Peer-to-Peer ×××又不能很好的解决地址空间冲突的问题。所有只靠×××自己的技术是不能解决这些隧道×××技术。
Case Study:×××需要解决的问题
因为×××本身是不能解决这些问题的了，所以需要其它的协议共同来实现，现在主要的问题是：
1>可以提供一种动态建立的隧道技术
2>可以解决不同×××共享相同地址空间的问题
第一个问题可以由MPLS来解决，因为它的LSP就是一种动态的隧道。它不把任何数据转给IP层，中途也不进行任何的修改，所以这种动态隧道的安全性就可以完美的解决。
第二个问题，必须要一种动态的路由协议来解决的，但现有的路由协议没有任何一个可以完美的实现此功能的，所以就需要对现有的协议进行相应的修改，这就要求这些协议有很好的可扩展性。
有扩展性的路由协议只有使用TLV的EIGRP，BGP和ISIS。因此它们可以扩展TLV实现支持一些新的特性。
IS-IS:它最早是OSI用来支持CLNS的协议，对IP的融合也是存在一些问题的。
EIGRP:它是CISCO私有的，而×××是一种开放技术，所以这是不合适的。
BGP:
1>由于×××的扩展，路由数目可能非常大，BGP是唯一支持大量路由的路由协议。
2>BGP是基于TCP来建立连接的，这就可以在不直接相连的路由器间交换信息，这使得P路由器中无须包含×××路由信息
3>BGP可扩展性非常的好，可支持多种属性，任何不了解这些属性的BGP路由器都将它们透明的转发，都将只使用它们了解的属性，不会因为某一属性的不支持，而丢弃整个数据分组。
mp-bgp
Case Study:BGP需要解决的第二个问题 -地址冲突
要想解决地址冲突问题，至少要攻克三个难题:
1＞本地路由冲突问题，即：在同一台PE上如何区分不同×××的相同路由。
2>路由在网络中的传播问题，两条相同的路由，都在网络中传播，对于接收者如何分辨彼此
3>报文的转发问题，即使成功的解决了路由表的冲突，但是当PE接收到一个IP报文时，他又如何知道该发给那个×××？
因为IP报文头中唯一可用的信息就是上的地址。而很多×××中都可能存在这个地址。
解决方案：
1>本地路由冲突问题，可以通过在同一台路由器上创建不同的路由表解决，而不 同的接口可以分属不同的路由表中，这就相当于将一台共享PE模拟成多台专用PE。
2>可以在路由传递过程中为这条路由再添加一个标识，用以区别不同的×××。
3>由于IP报文的格式不可更改，但可以在IP报文之外加上一些信息，由始发的×××打上标记，这样PE在接收报文时就可以根据这个标记进行转发。
Case Study:本地路由冲突解决方案 - VRF
对于本地路由冲突问题，也可以使用ACL，策略路由的方式，ip unnumber,NAT等，但这些方法都不是从根本上问题，而且它们自己也有一些本身的局限性。所以要想彻底解决这个问题，就要在理论上有所突破。
从Peer-to-Peer ×××的专用PE得来的启示，专用路由器方式分工明确，每个PE只保留自己×××的路由，可以很好的解决本地路由冲突。
然而现在的问题是我们只有一个PE，所以就要求在软件上实现这种多个PE的方式，这就是VRF。
VRF（××× Routing & Forwarding Instance,×××路由转发实例）：每一个VRF可以看作一个虚拟的路由器，用于模拟一台专用的PE设备，该虚拟路由器包括3个元素：
1>一张独立的路由表，当然也包括了独立的地址空间。
2>一组归属于这个VRF的接口的集合。
3>一组只用于本VRF的路由协议。
4>一个RD和一组RT规则。
对于每个PE，可以维护一个或多个VRF，同时维护一个公网的路由表（也叫全局路由表），多个VRF实例相互分离独立。
实现VRF并不困难，关键在于如何在PE上使用特定的策略规则来协调各VRF和全局路由表之间的关系。
Case Study:本地路由冲突解决方案/路由传递冲突解决方案 Step1 -RT
专有PE的方式中，我们为了区分不同SITE的×××的路由信息，我们在BGP中分配给它们特定的community，进而实现路由的区分。
这里我们实现VRF用的也是这种方式，只是它叫做RT(Route Target)。
扩展的community有两种格式(type=0x0002或0x0102时表示RT)：
|
Type(0x0002)
|
AS#(16bit)
|
Value(32bit)
|
|
Type(0x0002)
|
Value(32bit)
|
AS#(16bit)
|
RT的本质：
RT的本质是每个VRF表达自己路由的取舍及需要的路由类型，进而通过它可以实现不同的VRF之间的互通。
它可以解决路由在发送和接收时的冲突。
RT不是一个简单的数字，它通常是一个列表，一种路由属性列表。而且它是做为BGP的一种路由属性。
可以分为两部分：Export Target与Import Target
Export Target表示了我发出的路由属性，Import Target表示了我对哪些路由感兴趣。
SITE-A: 我发送的是红色的路由，我也只接收红色的路由。
SITE-B: 我发送的是红色的路由，我也只接收红色的路由。
SITE-C: 我发送的是黑色的路由，我也只接收黑色的路由。
SITE-D: 我发送的是黑色的路由，我也只接收黑色的路由。
这样，SITE-A与SITE-B中就只有自己和对方的路由，进而两者实现互访。同理SITE-C与SITE-D也一样。这时我们就可以把SITE-A与SITE-B称为×××-A,而把SITE-C与SITE-D称为×××-B。
|
|
发出路由
|
接收路由
|
|
专用PE方式
|
在属于特定×××的路由器上，使用BGP的community属性，将本×××的路由打上特殊标记, 并将路由发给P路由器。
|
在P路由器上接收所有的路由，并根据路由中的community属性发给特定的×××的PE设备
|
|
VRF
方式
|
在一个VRF中，在发布路由时使用RT的export规则。直接发送给其它的PE设备。
|
在接收的PE上，接收所有的路由，并根据每个VRF配置的RT的import规则进行检查，如果与路由中的RT属性match，则将该路由加入到相应的VRF中。
|
注：在专有PE方式只存在有P路由器的参与，但VRF中无P路由器参与，只有PE路由器。
Case Study:路由传递冲突问题解决 Step2-RD
因为RT不是与IP前缀放在一起的，如果在路由传递时只按RT来区分×××间的路由就有可能出现问题，特别是:BGP的Route Withdraw报文不携带属性，在这种情况下收到的路由就没有RT了，所有就不能区别不同×××之间的路由。
所以还要在路由传递时再定义一个属性，这就是RD，它的格式与 RT基本相同。
|
Type Field
|
Administrator Subfield
|
Assigned Number Subfield
|
IPv4 Address Prefix
|
|
2bytes
|
6bytes
|
4bytes
| |
注：可以说RD的作用很小，只在BGP使用withdraw报文时才会用到，尽管如此，它还是一个必须的属性值。
RD是用来防止一台PE接收 到远端PE发来的不同VRF的相同路由时不知所措，而加在路由前面的特殊信息。在PE发布路由时加上此RD，在远端PE接收到路由后，将其放在本地路由表中，用来与后来接收到的路由进行比较。
RD本质：
1>在IPv4地址加上RD之后，就变成了×××-IPv4地址族(Address Family)了。
2>通常建议为每个×××都配置相同的RD，不同的×××配置不同的RD。但实际上只要保证存在相同地址的两个VRF的RD是不同即可，不同的×××可以配置相同的RD，相同的×××也可以配置不同的RD。
3>如果两个VRF中存在相同的地址，则一定要配置不同的RD，而且两个VRF一定不能互访，间接互访也不成。
4>同一台PE上的不同VRF不能配置相同的RD。设备用来防止以后的扩展会引起出现相同的地址在两个VRF中。
5>RD并不会影响不同的VRF之间的路由选择以及×××的形成，这些事情由RT搞定。
6>PE从CE接收的标准路由是IPv4路由，如果需要发豐给其他的PE路由器，才需要为这条路由附加一个RD。
7>×××-IPv4地址仅用于ISP内部，在PE发布路由时添加。在PE接收路由后放在本地路由表中，用来与后接收到的路由进行比较。CE不知道使用的是×××-IPv4地址。
8>在数据包其穿越ISP骨干时，×××数据流量的包头中没有携带×××-IPv4地址。即这些RT/RD只用于路由传递，不用于数据传递。
Case Study:报文转发时的冲突解决方案 -私网标签
理论上讲可以使用RD来实现报文转发时的冲突解决方案，但RD是一个64bit长的字段，有些过大了，这会导致转发效率的降低。所以只需要一个短小，定长的标记即可。
由于公网的隧道已经由MPLS来提供了，而且MPLS支持多层标签的嵌套，这个标记定义成MPLS标签的格式最好不过了。
公网的标签是由LDP来分配的，通常MPLS是不参与私网的分发的，所由以MP-BGP来分配，它与私网的路由一同发布出去。
这个私网Label用来防止一台PE接收 到远端PE发给本地不同的VRF的相同地址的主机时不知所措，而加在报头前而的特殊信息。
Case Study:BGP发布路由时需要携带的信息
一个扩展之后的NLRI（Network Layer Reachability Information)增加了地址族的描述，以及私网label和RD。
|
MP_REACH_NLRI:
|
|
address-family: ×××-IPv4
地址族
|
|
next-hop:
就是PE路由器自己，通常是Loopback地址
|
|
NLRI:
|
|
label: 24bit,
与MPLS标签一样，但没有TTL（因为TTL是用于转发的)
|
|
prefix: RD(64bit
＋ip前缀）
|
|
RT
列表：
|
|
Extended_Communities(RT1)
|
|
Extended_Communities(RT2)
|
|
Extended_Communities(RT3)
|
对于使用了扩展属性MP_REACH_NLRI的BGP，我们称之为MP-BGP。
bgp/mpls ***
Case Study：CE与PE之间如何交换路由
1>在PE上配置VRF
2>PE维护独立的路由表，包括公网和私网(VRF)路由表
公网路由表：包含全部PE和P路由器之间的路由，由骨干网的IGP产生。
私网路由表：包含本×××用户可达信息的路由和转发表。
3>PE和CE通过标准的EBGP，OSPF，RIP或者静态路由交换路由信息
（1）静态路由，RIP都是标准的协议，但是每个VRF运行不同的实例，相互之间没有干扰。与PE的MP-IBGP之间只是简单的redistribute操作。
（2）EBGP也是普通的EBGP，而不是MP-EBGP，只交换经过PE过滤后的本×××路由。
（3） OSPF则做了很多修改，可以将本SITE的LSA放在BGP的扩展community属性中携带，与远端×××中的OSPF之间交换LSA。每个 SITE中的OSPF都可以存在area 0，而骨干网则可以看作是super area 0。此时的OSPF由两极拓扑（骨干区域＋非骨干区域）变为三级拓扑（超级骨干区域＋骨干区域＋非骨干区域）。
Case Study:VRF路由注入到MP-IBGP
PE路由器需要对一条路由进行几个操作：
1>加上RD（手工配置），变为一条×××-IPv4路由
2>更改下一跳属性为自己（通常是自己的loopback地址），类似于BGP的nexthop-self
3>加上私网标签（敌机自动生成，无需要配置）
4>加上RT属性（手工配置），携带的RT为export属性
5>发送给所有PE邻居
Case Study:MP-iBGP路由注入到VRF
远端PE收到路由后会将×××-v4路由变为Ipv4路由，并且根据本地VRF的import RT属性加入到相应的VRF中，私网标签保留，留做转发时使用。再由本VRF的路由协议引入并转发给相应的CE。
此时的私网标签在进入VRF中时是保留的，为了与以后的路由更新比较，来判断是否是相同的。但路由给CE的时候是没有私网标签的。
Case Study:公网标签分配过程
1>PE和P路由器通过骨干网IGP学习到BGP邻居下一跳的地址
2>通过运行LDP协议，分配标签，建立LSP通道。
3>标签栈用于报文转发，外层标签用来指示如何到达BGP下一跳，内层标签表示报亠的出接口或者属于哪个VRF（属于哪个×××）。
4>MPLS节点转发是基于外层标签，而不管内层标签是多少。
5> 所有的公网标签内的路由信息一般都是PE路由器的Loopback地址。由它将这个路由信息给第二跳P路由器，由它做第二跳标签弹出。一般这个第一跳路由器发送的这个路由信息是以一个特殊的标签3来给第二跳的路由器做为OUT LABEL的，有时也称这个特殊的标签3为implicit-null，它指示第二跳路由器它应该做第二跳标签弹出操作。
Case Study:报文转发 - 从CE到Ingress PE
1>CE将报文发给与其相连的VRF接口，PE在本VRF的路由表中进行查找，得到了该路由的公网下一跳（即：对端PE的loopback地址）和私网标签。
2>在把该报文封装一层私网标签后，在公网的标签转发表中查找下一跳地址，再封装一层公网标签后，交与MPLS转发。
Case Study:Ingress PE -> Egress PE -> CE
1>该报文在公网上沿着LSP转发，并根据途径的每一台设备的标签转发表进行标签交换
2>在倒数第二跳处，将外层的公网标签弹出，交给目的PE设备
3>PE设备根据内层的私网标签判断该报文的出接口和下一跳
4>去掉私网标签后，将报文转发给相应的VRF中的CE
转载于:https://blog.51cto.com/sense5/53841
扫一扫
694
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
