您的位置:首页 > 其它

静态路由小特性配置

2015-06-22 19:16 204 查看
实验拓扑图:




经配置,各网段相互能ping通。此时在R3上分别ping 12.12.12.1和12.12.12.2







显然ping不通,有R3的路由表可得知,只有2个直连网段的路由表。





路由器在收到一个数据包,如何处理呢

<1>路由器是3层设备,能够解包看到3层封装的IP报头信息,自然可以得知 源IP地址、目的IP地址;
<2>读到packe的DEST IP address,查询自己的路由表,决策出自己能否到达该目的地址,能则转发,反之丢弃;
<3>如果有多条达到DEST的路由,则根据 最长掩码匹配原则
现在R3上没有去往12.12.12.0/24该网段的路由条目,只得丢弃收到的packet。
如何才能学习到去往指定网段的路由条目呢?

<1>静态路由:指定去往某个特定的网段的特定处理方式 (特定处理方式是指:从哪个接口转发出去,从下一跳转发等方式);
<2>默认路由:在这种情况下,首先查路由表,没查询到时不丢弃,统一发给默认路由所指定处理方式处理;
<3>动态路由:由动态路由协议学习到路由条目添加至路由表,依据查表来转发。
通常静态路由使用3种配置模式

<1>关联接口---->这个接口关联的是本地路由器的接口,今后将数据包从该接口转发出去
<2>关联下一跳(the next hop)----->与自己直连的链路的接口ip



2种方式设置后查看路由表 显示是不同的,关联接口是directly connected 关联下一跳是 via






这2种方式各有特色:
<1>如果关联接口,若R3的fa0/1接口down了则路由失效,这是不想看到的,通常适用于点到点网络;
<2>如果关联下一跳,会做2次解析,首先是如何到达下一跳,其次是从下一跳转发数据包。所以即便接口down了,但路由器可从备份链路(冗余的)or其他路径(只不过可能增加了路径开销)继续转发该报文,而static route仍然有效;通常适用于广播网络环境
<3>但是关联下一跳也有弊端,如图如果R3与R2直接的拓扑发生了改变,而此时static route未变,可能会出现关联的下一跳到达不了的情况,从而错误丢包。

补充简单解释下为何关联接口适用于p2p而关联下一跳适用于MA网络

在p2p网络中,关联接口和下一跳效果一样,因为对端是唯一的,当转发数据包的时候,只需要一次ARP请求即可;

在MA网络中,关联接口的话,每次转发数据包都会触发一个ARP请求,既浪费带宽流量,也对缓存区造成负荷;
关联下一跳的话,只需要在第一次转发数据包时触发一个ARP请求,今后不必在触发了,很好的机制!

第三种配置方式
<3>既关联接口又关联下一跳(双保险)



此时查看路由表 如下



这种做法比较综合,既能方便路由查找,同时减少ARP缓存表负荷。

在R3成功指定了去往12.12.12.0的静态路由后,我们再ping一下 和前面做下对比




为何能ping通.1 而仍然ping不通.2 ? 我们debug看一下




包是成功到达了R1上 但是为何Ping不通呢?
分析过程:R3上的ping包 DEST IP address=12.12.12.1 是到达12.12.12.0/24网段,查询R3路由表发现需要static route转发,当packet成功到达了R2上,R2查询了自己的路由表



发现去往12.12.12.1由接口fa0/0出去到达R1,然后我们查看一下R1的路由表



ping包成功到达了R1,但是R1上没有去往23.23.23.0/24网段的路由,所以Ping不通
而之所以能够成功ping得通12.12.12.2 因为.2接口是R2自身的接口 R2有去往23.23.23.0/24的路由 所以可以!在R1上也应该添加静态路由。这也是常见错误之一!
关联接口的补充:

关联接口时候,除了正常的物理接口如fa0/1 gi0/1 eth0/1等等,还可以关联特殊接口,比如常见的

<1>port-channel 链路聚合端口,可做链路冗余 负载均衡

<2>Tunnel 在做隧道时,可以关联隧道口,可以将指定流量(如去往对端私网流量)从tunnel进去,请参照GRE隧道;

<3>DHCP 这种方式是从DHCP server处获取default gateway作为转发地址;附加参数的补充

在关联接口或下一跳后 可以继续附加参数



<1-255> 指的是路由的管理距离,
<permanent> 添加为永久的路由
<tag> 为路由条目打上标记,今后在定义路由策略时,方便抓取过滤
<track> 跟踪路由条目 具体参数博文 《参照静态路由参数说明》

本文出自 “蓝色仓库” 博客,请务必保留此出处http://bluebox.blog.51cto.com/8852456/1664194
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: