今天做了一些关于icmp包的acl实验 发现一些比较典型的问题 拿出来和大家分享一下
首先 我们要明确两个概念 就是在ping包过程中的….. 和U.U.U
. 在路由中代表包未到或者无回应
U在路由中代表包被丢弃 设备回应不可达
在cisco设备上使用ping命令的时候经常出现U.U.U 这代表了发出的数据包在去往目的地的途中被丢弃 丢弃者返回icmp不可达信息 在发送端的cli中呈现出U.U.U 例如 中途设备没有达到目标网络的路由 会丢弃数据包并返回不可达信息等等 但是 从理论上来讲 返回的信息应该是UUUUU 为什么会出现U.U.U 经过查证发现 原来是ios中的 防止icmp洪泛攻击的 在路由器上使用命令 no ip icmp rate-limit unreachable之后 就返回的全是UUUUU了
本次试验的拓扑如上图
实验开始阶段 我们现在R1的s1/1口的入方向上 禁止了192.1.1.0 0.0.0.255 网络的信息(注意 acl所有命令后都默认根由一个deny any 命令 所以禁止某条目后要接一条permit any) 然后在R3上ping所有其他接口包括自己 返回结构都是U.U.U 也就是目的网络不可达 原因是当R3 ping的包进入R1的s1/1口时 因为acl的存在 包会被直接丢弃 然后会返回一个目的网络不可达的信息 因为返回的信息是出方向的 所以不会被丢弃 而此时 如果在R2上ping R3 是会直接返回……表示没有回应 因为R2的包是从是s1/0方向进入的 并不会被丢弃 但是R3给R2的回应是以192.1.1.2委员地址从R1的s1/1口进入传往R2的 会被acl直接丢弃 所以R2收不到R3的回应 而ping其它接口都正常
同时 在R1上ping 148.1.1.0正常 ping 192.1.1.0 都会返回…… ping R3返回无回应可以理解 为什么ping自己的端口也是无回应呢?
这里要解释一个问题 路由器ping本端端口的时候 是有一个机制的 这个机制会根据链路不同而变化 对于串行链路 也就是我们实验中使用的s口 路由器在平自己接口的时候 会先将这个 request包从本端发出 到达对端R3后 对端不做任何改动 直接将TTL值-1后发送回来 之后本端对这个发给自己的包作出回应 再将这个reply包发往R3 R3将TTL-1后又发还回来 相当于两发两收 数据包加倍 整个过程中 R3充当了一面镜子一样的角色 而对于以太链路 则没有这种机制 直接由本端发送接收一次 关于这点 笔者认为 对于串行链路 路由器根据keep-alive清楚他的另一端一定连接这另一台路由设备 而且在串行链路上还不封装二层mac 这种机制能确保链路的畅通性 而以太接口的另一端可能是路由器 交换机 或者是pc 是不需要这种机制的 实验结果如图 以太
串行
这就解释了为什么R3 ping自己会显示不可达 而R1 ping自己根本就无回应
之后我们把R1 s1/1的acl去掉 在s1/0的入方向上禁止了icmp包的信息 再次进行试验 结果也与上边类似
最后我们有一个扩展 我们把R1 s1/0的入方向上的acl改为out出方向上 看会有什么效果 首先R2除了自己的 其他接口都是ping的通的 那么R2 ping用了R1的s1/0是怎么回事呐? 我们不是吧s1/0的出方向上的icmp包都给消灭了么? 原因很简单 因为acl不能控制本地流量 而R2 ping R1之后 R1回的icmp是R1本身的流量 不是转发什么别人的 R1上的acl是不管的 也正因为这样 此时R2 ping自己本身是ping不通的 因为R2发给R1请他转发给自己的icmp包被s1/0接口给丢弃啦 直接无回应的 而R1 ping所有都是通的 往出走的都是本地流量 回来的包都是入方向的 acl还是管不着 而在R3上就更有意思了 R3 ping 除了R2以外都是通的 ping R1的s1/0通是因为入口是s1/1 而ping R2则会显示U.U.U 因为R3发往R1的icmp包在s1/0口出去前往R2的时候就直接被丢弃啦 然后R1会告诉R3 目的网络不可达
