路由器的转发方式以及静态路由的负载均衡问题~

五月の天

今天突然看到一个话题 静态路由配置负载均衡，关于这个话题在网上看了一些帖子，众说纷纭，加上自己又是强迫症患者 所以做了个实验，拓扑如下

如图，R2和R3之间有两条线路，分别有两条静态路由
R2:    ip route 2.2.2.0 255.255.255.0 20.20.20.2
          ip route 2.2.2.0 255.255.255.0 10.10.10.2

R3:     ip route 1.1.1.0 255.255.255.0 20.20.20.1
           ip route 1.1.1.0 255.255.255.0 10.10.10.1

现在使用R1的f0/0接口（1.1.1.2）pingR4的f0/0接口（2.2.2.2）.
有趣的事情来了，如果设置路由器使用不同的转发方式，数据包的流向就会有着不同的效果。
首先来解释下路由器的数据转发方式：
      1.进程交换（procees switching）
      2.快速交换（fast swithcing）
      3.思科极速转发（cef）

进程交换：数据包进入路由器去掉二层帧头，检查三层地址判断如何转发数据包，二层帧头按照实际情况进行改写和重新CRC.数据包然后从具体的端口转发出去。

说简单点就是一次路由，一次转发，每当一个数据包过来，查一次路由表，然后转发数据。

优点：对链路的利用率较高

缺点：对于特殊的应用可能出现不可用的情况（例如某些应用要求数据包的发送路径和返回路径相同），cpu直接处理数据，降低了路由器的效率，速度慢（貌似都是缺点了~~）

配置命令:R（config-if）#no ip route-cache

快速交换：

快速交换使用缓存机制存储路由信息，当某个数据流的第一个数据包进入路由器时，路由器首先使用进程转发决定数据流的走向，然后生成一个与之相关的缓存表，剩余的数据包就会基于快速缓存直接转发，而不需要再次经过CPU处理，减轻了CPU的负载

优点：大大提高了转发效率

缺点：有可能出现次优路径或者路由黑洞，由于第一个包使用进程交换，生成缓存后，就算路由条目失效，路由器仍然会将数据包从缓存条目中指定的接口转发出去，直到缓存数据过期（好像是ARP的超时时间，具体忘记了 哪位能记住的还请指点下）

极速交换：

路由器使用一张FIB表（forwarding information base）和二层的邻接表构建成的CEF表转发数据，和快速转发不同的是，CEF转发的第一个数据包不需要经过进程转发处理，而是全部由CEF直接转发。

大体上和快速转发类似，不同的是，cef是动态的（常常被称之为基于拓扑的转发方式），在路由表形成之后，路由器会自动生成相应的FIB以及邻接表，上图应该描述的比较清楚，当数据包过来时，不再是查看ip routing（RIB）和ARP表项进行数据转发，而是直接查询FIB和邻接表，这两张表都是基于硬件的，所以查询速度以及转发效率会大大提高。另外，前文提到了快速转发的弊病，就是由于缓存表项的存在可能会导致路由黑洞，CEF由于是基于拓扑的，当路由表出现变动时，FIB也会随之更新，所以也不会存在黑洞的问题。

总体而言，好像CEF没什么缺点（可能我没发现），思科的设备如果有该功能的默认就是启用了该功能。

此外好像还有Optimum and Distributed Switching、Netflow switching等方式，我没有仔细了解过~就不深究了

好了讲完这三种转发方式后，再来扯扯静态路由的负载均衡。

如前文的拓扑，R2、R3有着两条指向同一个目的地的静态路由，所以会启用负载均衡。但是，如果你使用默认的配置（CEF转发），你会发现，如果到达同一个目的地（本文中的2.2.2.2），都只会使用一条线路，这就是所谓的基于目的的负载均衡（per-destination）。看图说话

使用cef后接口的状态

开启命令： 全局模式下使用ip cef即可。默认也是开启的

如上图，左边的wireshark抓的是R2的F1/0的数据包，右边的抓的是R2的F2/0的数据包.

