默认路由在EIGRP中的通告

前几天有朋友在论坛里面问关于默认路由在EIGRP的通告问题，今天自己动手做了一下，贴出来供有需要的朋友参考参考，对于有问题的地方，希望大家提出来多多指教。
我的实验拓扑如下



我们先来看看默认路由能够在EIGRP正常通告的情况
先前的准备工作诸如接口的配置我就不写了，这里主要要说明的是R3上要配置一条默认路由ip route 0.0.0.0 0.0.0.0 192.168.2.1 用于测试数据包的返回。
现在我在R1上使用EIGRP通告直连网络，在R2 上通告192.168.1.0的网络，这样基本的实验环境就搭建好了。此时R1和R2 只有直连网络和在EIGRP自治系统内学习到的路由，如图





下面开始默认路由在EIGRP的通告，在这里因为EIGRP默认是开启自动汇总的，所以我们现在看到的则是开启自动汇总的情况，在R2上的操作如下



此时默认路由在EIGRP通告就成功了，查看R1和R2的路由表





对比一下R1和R2初始的路由表，我们可以看到R1的路由表里面多了一条带D*的路由，这就是通过EIGRP学习到的默认路由，在顶部的Gateway of last resort is 192.168.1.2 to network 192.168.2.0也可以看到。
R2的路由表里面除了手工添加的一条默认路由（Gateway of last resort is 192.168.2.2 to network 0.0.0.0 就是指的这条路由 ）以外，还有一条直连带*号的路由，也就是我们通告出去的路由。
此时我在R1上执行ping 172.16.1.1的命令，结果是能够通的，说明默认路由在EIGRP内通告成功。



在这里我有三点要说的是：
一是ip default-network通告的网络必须是主网络号，即有类网络，如果通告子网的话，使用上述方法，R1是学不到默认路由的。
二是没有在R2上关闭自动汇总，在这个实验拓扑中，关闭了自动汇总后，看到的效果是一样的，所以就有很多朋友认为自动汇总不会对默认路由在EIGRP的通告产生影响，事实上，关闭自动汇总对于在有些网络中还是会有不同的，有兴趣的朋友可以看我后面的实验。

先看看在这个网络中，在R2上关闭自动汇总后的情况，下图为在R2上关闭自动汇总



看看关闭自动汇总后R1和R2的路由表的变化





对比发现关闭自动汇总，对R1和R2的路由表没有产生影响。

三是在R2上使用了一条默认路由，这条路由是用来到172.16.1.0网络用的，所以此条默认路由不是实现这个实验的必须条件，如果你把这条路由改为用静态路由，一样是可以达到效果的。如果不设置这条默认路由，R1一样是可以学习到带D*的路由的，只不过在R1不能ping通172.16.1.1而已。在这里我最初有个误解就是，我认为默认路由在EIGRP的通告通告的是ip route 0.0.0.0 0.0.0.0 192.168.2.2这条默认路由，事实上通告的应该是ip default-network 192.168.2.0这条默认路由。

现在我们来看看另一个实验拓扑



跟上面的拓扑结构一样，但IP地址变化了，现在我们来重点讨论下关于网络汇总的问题。
网络汇总包括两种，一种为自动汇总，一种为手工汇总。
下面我来演示下关闭自动汇总，但不启用手工汇总的情况。
通告方法还跟上个实验一样，只不过这里在R2上我不是用默认路由到10.0.1.0/24的网络，我是用静态路由来实现，让大家来看看我第一个实验最后所说结论的正确性。初始环境不再赘述，跟上个实验环境一样，只不过IP地址发生变化。

在R2上关闭自动汇总，添加到10.0.1.0/24的静态路由，如图



查看R2的路由表



可以发现到达10.0.1.0/24的默认路由没有了，取代的是一条静态路由，以及使用ip default-network通告的网络172.16.0.0 ，通告的默认路由没有生效（Gateway of last resort is not set），通过查看这就可以看出通告有没有成功，发现了一个诀窍，但只适用于静态路由的方式，呵呵！

查看R1的路由表的情况



现象出来了吧，没有带D*的默认路由了，R1只学习到一条到达172.16.2.0的普通的路由，此时R1是不能到达10.0.1.0的网络的

而如果我现在在R2上启用自动汇总的话，看到的情况又不一样了



R2的路由表



通告的默认路由已经生效了

R1的路由表



结果就不用多说了，熟悉的朋友都知道了。

现在我通过使用手工汇总来通告默认路由



查看R2的路由表



现在用那个诀窍来看看，没有通告成功？问题出在哪里呢？还是说手工汇总不能通告？细心的朋友可能已经发现了，我的手工汇总地址172.16.2.0/24 ，这是一个子网，如果我把它改成172.16.0.0/16 ，又会出现什么情况呢？动手来做一做就知道了。



再来看看R2的路由表



通告的默认路由出现了，通告成功了。我们在R1上测试一下看看



这个实验我证明了两点：
一是对于子网网络来说，关闭了EIGRP的自动汇总，而不启用手工汇总的话，默认路由信息是通告不成功的。
二则是不管是自动汇总还是手工汇总，其实都是把子网汇总成有类网络，所以手工汇总一定要注意汇总的网络一定要是个有类网络。

其实在上面我还有一点没有证明，那就是ip default-network通告的网络也必须是主网络的问题，有兴趣的朋友可以试着证明一下，我可以说的是，子网是不成功的。

哈哈，终于到最后一个网络拓扑了，二话不说，上图



在这个实验里面，我想实现的是如何在R2上通告默认路由，以此来给大家介绍另外一种通告的方法。
先开始传统的方法吧
在R2上通告172.16.1.0/24的网络





查看R2的路由表



查看R1的路由表



R1学习到了172.16.2.0的路由，由R2通告172.16.1.0的图示上可以看出，实际上我通告的是172.16.0.0的网络，所以R1才能学习到172.16.2.0的路由。

我们不妨在R2上通告一下默认路由来看看



再看看R1的路由表的情况



R1学习不到R2通告的默认路由信息，也可以说R2通告默认路由不成功。为什么会出现这种情况呢？我的配置都没有问题啊?我的理解是在R2上使用ip default-network 172.16.0.0这条命令的原因，或者说是因为R2的两条直连网段处于同一主网，默认路由根本不知道从哪个接口出去。那么遇到这种情况，该如何通告默认路由，此时可以使用重发布来通告。我可以将R2上的静态路由重发布到EIGRP的自治系统内来实现默认路由的通告。

实现过程非常简单，使用redistribute static即可以实现，如图



下面来看看R2的路由表的情况



R1的路由表的情况如下



可以看到R1使用外部EIGRP的标识来表示，由此实现了R1到10.0.1.0的连通。

通过这个实验，我个人觉得重发布更具有适用性，使用ip default-network 通告默认路由必须要结合network这条命令进行通告，如果R3是外网的路由器，如此通告可能会引起一些不安全的因素，而且重发布更加方便，快捷。
本文出自 “Scorpion” 博客，请务必保留此出处http://scorpion.blog.51cto.com/400270/221762