静态路由小特性配置
实验拓扑图：
经配置，各网段相互能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> 跟踪路由条目 具体参数博文 《参照静态路由参数说明》