当在R1上使用Ping 2.2.2.2和ping 2.2.2.2 source 1.1.1.2的时候，查看数据流走向

右边的wireshark没有ping的数据，证明了之前的理论，开启了CEF功能的路由器默认使用的是基于目的地的负载均衡方式（很多人也称之为基于流的转发方式）。

那么如果将R2和R3的F1/0和F2/0的负载均衡的方式改下呢？

修改方式：接口配置模式下使用 ip load-sharing per-packet

修改之后我们继续ping

大家可以看到，左边的wireshark（也就是上面一条线路）先发送了3个数据包，下面线路发送了两个数据包，继续ping的话，左边然后发送2个数据包，右边是3个数据包

也就是上->下->上->下->上   和我们定义的负载均衡的方式一样，每个数据包采用轮询的方式从不同的接口发送出去。

接着是使用fast switching方式。

修改接口配置：全局模式使用no ip cef即可

如果只想某个接口关闭 接口配置模式下使用 no ip route-cache cef即可

然后我们观察下默认的负载均衡的方式

tips：全局使用no ip cef之后，如果使用show run命令看到接口的配置和使用cef是一样的，只能通过show ip int xxx来看接口使用的是cef还是fast switching

如图，这次流量只从右边发送了，所以可以确定是基于目的地的负载均衡，这个和fast switching的工作原理是一样的（相同的数据流使用某条固定的链路）

如果我们把R2 R3的所有接口的负载均衡的方式改成per-packet呢？

file:///G:/%E6%9C%89%E9%81%93%E4%BA%91%E7%AC%94%E8%AE%B0%E6%9C%AC%E5%9C%B0%E6%96%87%E4%BB%B6/qq74007EDDCC89D6639FA700586C34330A/0b678a2b321740708c07477cba060916/)5uak_%7D%7D7%60u0%7Dz(7xmmtxzc.pngfile:///G:/%E6%9C%89%E9%81%93%E4%BA%91%E7%AC%94%E8%AE%B0%E6%9C%AC%E5%9C%B0%E6%96%87%E4%BB%B6/qq74007EDDCC89D6639FA700586C34330A/d8cf79ebb75f4907bd997d138311a0e4/nxi8v%5D76%25i~%24dwcs0g4~key.png

是的 你会发现，tmd命令打上去没用o(╯□╰)o

然后结果。。。。

是的 你没有猜错，和上图是一模一样的。。。。

证明了 对于fast switching而言，貌似无法使用per-packet的负载方式

最后是进程转发（终于快没了 麻蛋~）

修改方式很简单 接口配置模式下使用no ip route-cache即可

看到的就是上图的样子

然后我们继续ping~~~

首先，有数据包丢失 我不知道这是不是模拟器的原因，其次 细心的同学可以发现，这一次左边只有request请求，所有的reply全是在右边，这说明了两点：

第一：process switching默认使用的per-packet的负载均衡方式

第二：证明了process switching的缺陷，数据包去向和返回的路径不统一，这在某种情况下会导致一定的问题

然后就是修改接口的负载均衡的方式

我就不截图了 麻烦死了~~~

是的~~~~和fast switching一模一样 修改之后show run接口配置和使用默认一样的 不会显示接口的负载均衡的类型为per-destination

结果可想而知，就是process switching只支持基于数据包的负载均衡

总结下：

最后，我没有用debup ip packet和ping的扩展命令 以及traceroute命令。因为太tmd麻烦了 看得不爽 ，所以干脆直接抓包，简单粗暴~

第一个自己手打的东西，错误应该很多，请大家指出来 以便于我学习，谢谢大家啦~~~

不行了 花了老子几个小时了 我要去撸几把压压惊 ~~~

五月の天

刘宏涛

太好了 太好了

smlmcww

分析的太到位了

smlmcww

分析的太到位了

枫叶悠璃

谢谢楼主热心分享分享！

五月の天

表格错了 大家把cef和process switching顺序交换一下