Understand OSPF Routing Between Inter Area

Jack_Cisco

实验目的：
1、理解OSPF内部区域间路由计算方法。
实验拓扑图：

实验步骤及要求：
1、配置各台路由器的IP地址，并且使用Ping命令确认各路由器的直连口的互通性。
2、R1和R4路由，需要接口的网络类型，以便于OSPF能够自动创建邻居关系。
R1(config)#interface serial 1/2
R1(config-if)#ip ospf network broadcast
R4(config)#interface serial 1/2
R4(config-if)#ip ospf network broadcast
3、按拓扑规定,配置相应接口的OSPF的链路开销值(cost)。配置如下所示:
R3(config)#interface serial 1/0
R3(config-if)#ip ospf cost 2
R3(config-if)#exit
R3(config)#interface serial 1/1
R3(config-if)#ip ospf cost 5
R3(config-if)#exit
4、完成配置后。暂时不查看R3的路由表，分析一下R3到达R1的192.168.1.0/24网络路由。OSPF使用cost值来计算到达目标网络度量。当出现多条冗余的链路时，会使用SPF算法进行最佳路由计算与选择最佳路由。本例中，R3到达192.168.1.0/24的网络，共有如下几条路由可供选择：
编号
路径
COST值
1#
R3 ------> R2 ------> R1 ------> 目标网络
13
2#
R3 ------> R2 ------> R4 ------> R1 ------> 目标网络
7
3#
R3 ------> R4 ------> R1 ------> 目标网络
8
4#
R3 ------> R4 ------> R2 ------> R1 ------> 目标网络
18
根据上述表格，所列出的各条路由来看，R3路由器会先优先选择2#路由，因为2#路由的cost最小。为了确认猜测。查看R3的路由表：
R3#show ip route
…………
C       172.16.255.8 is directly connected, Serial1/1
O IA    172.16.255.12 [110/6] via 172.16.255.5, 00:04:01, Serial1/0
O       172.16.255.16 [110/4] via 172.16.255.5, 00:04:01, Serial1/0
O IA 192.168.1.0/24 [110/7] via 172.16.255.5, 00:04:01, Serial1/0
…………
R3#
使用ping确认路由有效性：
R3#ping 192.168.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 112/137/144 ms
R3#
为了确认确实使用了2#路由，使用traceroute命令再次确认：
R3#traceroute 192.168.1.1
Type escape sequence to abort.
Tracing the route to 192.168.1.1
  1 172.16.255.5 52 msec 96 msec 96 msec
  2 172.16.255.1 144 msec *  168 msec
R3#
5、产生这个问题的主要原因是：
当R3路由器在选择到达R1的192.168.1.0/24网络的路由时，使用得确实是SPF的算法。计算最短最佳路由。因此R3在比较几条路由器时，会选择从R2,R4,R1这样的路由，因为其cost值是7。
当R3向数据包转发给R2的时候，R2发现此数据包是要到达其它网络。因此R2不会将数据包再转发给其相同区域的其它路由器。因为R2自己是ABR，他认为到达其它区域的数据包，需要直接转发给骨干区域。而自己也恰巧与骨干区域相连。因此R2直接将数据包转发给骨干区域的R1路由器。
正是因为这个原因，所以我们查看的路由跟实际转发数据包的路径不一致。
6、实验总结：
OSPF区域间的路由，并不是完全根据cost值计算的最短路径优先算法。而是有点类似于距离矢量的算法。
7、实验完成。


本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u3/99768/showart_1979388.html