MPLS环境下：Untagged和Aggregate标签操作的区别.docxVIP

【MPLS?VPN】MPLS环境下：Untagged及Aggregate标签操作的区别最近跟一个兄弟交流到了这个问题，做了一个整理性的小结，希望与大家做个探讨交流，有任何疏漏和增补意见，还望大家多多赐教。 1.关于untagged?实验环境：拓扑如上图所示，设备互联网段IP地址空间采用10.1.xy.0/24，其中x及y为设备编号，IP地址的最后一个8位组为设备编号。所有设备的loopback0地址为x.x.x.x/32全网运行OSPF协议，全网路由可达拓扑中，接口编号为红色粗体的接口，激活LDP配置比较简单，我这里就不贴配置了，关键点是注意1：全网互通，2：跑MPLS，但是R1的F0/0及R3的F0/0不运行MPLS也就是不激活LDP。实验现象：完成实验后，R1的LFIB表如下：R1#show mpls forwarding-table?Local ?Outgoing ? ?Prefix ? ? ? ? ? ?Bytes tag ?Outgoing ? Next Hop ? ?tag ? ?tag or VC ? or Tunnel Id ? ? ?switched ? interface ? ? ? ? ? ? ?100 ? ?Untagged ? ?2.2.2.2/32 ? ? ? ?0 ? ? ? ? ?Fa0/0 ? ? ?10.1.13.3 ? ?101 ? ?Untagged ? ?3.3.3.3/32 ? ? ? ?0 ? ? ? ? ?Fa0/0 ? ? ?10.1.13.3 ? ?102 ? ?Untagged ? ?10.1.23.0/24 ? ? ?0 ? ? ? ? ?Fa0/0 ? ? ?10.1.13.3我们发现，2.2.2.2、3.3.3.3、10.1.23.0，这个前缀，我本地都分配了标签，但是，outgoing标签（严格的说是动作operation）却是untagged。为什么会出现这样的问题呢？? ? 我们知道MPLS的工作是基于IP路由表及CEF表、LIB表进行的，LSR标签交换路由器会为自己本地路由表的路由产生标签，并且将路由前缀与自己为该 前缀所分配的标签的映射发给LDP邻居。那么当一台LSR在收到LDP邻居发送给我的标签映射后，我会进行一系列的检查。首先这条路由前缀在我的路由表里 要有，在者，路由的下一跳是否就是传标签映射给我的这个LDP邻居。一台LSR有可能会从多个LDP邻居收到为同一个路由前缀捆绑的标签，而我只会使用去 往该路由前缀的实际下一跳（路由器）分配的标签。? ? Ok那么回到上面的拓扑，对于R1而言，2.2.2.2、3.3.3.3、10.1.23.0这三条路由前缀，R1会从R2及R3都学习到，但是由于 COST值的关系，R1会优选R3的路由，也就是R3是R1去往该三个网段的实际下一跳。然而，可惜的R1及R3之间并非LDP邻居，可不就是世界上最遥 远的距离么？R2呢，为这三条路由捆绑了标签，并且将标签映射发给了R1，可惜啊，R1的心这会儿在人家R3上，它就忽略了R2的标签映射（通过 debug mplsldp bindings可以看到R1直接omit了R2发过来的标签映射）。因此，就造成了R1的LFIB 的这个状态。这是一个悲情故事……这也是一个产生untagged标签动作的典型问题。实验小结：? ? 那么untagged是一个怎样的操作呢？当一台LSR收到一个标签包，它会去查看LFIB表，如果outgoing动作是untagged，那么意味着 该LSR认为这条路由IP可达，并且下一跳可能并不支持MPLS，只是IP设备，于是它会将标签包的所有标签全部弹出，然后根据LFIB表里所示的 ougoing interface及next-hop将该IP包扔出去，注意这时候不需要拿着这个IP包去查CEF表，因为LFIB表中已经有我们所需的转发信息了。? ? 这在我们这个实验环境中看似没什么问题，但是，在大多数MPLS环境中，例如MPLS VPN环境中，这个问题就大条了。?2.关于aggregate?实验环境：R1、R5为CE路由器。R1运行OSPF；R5运行EBGPR2、R4为PE路由器。R2运行VRF的OSPF，以获取R1的客户路由，重点关注1.1.1.0/24；R4运行VRF的EBGP，以获取R5的客户路由，重点关注4.4.4.0/24R2、R3、R4为MPLS VPN Backbone，Core内运行OSPF，使得三台路由器都能获取到各自的Loopback路由。Loopback均使用x.x.x.x/32。R3为P路由器，同时是RR。R2的Fa0/1、R3的F0/0及F0/1、R4的F0/0激活LDP实验现象观察一下R2的LFIB表：R2#show mpls forwardin