John Winning's Blog

随便一个idea

godupgod@163.com (godupgod) — Sat, 31 Jul 2010 10:20:31 +0800

看到了一个哥们的留言，突然产生了一个想法。大家在平时的学习中，有什么笔记心得么？我可以在博客中为你开一个用户，以后想留点什么笔记给自己看，查起来也方便。以后这个笔记本是我的，也可以是你们的。

有需要的请留言，留下你喜欢的用户名，和笔记的大概内容。

继续阅读《随便一个idea》的全文内容...

分类: 其他 | Tags: | 添加评论(0)

还没有相关文章，您来说两句？

好久没来了，谈谈最近情况

godupgod@163.com (godupgod) — Thu, 29 Jul 2010 20:53:48 +0800

好久没来更新了，最近发现blog的垃圾过滤插件失灵了么，垃圾评论一大堆。

还有交换链接的短消息，一直没回，抱歉了，大伙，以后可以发我邮箱，呵呵，godupgod@163.com，估计这个回的比较快。

天天看到QQ群里发现还有哥们准备考RS，仔细想想，这个东西到底有用么？这话不对，不应该说这个东西，而应该说这个行业，前景到底怎么样？有一定肯定的，那就是，肯定饿不死。我倒准备改行了，外贸怎么样？与人交流才是王道？卖什么？无所谓的啦，哈哈。

最近微薄玩的比较多，可以来找我http://t.sina.com.cn/1692778140。值得一提的是新浪同志们比较敬业，有些关键词，一上去，几分钟就消失了，我代表我党感谢你们。辛苦了，吃跟盐水棒冰吧。

听个朋友介绍，玩了几天股指期货仿真，推荐大家有空的或有多余money的来玩一玩，比股票容易操作，而且T+0的，苗头不对的，马上溜。

关于这个网站。其实我一直在想，怎么把这个网站改版下，当时想做一个类似大众点评网一样的网站，主要做汽车维修网点的评论，保养维修的估价，用的技术是ruby rails。但是一哥们放我鸽子，计划暂时搁置。有兴趣或者有能力的朋友可以来和我讨论下，我觉得还是可行的。再不行么，直接改成交友论坛？

反正我一直觉得这个空间的稳定性能有问题，访问速度一直是有问题的，时好时坏。中国就这样，付好钱，乙方就牛叉了，一分价钱一分货，反正已经卖身两年了，没办法了。下次准备换成VPS，可惜火速没有VPS，只能去看看新网或者万网了，不知道VPS能绑定多少个域名，这个才是大问题。

最近天热，能宅同志们就宅吧！

PS，想起一个事情，发垃圾留言的，下次留个价格给我，告诉我下你们怎么收费的。也许哪天我用得着。

继续阅读《好久没来了，谈谈最近情况》的全文内容...

分类: 其他 | Tags: | 添加评论(1)

还没有相关文章，您来说两句？

购买Godaddy主机问题

godupgod@163.com (godupgod) — Wed, 09 Jun 2010 15:20:26 +0800

今天闲来无事，在Godaddy上定购了一个经济型的主机，几个小时后，他分配给我的IP地址97.74.215.236，我用FTP登陆，发现怎么登陆不了，ping了一下，在202.97.35.98这里出问题了，查了一下IP地址，万恶的XXX，被block了。

那我算什么情况？做个网站只能提供海外同胞访问？是不是适合用来做XX网站？

最后还算Godaddy有良心，退款给我了

继续阅读《购买Godaddy主机问题》的全文内容...

分类: 其他 | Tags: | 添加评论(0)

还没有相关文章，您来说两句？

用自建FTP代替xmarks服务器

godupgod@163.com (godupgod) — Wed, 26 May 2010 23:09:40 +0800

Firefox的书签同步插件xmarks前两天被gfw封锁了。正常方法无法同步书签了。让人很是恼火。今天再xmarks的设置中看见可以自定义服务器。尝试了一下，确实可用！

这里就说一下如何搭建吧。爬墙去xmarks的wiki上查阅了详细信息。其实这种同步方式非常非常简单，并且支持很多种协议，按照wiki的说法，只要是Firefox自己支持的协议如（ftp、 http、https等）它都可以支持。我在这里就选用了最简单的方法，FTP。只要你有任意一台有写权限的FTP即可。无需过多设置即可让xmarks从它上面同步书签。首先要说的是，如果要自定义服务器的话，不要再用配置向导，它是默认连接xmarks官方服务器的。

具体看以下步骤：

为FTP创建一个独立的帐号和密码。也可以使用现有的帐号，但是最好还是分开。（个人觉得会比较安全）
创建任意一个目录用来保持书签和密码，如xmarks，然后记下这个目录的全路径如：ftp://ftp.example.com/xmarks
将这个文件夹的访问权限设置为777（Win服务器可以跳过这一步）
打开xmarks的设置对话框，找到“高级”页面中最下面的“服务器”，将“使用自己的服务器”打钩
弹出对话框会让你输入自己的服务器网址和密码网址。你服务器地址你可以输入：ftp://ftp.example.com/xmarks/bookmarks.json 如果你要保持密码的话，输入：ftp://ftp.example.com/xmarks/password.json （注意，这两个地址必须是文件，不能是目录。文件名可以自己指定。这两个地址最好不要透露给其他人。
切到设置里的状态页面，在帐户里面设置你ftp的用户名和密码。
然后再次切回高级页面，点选强制覆盖服务器书签后的上传按钮。如果同步成功，应该会有提示，并且在FTP上可以看到书签和密码文件。

然后就大功告成了。Have fun.

继续阅读《用自建FTP代替xmarks服务器》的全文内容...

分类: 其他 | Tags: | 添加评论(0)

还没有相关文章，您来说两句？

最近想做网站推广？

godupgod@163.com (godupgod) — Mon, 24 May 2010 22:57:04 +0800

SEO？SEM？

继续阅读《最近想做网站推广？》的全文内容...

分类: 其他 | Tags: | 添加评论(0)

还没有相关文章，您来说两句？

究竟为什么内网不能用外网地址访问内部服务器

godupgod@163.com (godupgod) — Sat, 08 May 2010 21:42:03 +0800

hi大家好，今天我们来讨论一个很多人都找不到答案得问题：究竟为什么内网不能用公网地址访问内网服务器。不是任何设备都存在此问题，拿cisco的设备来说，不同版本的ios，有的就没有这个问题，而有的版本就有问题，netscreen的防火墙也没有这个问题，关键是开发者有没有意识到这个问题，通过修改ios，完全可以避免。对于这个问题，解决方法是有，比如内网dns欺骗、pix上得alias等等，但是究竟为什么有些设备不支持呢？今天我斗胆发个贴，因为有些结论纯粹靠想，也没有设备进行试验，所以希望大家跟贴讨论，达到抛砖引玉的目的，谢谢了先！

以下所有内容均针对出口是以太网的情况，对于串口接入，不会出现这种问题。

如图，这个图是本贴的初始图，大圈是本地路由器，和他相连的是isp路由器，和isp相连的是internet上随便一个路由器。

screen.width*0.6){this.width=screen.width*0.6;this.alt='此图已经缩小，点击察看原图。';this.onmouseover=this.style.cursor='pointer';this.onclick=function(){window.open('http://bbs.net130.com/attachment.php?attachmentid=28693')}}" src="http://www.godupgod.com/uploaded/2010/5/201005082145320231.bmp" />
本地出口地址是5。5。5。1，isp对端是5。5。5。2（掩码没写，稍后会分别讨论）。 1。1。1。1和1。1。1。2是内网两台服务器的内网地址，被静态映射到公网上的5。5。5。4和5。5。5。5。内网的pc全部被pat到出口上。本地路由器一条缺省路由到isp对端。

我想这个拓扑应该是非常普遍的了，我认为就是因为这个非常普遍的拓扑，造成了很多人所反应的“内网不能通过公网地址访问内网服务器”这个问题。我认为这个问题的关键原因就在于掩码，就是在3层上做文章。

第一节

先来看看一般情况下，这个环境的掩码的规划。假设isp分配一段8地址子网给本地，这样isp路由器接口和本地路由器接口共占用2个，网络地址、广播地址共占用2个，可用的一共4个，掩码是248。对于图示的拓扑，假设本地路由器出口掩码是248（内网pc的pat地址相应的也就是掩码为248），被映射的两个地址掩码也是248，这个最普遍的掩码规划，结果是：服务器、内网pc的pat地址、本地出口地址全部处于同一个网段。我们分析一个包的来龙去脉，来看看到底内网pc通过公网地址可否访问到内网服务器。

假设内网一台pc1。1。1。111发出ping 5。5。5。4（服务器的公网地址）请求，包源地址1。1。1。111，目的地址5。5。5。4，路由器收到这个包后，检查路由表，发现5。5。5。4就位于自己的出口网段（假设出口为以太口），所以直接通过arp广播请求5。5。5。4的mac地址，问题出现了，谁会应答这个请求呢？没有人，所以，这种情况下（所有公网地址在同网段）当然不会通。不但内网访问服务器不行，服务器之间通过公网地址访问也不会通。

结论一：只要出口地址和服务器映射的公网地址在同网段，就有问题。

第二节

基于上面的讨论，我们知道了只要出口地址和服务器映射的公网地址在同网段，就会发生“无人应答”的必然结果，所以我们这次改变掩码规划，将出口掩码变长，变为252（isp掩码也要相应改变）。在这里首先声明一个要点，就是nat池的地址可以和出口不在同网段，以前有帖子也讨论过，我自己一开始也迷惑，后来想明白了，只要isp路由器上有这些地址的路由就可以，下一条是本地路由器，这样本地路由器便可以接受到这些包。

我们再次分析一个包的流程。内网pc1。1。1。111发出ping 5。5。5。4请求，包源地址1。1。1。111，目的地址5。5。5。4，路由器收到这个包后，检查路由表，这一次，发现5。5。5。4不在本地的任何接口，所以走了缺省路由，将包发给了isp对端口，并在本地nat表中生成一条项目，记录内网地址1。1。1。111被转换成公网地址5。5。5。1加上端口号（假设端口号是8888），isp接受到的包，目的地址是5。5。5。4，源地址变成了5。5。5。1，它检查它的路由表，发现5。5。5。4路由下一条是5。5。5。1，也就是本地路由器，所以又将此包发给本地路由器，经过了一次往返后，本地收到这个包，首先接受nat引擎的过虑，发现5。5。 5。4正在被静态映射到内网的1。1。1。1的主机，所以改变目的地址为1。1。1。1，源地址还是5。5。5。1，这样就交给了路由引擎，查看路由表，1。1。1。1的路由当然有了，通过2层直接发给1。1。1。1，至此，去程的包分析完毕。

我们再分析回程的包。服务器1。1。1。1收到包后，准备回应给5。5。5。1（加端口号），发出reply包，源地址1。1。1。1，目的地址5。5。 5。1:8888，本地路由器收到后，先给路由引擎，发现5。5。5。1就是出口地址，问题又来了，包的目的就是出口，而不是经过出口，这时候路由器该怎么办呢？假如是从外向内来的包访问5。5。5。1:8888，这时候会先提交个nat引擎，做nat转换。但是这是从内向外发出的包，要先提交给路由引擎，我认为此时，由于收到的包是从内向外的，目的直接就是针对出口来的，而出口并没有开启什么端口，除非为了web管理，或者telnet管理开启80或 23端口，所以路由器会丢弃，因为没有得到应答。

结论二：只要出口地址和内网pc的pat地址同网段，同样会有问题

第三节

我们再变更掩码方案，使得内网pc的pat地址和服务器映射地址同网段，但和出口不同网段。假设内网pc的pat地址为5。5。5。6（和服务器地址同网段）

我们再次分析一个包，内网pc1。1。1。111发出ping 5。5。5。4请求，包源地址1。1。1。111，目的地址5。5。5。4，路由器收到这个包后，检查路由表，发现5。5。5。4不在本地的任何接口，所以走了缺省路由，将包发给了isp对端口，并在本地nat表中生成一条项目，记录内网地址1。1。1。111被转换成公网地址5。5。5。6加上端口号，isp接受到的包，目的地址是5。5。5。4，源地址变成了5。5。5。6，它检查它的路由表，发现5。5。5。4路由下一条是5。5。5。1，也就是本地路由器，所以又将此包发给本地路由器，经过了一次往返后，本地收到这个包，首先接受nat引擎的过虑，发现5。5。5。4正在被静态映射到内网的 1。1。1。1的主机，所以改变目的地址为1。1。1。1，源地址还是5。5。5。6，这样就交给了路由引擎，查看路由表，1。1。1。1的路由当然有了，通过2层直接发给1。1。1。1，至此，去程的包分析完毕。

我们再分析回程的包。服务器1。1。1。1收到包后，准备回应给5。5。5。6（加端口号），发出reply包，源地址1。1。1。1，目的地址5。5。 5。6，本地路由器收到后，先给路由引擎，发现5。5。5。6不在本地任何端口下，所以走了缺省路由，发给isp，并在nat表中生成一条记录，将1。 1。1。1转换为5。5。5。4，isp接受到包源地址变为5。5。5。4，目的地址是5。5。5。6，通过检查路由表，发现5。5。5。6这个地址的路由下一条应该是5。5。5。1，也就是本地路由器，所以包又被发回来了，经过一次往返，本地收到了这个包，首先提交给nat引擎，发现目的地址5。5。 5。6在nat表中对应着内网pc1。1。1。111，所以将5。5。5。6替换成1。1。1。111，源地址不变，还是5。5。5。4，然后提交给路由引擎，路由器在2层将包发给1。1。1。111，这时，1。1。1。111这台主机收到了从5。5。5。4返回的包，而他一开始ping请求包，就是发给 5。5。5。4这个公网地址
的，所以ping通了！！！！

结论三：内网pc的pat地址和服务器公网地址同网段，同时和出口地址不同网段，这样没有问题。

第四节

本贴的高潮部分已经达到，至此，只剩下一种情况，就是内网pat地址、服务器公网地址、出口地址全部不在同网段。假设出口掩码252，服务器公网地址段掩码248，内网pc的pat地址改为5。5。5。254，这样三种地址都不在同网段。而且isp也必须有服务器公网地址和内网pc的pat地址的路由，下一条是5。5。5。1我们再次分析一个包，内网pc1。1。1。111发出ping 5。5。5。4请求，包源地址1。1。1。111，目的地址5。5。5。4，路由器收到这个包后，检查路由表，发现5。5。5。4不在本地的任何接口，所以走了缺省路由，将包发给了isp对端口，并在本地nat表中生成一条项目，记录内网地址1。1。1。111被转换成公网地址5。5。5。254加上端口号，isp接受到的包，目的地址是5。5。5。4，源地址变成了5。5。5。254，它检查它的路由表，发现5。5。5。4路由下一条是5。5。5。1，也就是本地路由器，所以又将此包发给本地路由器，经过了一次往返后，本地收到这个包，首先接受nat引擎的过虑，发现5。5。5。4正在被静态映射到内网的1。1。1。1的主机，所以改变目的地址为1。1。1。1，源地址还是5。5。5。254，这样就交给了路由引擎，查看路由表，1。1。1。1的路由当然有了，通过2层直接发给1。1。1。1，至此，去程的包分析完毕。

我们再分析回程的包。服务器1。1。1。1收到包后，准备回应给5。5。5。254（加端口号），发出reply包，源地址1。1。1。1，目的地址5。 5。5。254，本地路由器收到后，先给路由引擎，发现5。5。5。254不在本地任何端口下，所以走了缺省路由，发给isp，并在nat表中生成一条记录，将1。1。1。1转换为5。5。5。4，isp接受到包源地址变为5。5。5。4，目的地址是5。5。5。254，通过检查路由表，发现5。5。5。 254这个地址的路
由下一条应该是5。5。5。1，也就是本地路由器，所以包又被发回来了，经过一次往返，本地收到了这个包，首先提交给nat引擎，发现目的地址5。5。 5。254:某个端口，在nat表中对应着内网pc1。1。1。111，所以将5。5。5。254替换成1。1。1。111，源地址不变，还是5。5。 5。4，然后提交给路由引擎，路由器在2层将包发给1。1。1。111，这时，1。1。1。111这台主机收到了从5。5。5。4返回的包，而他一开始 ping请求包，就是发给5。5。5。4这个公网地址的，所以ping通了！！！！

结论四：三种地址全部不在同网段，没有问题。

综上所述，得到了4个结论：

结论一：只要出口地址和服务器映射的公网地址在同网段，就有问题。
结论二：只要出口地址和内网pc的pat地址同网段，同样会有问题。
结论三：内网pc的pat地址和服务器公网地址同网段，同时和出口地址不同网段，这样没有问题。
结论四：三种地址全部不在同网段，没有问题。

可以简单的发现，前两个是充分条件，只要满足了其中一个，就会出现问题，而现在大多数的接入都符合前两个情况，而几乎没有人“多此一举”的去改变掩码规划，所以造成如此多的普遍现象：内网不能用公网地址访问内网服务器！！！！！

出口地址只要不和其他两种地址同网段，就可以保证不出问题。

至此，已经探讨了问题的原因。此过程中我还得到了一个推论和一个待验证的问题。

推论：如果nat池中的公网地址和出口地址不同网段，不管在内网还是公网ping nat池中未参与转换的公网地址，会出现环路，包在本地和isp之间来回往返。

待验证的问题：

对于第三节和第四节，如果只在本地出口变长掩码，isp端不作任何改变，会怎么样？以第三节的环境来说：我们再次分析一个包，内网pc1。1。1。111 发出ping 5。5。5。4请求，包源地址1。1。1。111，目的地址5。5。5。4，路由器收到这个包后，检查路由表，发现5。5。5。4不在本地的任何接口，所以走了缺省路由，将包发给了isp对端口，并在本地nat表中生成一条项目，记录内网地址1。1。1。111被转换成公网地址5。5。5。6加上端口号，isp接受到的包，目的地址是5。5。5。4，源地址变成了5。5。5。6，它检查它的路由表，由于此时isp的接口掩码没有变长，还是248，所以，它发现5。5。5。4路由就在它自己的接口上，所以直接在接口发arp请求5。5。5。4的mac地址，此时，按理说，没人会应答（除非本地开了代理 arp），但是有一次偶尔发现在路由器上show arp，会发现有些奇怪的条目，ip地址都是nat池中的地址，mac地址不管ip多少，都是本地出口的mac地址，这样的话，即使arp请求的地址不和出口同段，一样会得到应答，不知道这个对不对。

对这个问题的解决方法，在ios层面，一般是利用修改dns回包中的payload实现的，将dns返回的公网地址，修改成内网地址，这样直接通过内网通信，就不会有问题了。对于直接用公网ip访问的包，会在路由器内部先nat，然后调头，不走出口，直接再回到内网，以支持用公网地址访问。

写了这么多，不知道各位有没有耐心看完，不管怎么样，请大家多发表评论，谢谢！

本文转自：http://bbs.net130.com/showthread.php?t=129984

要解决这个问题：

也可以是用ASA的alias命令

一般的情况是公司内部在inside架设一台DNS服务器，供Inside的用户使用，而且这个一般是不能缺少的，因为有的服务并不是对外提供的，而是仅仅 Inside内的用户使用，并且服务器放在Inside中，这里对Inside的DNS和主机的设置就不多说了。这样可以让公司内部的人要访问比如WEB 服务器或者FTP服务器可以直接解析到内部地址访问，提高了效率。

但是也有些情况下，内部的机器需要通过外部IP访问自己的服务器，这个时候朋友们就会发现内部主机无法通过外网IP访问内部的服务器。这是什么原因呢?其实是因为我们如果需要通过外部IP访问内部服务器的话需要到外部绕一圈，而ASA防火墙里我们只需要设置一下IP回流就可以让它不到外面绕，直接在防火墙内实现转换。

比如我们的邮件服务器内部地址是：172.16.0.2,接在我们的DMZ商品上，我们公网IP是123.100.100.100，防火墙里设置了 static nat，把outside的80映射到了172.16.0.2上面，这样就能使外面的人通过外网ip访问我们的web服务器。那么如何使内部的人也能通过外网ip访问web服务器呢?我们只要加入下面这条命令即可(假设内部inside)

alisa (inside) 172.16.0.2 123.100.100.100 255.255.255.255

这样让内部访问123.100.100.100这个ip就会直接转换到172.16.0.2，这样就没有问题了

ALIAS命令完整的格式解析：
alias (发出DNS请求的接口) 需要转换成的IP地址外部DNS server给出的响应地址 255.255.255.255

继续阅读《究竟为什么内网不能用外网地址访问内部服务器》的全文内容...

分类: Cisco | Tags: NAT | 添加评论(3)

防火墙 VPN NAT穿越技术 (2009-6-15 23:54:14)

最近在研究VOIP，贴篇文章，使用STUN穿越NAT

godupgod@163.com (godupgod) — Fri, 26 Feb 2010 21:38:30 +0800

最近在玩VOIP，发现外网的语音网关能够顺利拨上IPPBX，但是接电话之后没有声音，发觉还是语音网关这边路由器端口的问题

STUN是RFC3489规定的一种NAT穿透方式，它采用辅助的方法探测NAT的IP和端口。毫无疑问的，它对穿越早期的NAT起了巨大的作用，并且还将继续在ANT穿透中占有一席之地。

STUN的探测过程需要有一个公网IP的STUN server，在NAT后面的UAC必须和此server配合，互相之间发送若干个UDP数据包。UDP包中包含有UAC需要了解的信息，比如NAT外网 IP，PORT等等。UAC通过是否得到这个UDP包和包中的数据判断自己的NAT类型。

假设有如下UAC（B），NAT（A），SERVER（C），UAC的IP为IPB，NAT的IP为 IPA ，SERVER的 IP为IPC1 、IPC2。请注意，服务器C有两个IP，后面你会理解为什么需要两个IP。

（1）NAT的探测过程：

STEP1：B向C的IP1的pot1端口发送一个UDP 包。C收到这个包后，会把它收到包的源IP和port写到UDP包中，然后把此包通过IP1和port1发还给B。这个IP和port也就是NAT的外网 IP和port（如果你不理解，那么请你去看我的BLOG里面的NAT的原理和分类），也就是说你在STEP1中就得到了NAT的外网IP。

熟悉NAT工作原理的朋友可以知道，C返回给B的这个UDP包B一定收到（如果你不知道，去读下我的其它文章）。如果在你的应用中，向一个STUN服务器发送数据包后，你没有收到STUN的任何回应包，那只有两种可能：1、STUN服务器不存在，或者你弄错了port。2、你的NAT拒绝一切UDP包从外部向内部通过（我们公司的NAT就是）。

当B收到此UDP后，把此UDP中的IP和自己的IP做比较，如果是一样的，就说明自己是在公网，下步NAT将去探测防火墙类型，我不想多说。如果不一样，说明有NAT的存在，系统进行STEP2的操作。

STEP2：B向C的IP1发送一个UDP包，请求C通过另外一个 IP2和PORT（不同与SETP1的IP1）向B返回一个UDP数据包（现在知道为什么C要有两个IP了吧，虽然还不理解为什么，呵呵）。

我们来分析一下，如果B收到了这个数据包，那说明什么？说明NAT来着不拒，不对数据包进行任何过滤，这也就是STUN标准中的full cone NAT。遗憾的是，full cone nat太少了，这也意味着你能收到这个数据包的可能性不大。如果没收到，那么系统进行STEP3的操作。

STEP3：B向C的IP2的port2发送一个数据包，C收到数据包后，把它收到包的源IP和port写到UDP包中，然后通过自己的IP2和port2把此包发还给B。

和step1一样，B肯定能收到这个回应UDP包。此包中的port是我们最关心的数据，下面我们来分析：

如果这个port和step1中的port一样，那么可以肯定这个NAT是个CONE NAT，否则是对称NAT。道理很简单：根据对称NAT的规则，当目的地址的IP和port有任何一个改变，那么NAT都会重新分配一个port使用，而在step3中，和step1对应，我们改变了IP和port。因此，如果是对称NAT,那这两个port肯定是不同的。

如果在你的应用中，到此步的时候PORT是不同的，恭喜你，你的STUN已经死了。如果不同，那么只剩下了restrict cone 和port restrict cone。系统用step4探测是是那一种。

STEP4：B向C的IP2的一个端口PD发送一个数据请求包，要求C 用IP2和不同于PD的port返回一个数据包给B。

我们来分析结果：如果B收到了，那也就意味着只要IP相同，即使port不同，NAT也允许UDP包通过。显然这是restrict cone NAT。如果没收到，没别的好说，port restrict NAT.

（2）SIP怎么使用STUN

个人认为这是个很不值得提的问题，不过有许多人问我，还是简要提一下。其实这是个很简单的问题，SIP通过STUN得到NAT的外网IP和SIP的信令监听端口的外网port，替换SIP注册包中的contact头中的IP和port，然后注册。这样就可以确保当有人呼叫你的的时候注册服务器能找到你。需要提醒你的是，NAT发现一个连接超过一段时间后没有活动，它就会关闭这个影射，因此你必须间隔一端时间发送一个数据包出去以keep alive。

另外，当你要和别人建立RTP通讯的时候，不要忘记把你的SDP中的IP和PORT改成公网IP和PORT。

================================================================================================

下面对SIP协议产生NAT穿透问题，作一些解释；及提出解决的办法。
1、大致有4种类型的NAT。
a) Full Cone 完全圆锥体
b) restricted cone 受限制的圆锥体
c) port restricted 端口受限制的圆锥体
d) symmetric 对称的
其中a,b,c 也称作非对称的NAT。

2、SIP终端在NAT后面，其工作有可能出现问题。原因是SIP信令走的路径，和媒体流走的路径不一样。

3、Full Cone 完全圆锥体NAT
因特网上的任何PC，可以发送数据包到IP:port对；而NAT将这个IP:port对（公网上的）映射到内网的IP:port对（私有网络的）。

4、restricted cone 受限制的圆锥体NAT
NAT外面的PC，只有那些内网中已有PC与之联系过的PC，才能通过这个映射进来。例如，我通过内网的一台机器，IP 地址是10.1.1.1:123，与PC(a)联系，则PC(a)也可以通过这个NAT的映射，联系到我。而PC(b)则不行。
10.1.1.1:123 ---NAT ---> 202.70.65.78:10000 ------pc(a)
如果pc(b)也发送数据到 202.70.65.78:10000，则不会有数据送到10.1.1.1:123。

补充说明：
如果我也联系过pc(b)，则pc(b)也可以进来了。
10.1.1.1:123 ---NAT ---> 202.70.65.78:10000 ------pc(b)
如果pc(b)也发送数据到202.70.65.78:10000，则数据送到 10.1.1.1:123。

5、port restricted 端口受限制的圆锥体NAT
除了4的条件外，即不但要检测pc(a)的源IP地址，还要检测其端口是否与前面也一样。
10.1.1.1:123 --->NAT---->202.70.65.78:10000 -----> pc(a)[213.123.324.34:8000]

这个NAT只会接收从IP地址 213.123.324.34 且端口为 8000来的数据，让进入到10.1.1.1:123。

6、对称的NAT 这是关系描述最简单的一个
10.1.1.1:1000 ----NAT -----> 200.123.123.34:1234 ----pc(a)
10.1.1.1:1000 ----NAT -----> 200.123.123.34:2222----pc(b)
这种NAT的IP:port对，对每个外部的程序，都是不同的。因而每一个外部的程序，都有自己的映射（NAT分配的IP:port对）。而前面的三种，多个外部程序，可能共用一个NAT的IP:port对。

7、RTP的问题
在RTP的消息正文内，有UA能够成功通信所需要的一些信息。这种消息正文，就叫做SDP消息。

问题在于，SIP终端（UA）可能对NAT一无所知。因而在SDP中包含的IP地址，通常使用内部的IP地址，也就是SIP终端知道的IP。这样，当通信的对方想与SIP终端通信时，就查看SDP消息中的IP地址，但是什么也没有得到，因为这里使用的是内部IP地址。

下面举个例子说明：

INVITE sip:040600@192.168.20.2:5060 SIP/2.0.
Record-Route: .
Via: SIP/2.0/UDP 143.248.130.35;branch=z9hG4bK758e.976609c7.0.
Via: SIP/2.0/UDP
192.168.20.3;rport=1024;received=223.178.140.109;branch=z9hG4bK34efcab2403aa20d.
From: "Iqbal" ;tag=3a7ceb24a6ac50c4.
To: .
Contact: .
Supported: replaces.
Call-ID: 7f2c327896a5b0e1@192.168.20.3.
CSeq: 8717 INVITE.
User-Agent: Grandstream HT487 1.0.5.18.
Max-Forwards: 16.
Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE.
Content-Type: application/sdp.
Content-Length: 343.
.
v=0.
o=040618 8000 1 IN IP4 192.168.20.3.
s=SIP Call.
c=IN IP4 192.168.20.3.
t=0 0.
m=audio 38660 RTP/AVP 0 8 4 18 2 15 99.
a=sendrecv.
a=rtpmap:0 PCMU/8000/3.
a=rtpmap:8 PCMA/8000/3.

SIP消息的标题头，类似于邮件的标题头。从后往前看，从From行开始，看到第一个Via行，这是SIP终端自己认为的IP地址，例如 192.168.20.3。但是SIP代理服务器是聪明的，它知道这个消息是从哪里发过来的，它添加了rport和接收到的标志：
Via: SIP/2.0/UDP
192.168.20.3;rport=1024;received=223.178.140.109;branch=z9hG4bK34efcab2403aa20d.

也就是说，SIP代理服务器，知道发消息的SIP终端的公网地址是223.178.140.109:1024。
这样，SIP代理服务器是可以与SIP终端通信的，因为它知道SIP终端的公网地址。

但是，可怜的老式的RTP被阻塞了，因为它的标题头如下：
v=0.
o=040618 8000 1 IN IP4 192.168.20.3.
s=SIP Call.
c=IN IP4 192.168.20.3.
t=0 0.
m=audio 38660 RTP/AVP 0 8 4 18 2 15 99.
a=sendrecv.
a=rtpmap:0 PCMU/8000/3.
a=rtpmap:8 PCMA/8000/3.

SIP终端期望从端口 port m=38660 且IP地址IP c= 192.168.20.3来接收RTP数据，而这个192.168.20.3:38660，就是通信的对方试图发RTP数据的目的地址。

这就是SIP电话振铃总是能够听到，而接起来却没有声音的原因。

8 解决办法告诉SIP终端，不要如此傻地工作，而要想办法知道NAT分配给自己的端口映射。

并将公网的IP地址：端口放到SDP消息中。这样，SIP终端就问NAT....。或者是问公网的某个服务器，NAT分配给自己的映射是什么。

9 问NAT。这种办法就是使用UPnP协议，另外去参见UPnP的资料。

10 问公网上的某个服务器。如STUN服务器。
SIP终端发送一个探测数据包，到公网上的服务器。公网上的服务器会发回数据包，会包含有关NAT的详细信息。有了这些信息，SIP终端就会知道它是否在NAT后面。这种探测方法，可以用于上面4种NAT，都有效。例如SIP终端从 10.1.1.1:1000发送一个数据包，则SDP消息中包含的是m=1000 and c=10.1.1.1。但是，如果SIP终端先进行NAT探测，则会知道NAT会分配公网的IP:端口是212.134.123.23:12345。则 SIP终端直接在SDP消息写m=12345，c=212.134.123.23。

产生的问题因为NAT的端口分配是动态的，因而有可能会改变。这样，在发送了NAT探测消息后，要很快地发送出SIP消息。而且，SIP终端发送数据的端口和接收数据的端口要是一样的。

注意受限制的圆锥体（包括端口受限制的圆锥体）NAT，它不让回来的消息进来，除非SIP终端先发了一个数据包给它。因而，SIP终端需要先发一个数据包给对方。这样以后对方来的数据，就可以进入NAT内部了（不过，不需要为这个操作担心，有办法的）。

上面的办法在对称的NAT后面，不能够工作。因为，对称的NAT，它在分配给SIP终端外部的IP:port时，每次都变化（不同的对方不一样）。也就是SIP终端在探测NAT时，得到的IP:port，与它后来发SIP消息时，分配的IP:port不一样。这样，对方来的语音数据就进不来，因为对方得不到正确的IP:port。

11、上面描述的过程，其实就是采用STUN协议时，解决问题的过程。就是SIP终端向STUN服务器发探测NAT的数据包。

12、对称的NAT 解决办法就是在公网上放一个中转语音流的服务器。这个中转语音流的服务器有时就是一个Out Bound proxy。注意，这个中转语音流的服务器，可能会成为瓶颈。由于语音要经过中转语音流的服务器，所以路径增长了，音质会变差。所以，对称的NAT，要 SIP能够工作，总之是个麻烦。

不过，目前大多数的NAT，都可以做“虚拟服务器的端口转发”，即将SIP工作需要的端口转发到SIP终端上去。如果在NAT设备上，做了“虚拟服务器的端口转发”，则NAT会保留SIP工作需要的端口，专用于SIP终端，这样SIP终端就相当于是在一个Full Cone完全圆锥体的NAT后面，SIP用STUN工作没有问题。SIP终端需要的端口数是这样确定的，一个端口用于SIP信令，比如5060。RTP端口的数量，取决于通话的路数。一路通话需要2个RTP端口。每增加一路通话，则需要多2个端口。
只支持一路通话的SIP话机，需要NAT映射3个端口。
前面三种的NAT，可统称为非对称的NAT。非对称的NAT，都可以用STUN协议穿过NAT。

将对称的NAT，通过端口转发的方式，变为完全圆锥体的NAT，是解决NAT问题的最好办法。首先应当用这种办法来解决。没有办法映射端口，再想其它的办法。当然，建议大家不要买那种不能够映射端口的宽带路由器，那样的路由器太差了。

继续阅读《最近在研究VOIP，贴篇文章，使用STUN穿越NAT》的全文内容...

分类: 分享 | Tags: | 添加评论(0)

还没有相关文章，您来说两句？

junos generate 与 aggregate 汇总

godupgod@163.com (godupgod) — Wed, 23 Dec 2009 21:39:20 +0800

创建aggregate路由可以使用两种方法：[edit routing-options]

aggregate
generate

而两者最大的区别在于对待下一跳问题的处理上面：
Aggregate Routes路由的目的，仅仅为了将已经存在于本地路由表的路由手工汇总成一条单一路由表示，而并非为了在本地路由器上充当到达汇总路由网段的数据转发。所有到达汇总路由网段的数据流应当依赖本地的明细路由根据最长匹配原则转发，因此Aggregate Routes路由的下一跳为reject，或者是可选的discard。
Generate Routes路由的角度上而言，其目的除了对路由进行汇总以外，同时也作为到达汇总目标网段的最后求助网关，因此Generate Routes路由存在一个确实的下一跳IP地址。该地址为Generate Routes的Contributing Routes当中数字最小的路由下一跳(对于单一路由协议而言)，同时该Contributing Routes被认为是Primary Contributing Routes。
此外，对于Generate Routes，成为其Contributing Routes还有一个限制，所有下一跳为discard或者reject的路由均不能成为合法的Contributing Routes。
实际上，JUNOS路由表将它们两者当作同属Aggregate协议的路由来对待，并且两者在Juniper JUNOS路由表当中的Preference均为130.

注意：

他们的区别是，一个的下一条是reject或discard，另一个的下一条是详细条目的某个下一条（一般是选详细条目中，prefix最小的next-hop，也就是Primary Contributing Route），所以，一般generate比aggregate安全。
generate对本地对外通告的路由不能进行汇总，只能汇总从邻居学到的路由，默认的网关就是学到的路由的下一条。

aggregate

generate

继续阅读《junos generate 与 aggregate 汇总》的全文内容...

分类: Juniper | Tags: | 添加评论(0)

还没有相关文章，您来说两句？

IS-IS 路由协议

godupgod@163.com (godupgod) — Tue, 22 Dec 2009 21:36:51 +0800

1. 前言

为什么要学习IS-IS路由协议，这是我们学习一个协议前要了解的。IS-IS路由协议与OSPF路由协议都是链路状态路由协议，他们不但适合应用于LAN的环境，而且更多使用在城域网的环境中，目前城域网技术的发展有三个主流方向，即IP城域网技术、城域以太网技术、光城域网技术。在IP城域网中关键技术包括路由技术、端到端的QoS管理、接入网技术和用户/业务管理。在路由技术中最常用的就是BGP、OSPF和IS-IS三种路由协议。如果想了解城域网的知识，所以需要先学习IS-IS路由协议。

2. OSI与CLNS概述

OSI（Open System Interconnect）参考模型是一个国际化标准，用于增强不同厂商设备之间的互操作性。它定义了一个7层的模型，并且详细规定了各层的功能，同时也确定了计算机网络的标准。

制定OSI七层参考模型的是ISO（International Organization for Standardization，国际标准化组织）。对于数据通信和信息技术的发展来说，OSI参考模型起到了重要的作用。它提供了开放式的标准架构，使不同厂商生产的通信设备之间可以进行互联和互操作。ISO七层模型的每一层都定义了单一的功能，可以将相关功能组合成功能层，从而简化和方便了协议的设计。

OSI参考模型中的网络服务规范定义了网络设备之间使用无连接通信的功能，也就是CLNS（Connectionless Network Service，无连接网络服务）。顾名思义，使用CLNS，无需在发送数据之间建立端到端的路径。下图中展示的是CLNS中所包括的协议组件，这些协议组件都由ISO所定义。

正如上图所示，CLNP（Connectionless Network Protocol，无连接网络协议）、IS-IS、ES-IS（End System—Intermediate System，终端系统—中间系统）都是ISO定义的独立的OSI第三层（网络层）的协议，这些协议分别在不同的ISO标准中定义：

CLNP：在ISO 8473中定义，定义了CLNS所使用的协议。
IS-IS：在ISO 10589中定义，定义了在使用CLNP的网络中，中间系统与中间系统间进行路由信息的交换方式。
ES-IS：在ISO 9542中定义，定义在使用CLNP的网络中，终端系统与中间系统间进行路由信息交换的方式。

CLNP这个名词可能很多人都比较陌生，它是一个OSI网络层协议。打个比方来说，它就相当于我们所熟悉的IP协议，而IP定义为用来为TCP/IP协议栈提供网络层服务。与IP一样，CLNP也是一个无连接的协议，不提供可靠的数据连接，而且也独立于下层（数据链路层）协议。我们都知道，IP是TCP/IP协议栈中唯一的网络层协议，高层的协议和数据全都封装在IP数据包中进行传输。这不同于CLNS网络环境，在CLNS中，CLNP、IS-IS、ES-IS都是独立的网络层协议，它们都直接被封装到数据链路层的帧中进行传输。

如同IP一样，CLNP也有一套自己的寻址体系，我们称之为CLNP地址。CLNP地址的结构和寻址方式与我们熟悉的IP地址有着很大的差别。

在OSI术语中，主机（例如PC）被称为ES（终端系统），路由器被称为IS（中间系统）。ES-IS可以说是一种终端系统和路由器之间的“语言”或路由协议。它用来使同一网段或链路的终端系统和路由器之间可以彼此发现对方，并可以让ES能够获悉其网络层地址。总结来说，ES-IS主要有以下几种功能：

使ES获悉其所在的区域，即区域前缀
在ES与IS之间建立邻接关系
建立数据链路层地址到网络层地址（CLNP地址）的映射

可以看出，ES-IS在CLNS网络环境中的作用就好像IP网络中的ICMP、ARP与DHCP协议的协同工作。

在ES-IS工作过程中，终端系统通过发送ESH（ES Hello）报文到特定的地址，目的是向路由器通告自己的存在。路由器通过监听ESH报文，以发现网络中存在的ES，以便后续将到达特定ES地址的数据包转发给ES。

在ES-IS中，路由器通过发送ISH（IS Hello）报文到特定地址，也向ES通告其自身的存在。ES也监听ISH，如果收到多个IS发送的ISH，ES将随即进行选择，并将所有数据都发送给这个IS。

需要注意的是，通常我们的终端系统，例如PC，都不使用ES-IS，因为这些PC都运行的是TCP/IP协议栈，类似ES-IS的工作都由TCP/IP协议栈中的ARP、ICMP、DHCP协议来完成。

下图所示为CLNS中ES-IS的工作机制：

IS-IS是CLNS中一个重要的组成部分，它是一个用来在CLNS网络环境中使路由器与路由器（IS与IS）之间动态的交换路由信息的协议，IS-IS在ISO 10589中进行了定义。IS与IS，即路由器与路由器之间的通信使用IIH（IS-IS Hello）报文。IS-IS的设计主要是为了满足CLNS网络中的如下需求：

在路由域内执行路由选择协议功能
为网络提供最佳路由
当网络出现故障后，能够快速的收敛
提供无环路的网络
提供网络的稳定性
提供网络的可扩展性
合理利用网络资源

为了满足如上需求，IS-IS被设计成一种链路状态路由协议，并且使用SPF最短路径优先算法以实现快速的收敛和无环路网络。

之前所提到的IS-IS，它仅支持CLNS网络环境，而不支持IP网络环境中的路由信息交换。后来，IETF在RFC 1195中对IS-IS进行了修改和扩展，称之为集成IS-IS（Integrated IS-IS）或双重IS-IS（Dual IS-IS）。集成IS-IS的制定是为了使其能够同时应用在TCP/IP网络和OSI网络中，使其能够为IP网络提供动态的路由信息交换。

集成IS-IS是一个能够同时处理多个网络层协议（例如IP和CLNP）的路由选择协议。相反，OSPF只支持IP一种网络层协议，即OSPF仅支持IP路由。而集成IS-IS可以支持纯CLNP网络或纯IP网络，或者同时支持CLNP和IP两种网络环境，并为其提供路由功能。集成IS-IS协议经过多年的发展，已经成为一个可扩展的、功能强大的、易用的IGP路由选择协议，并且在运营商网络中得到了更多的应用和部署，主要用来实现域内的IP路由选择。

3. OSI路由选择

OSI规范中定义了四种路由选择级别，分别为L0、L1、L2和L3。

L0路由选择

L0路由选择是发生在ES与IS之间的，它通过使用ES-IS进行路由信息的交换。正如之前介绍ES-IS那样，ES通过侦听IS发送的ISH报文来获知IS的存在。当ES要向其他ES发送信息是，它将把数据包发送到IS。同样，IS也侦听ES发送的ESH报文以获知ES的存在，当有数据包要发送个某个ES时，它便根据通过ESH获取到的信息发送个特定的ES。这个过程就称为L0路由选择。

L1路由选择

从图中可以看出，L1路由选择发生在同一区域内的IS之间。所谓区域是指在CLNP地址中拥有相同区域前缀的一组ES和IS。这里的区域概念与OSPF中的区域非常相似。同一个区域中的IS之间通过交换路由信息后，便得知了本区域内的所有路径。当IS收到一个到目标地址是本区域内地址的数据包后，通过查看数据包的目的地址以将数据包发往正确的链路或目的地。可以看到，L1路由也就是区域内的路由选择。

L2路由选择

当IS收到一个目的地址不是本区域的数据包时，数据包将被转发到其他区域的IS，其他区域的IS再将其转发到正确的目的地或者将数据包中继到其他区域，以便由其他区域的IS转发到正确的目的地。这样的路由被称作L2路由选择，可以看到，L2路由选择是发生在区域之间的，所以也称作区域间路由。

L3路由选择

了解了L0、L1、L2路由选择后，我们已经可以猜测出L3路由选择的作用了，L3路由选择就是域间的路由。L3路由选择类似与IP路由中的BGP（Border Gateway Protocol，边界网关协议），它的目的是在不同的路由域或自治系统（AS，Autonomous System）间交换路由信息，并将去往其他自治系统的数据包转发到正确的自治系统以便到达最终目的地。这些自治系统之间可能拥有不同的路由拓扑，所以不能直接进行路由信息的交换。通常L3路由选择都是由IRDP（Inter-Domain Routing Protocol，域间路由选择协议）来完成的，IRDP的功能类似于IP路由中的BGP路由协议。

4. IS-IS路由选择

IS-IS所完成的路由功能就是L1和L2路由选择，也就是说IS-IS用来在同一个路由域内进行区域内和区域间的路由选择。

IS-IS路由选择分为两个等级，即L1和L2。IS-IS区域中的L1路由选择负责路由到区域内的终端系统（ES）和IS。在同一个路由选择区域中，所有设备的区域地址都相同。区域内的路由选择是通过查看地址中的系统ID后，然后选择最短的路径来完成的。

L2路由选择是在IS-IS区域之间进行的。路由器通过L2路由选择获悉L1路由选择区域的位置信息，并建立一个到达其他区域的路由表。当路由器收到数据包后，通过查看数据包的目标区域地址（非本区域的区域地址），选择一条最短的路径来路由数据包。

由于IS-IS负责L1和L2等级的路由，IS-IS路由器等级（或称IS-IS路由器类型）可以分为三种：L1路由器（Level 1）、L2路由器（Level 2）和L1/2（Level 1/2）路由器。

L1路由器

属于同一个区域并参与Level 1路由选择的路由器称为L1路由器。L1路由器类似于OSPF中的非骨干内部路由器。在CLNP网络环境中，L1路由选择负责收集本区域内所有主机和路由器的信息，可以说L1路由器只关心本区域的拓扑结构。L1路由器将去往其他区域的数据包发送到最近的L1/2路由器上。

L2路由器

属于不同区域的路由器通过实现Level 2路由选择来交换路由信息，这些路由器成为L2路由器或骨干路由器。L2路由器类似于OSPF中的骨干路由器。在CLNP网络环境中，L2路由器与其他L2或L1/2路由器交换区域前缀信息。对于IP网络环境，在L1路由选择中，仅在区域内交换IP前缀信息，而不同区域的IP前缀信息由连接到骨干区域的执行L2路由选择的路由器交换。

L1/2路由器

同时执行L1和L2路由选择功能的路由器为L1/2路由器，L1/2路由器类似于OSPF中的ABR（区域边界路由器），它的主要职责是搜集本区域内的路由信息，然后将其发送给其他区域的L1/2路由器或L2路由器；同样，它也负责接收从其他区域的L2路由器或L1/2路由器发来的区域外信息。可以说所有L1/2路由器与L2路由器组成了整个网络的骨干（Backbone）。

此外，需要注意的是，对于IS-IS来说，骨干必须是连续的，也就是说具有L2路由选择功能的路由器（L1路由器或L1/2路由器）必须是物理上相连的。

总结这三种类型的路由器的作用，可以归纳为：

L1路由器负责收集区域内的路径信息
L2路由器负责收集区域间的路径信息
L1/2路由器负责收集区域内和区域间的路径信息，这类似与OSPF中的ABR

5. IS-IS与OSPF对比

1、IS-IS与OSPF的相同点

从IS-IS与OSPF的功能上讲，它们之间存在着这么大的相似之处，虽然它们在结构上有着差异：

IS-IS与OSPF同属于链路状态路由协议。作为链路状态路由协议，IS-IS与OSPF都是为了满足加快网络的收敛速度、提高网络的稳定性、灵活性、扩展性等这些需求而开发出来的高性能的路由选择协议。
IS-IS与OSPF都使用链路状态数据库收集网络中的链路状态信息，链路状态数据库存放的是网络的拓扑结构图，而且区域中的所有路由器都共享一个完全一致的链路状态数据库。
IS-IS与OSPF都使用泛洪（flooding）的机制来扩散路由器的链路状态信息。
IS-IS与OSPF都使用相同的报文（OSPF中的LSA与IS-IS中的LSP）来承载链路状态信息。
IS-IS与OSPF都分别定义了不同的网络类型，而且在广播网络中都使用指定路由器（OSPF中的DR，IS-IS中的DIS）来控制和管理广播介质中的链路状态信息的泛洪。
IS-IS与OSPF同样都是采用SPF算法（Dijkstra算法）来根据链路状态数据库计算最佳路径。
IS-IS与OSPF同样都采用了分层了区域结构来描述整个路由域，即骨干区域和非骨干区域。
基于两层的分级区域结构，所有非骨干区域见的数据流都要通过骨干区域进行传输。
IS-IS与OSPF都是支持VLSM（Variable Length Subnet Mask，可变长子网掩码）和CIDR（Classless Inter-Domain Routing，无类域间路由）的IP无类别路由选择协议。
IS-IS与OSPF都是标准协议。

2、IS-IS与OSPF的不同点

区域设计

OSPF的骨干区域就是区域0（Area 0），是一个实际的区域。IS-IS与OSPF最大的区别就是IS-IS的区域边界位于链路上，OSPF的区域边界位于路由器上，也就是ABR上。ABR负责维护与其相连的每一个区域各自的数据库，也就是Area 0骨干区域数据库和Area 1非骨干区域数据库。如下图所示

IS-IS的骨干区域是由所有的具有L2路由选择功能的路由器（L2路由器或L1/2路由器）组成的，而且必须是物理上连续的，可以说IS-IS的骨干区域是一个虚拟的区域。这点与OSPF不同，虽然IS-IS中的L1/2路由器的功能相似于OSPF中的ABR，但是对于L1/2路由器来说，它只属于某一个区域中，并且同时维护一个L1的链路状态数据库和一个L2链路状态数据库，而且L1/2路由器不像OSPF中的的ABR，可以同时属于多个区域中。与OSPF相同的是，IS-IS区域间的通信都必须经过L2区域（或者骨干区域），以便防止区域间路由选择的环路，这与OSPF非骨干区域间的流量都要经过骨干区域（Area 0）的操作是一样的。

通过上图所示的IS-IS区域可以看出，由于IS-IS的骨干区域是虚拟的，所以更加利于扩展，灵活性更强。当需要扩展骨干时，只需添加L1/2路由器或L2路由器即可，这比OSPF要灵活的多。

我们在设计IS-IS区域和路由器类型时，可以遵循以下原则：

不与骨干相连的路由器可以配置为L1路由器
与骨干相连的路由器必须配置为L2路由器或L1/2路由器
不与L1路由器相连的骨干路由器可以配置为L2路由器

纵观IS-IS与OSPF大体的功能，包括邻接关系、路由结构、链路状态操作、使用的算法等都存在着许多相似之处。但在这些相似点之中，或者说在这些基础上，IS-IS与OSPF也是存在着很多的不同点。下表中从各个方面列出了IS-IS与OSPF之间的区别。

IS-IS	OSPF
IS-IS可以支持CLNP和IP两种网络环境	OSPF仅支持IP网络环境
IS-IS所使用的数据包被直接封装到数据链路层帧中	OSPF数据包被封装在IP报文中
IS-IS是ISO CLNS中的一个网络层协议	OSPF不是网络层协议，它运行在IP之上
IS-IS使用LSP承载所有的路由选择信息	OSPF使用不同类型的LSA承载路由选择信息
IS-IS利用TLV可以灵活的对协议进行扩展	OSPF很难进行扩展
IS-IS可以忽略不支持的TLV	网络中所有路由器都必须能够识别所有LSA
IS-IS PDU可以承载多个TLV字段，只有一个报头，节省带宽	1类、2类LSA可以承载多个IP前缀；3类、4类、5类LSA只能承载单个IP前缀，如果需要发送多个IP前缀信息，需要多个LSA
IS-IS仅支持广播类型链路与点到点类型链路	OSPF可以支持多种网络类型：广播、点到点、NBMA、点到多点和按需电路（Demand Circuit）
IS-IS邻接关系建立过程简单，仅3步	OSPF需要通过多种状态建立邻接关系
数据库同步在建立邻接关系之后	数据库同步在邻接关系建立之前
IS-IS路由器只属于一个区域，基于节点分配区域	OSPF路由器可以属于多个区域，典型的是ABR，OSPF基于接口分配区域
IS-IS的区域边界在链路上	OSPF的区域边界在路由器上
IS-IS的L1区域（非骨干区域）为末节（stub）区域，除非使用路由泄漏（Route Leaking）机制	默认情况下，OSPF非骨干区域不是stub区域，但可以配置为stub区域
IS-IS仅在点到点链路上的扩散是可靠的，在广播链路中通过DIS周期性的发送CSNP来实现可靠性	OSPF在所有链路上的扩散都是可靠的
IS-IS中没有备份DIS	OSPF中要选举BDR，以接替DR的角色
IS-IS中的DIS可以被抢占	OSPF中的DR不能被抢占
DIS以3倍的频率发送Hello PDU	DR以正常的频率发送Hello报文
默认情况下，IS-IS的LSP最大生存时间为1200s，刷新间隔为900s，而且定时器的值可调	OSPF的LSA的老化时间为3600s，刷新间隔为1800s，而且是固定值
默认情况下，IS-IS的接口cost值为10	默认情况下，OSPF的接口cost值根据带宽进行计算
默认情况下，IS-IS保持时间（holding-time）为30s，而且在建立邻接关系时不需要双方的保持时间匹配	默认情况下，OSPF的保持时间（dead-interval）为40s，而且为了建立邻接关系，必须使双方的保持时间一致
IS-IS通过将Hello PDU的大小填充至接口MTU大小来检查双方的MTU是否匹配	OSPF通过在DBD报文中嵌入接口MTU字段来检查双方的MTU是否匹配

6. IS-IS寻址

虽然IS-IS（集成IS-IS）可以用来交换IP路由选择信息，但是对于一个运行IS-IS协议的路由器来说，它必须拥有一个CLNP地址，就算只使用IS-IS进行IP路由选择信息的交换也需要这样做。因为IS-IS在交换IP路由信息时，使用的还是ISO数据包，IP路由选择信息承载在ISO数据包中，并且使用CLNP地址来标识路由器并建立拓扑表和链路状态数据库。

CLNP地址与我们熟悉的IP地址有着很大的区别。首先，CLNP地址是一种基于节点的编址方案，也就是说一个节点（路由器）只需要一个CLNP地址，而IP地址是一种基于链路或者说是基于接口的编址方案，路由器中每一个接口都需要一个IP地址以进行不同子网间的数据包路由。其次，在地址结构上，CLNP地址与IP地址也有着很大的差别。

NSAP地址

IS-IS将CLNP地址称作网络服务访问点（NSAP，Network Service Access Point），也就是常用的CLNP地址。在OSI参考模型中，每一层为高层提供特定的服务。NSAP定义了适当的服务接口，类似于IP路由器为TCP和UDP定义的协议类型。

在ISO术语中，数据链路层地址（例如LAN MAC地址、Frame-Relay DLCI等）常被称为子网连接点（SNPA，Subnetwork Point of Attachments）。由于一个网络设备可能连接多个链路，所以需要有多个SNPA地址，但是只需要一个CLNP地址。正如之前介绍ES-IS那样，ES-IS的主要功能之一就是为节点提供NSAP地址到SNPA地址的映射。

NSAP地址主要包含两个内容：

节点的CLNP地址
高层进程

NSAP地址相当于IP报头中的IP地址和上层协议。NSAP地址最长为20字节，这要比长度为固定4字节的IP地址要长的多。下图所示为一个NSAP地址的地址格式，其中包括很多域：

NSAP地址由两个主要部分组成，IDP（Initial Domain Part，初始域部分）和DSP（Domain-Specific Part，特定域部分）。

IDP又分为AFI（Authority and Format Identifier，机构和格式标识符）和IDI（Initial Domain Identifier，初始域标识符）：
AFI字段是一个取值范围为0~99的十进制数，它指定该地址的格式和分配给该地址的机构。AFI字段标识与NSAP相关的高层寻址域和DSP部分的语法。下表中列出了一些有效的AFI值。
如下表中所示，AFI值为49时表示此地址为私有地址。这类似于RFC 1918中规定的私有IP地址范围。IS-IS可以对这些地址进行路由，但不应该将这些地址通告给其他CLNP网络。其他使用AFI值为49的网络可能采用了不同的编址方案，两种不同的编址方案一起使用可能会产生编址问题。

IDI用来标识AFI下的子域。例如ISO 6523 ICD地址域有一个4位格式，而ISO DCC用3为格式标识数据国家代码。美国政府使用的ISO 6523 ICD子域的IDI值为0005和0006，即47.0005分配给美国政府的公民组织，47.0006分配给美国国防部。

AFI	地址域
37	X.121
39	ISO数据国家代码（DCC）
41	F.69
43	E.163
45	E.164
47	ISO 6523国际代码指示符（ICD）
49	本地管理（私有）

DSP由HODSP（High Order DSP，高序DSP）、ID和SEL（选择符）组成：

HODSP将域划分为多个区域。HODSP大致相当于IP子网。
ID表示系统ID（SysID），SysID用来唯一标识OSI设备。
SEL表示NSAP选择符号（NSEL），用来标识设备中的进程，它大致相当于IP中的端口或套接字。在IS-IS路由选择过程中，没有使用NSEL，所以NSEL始终保持为00。

如下所示为一个完成的20字节的NSAP地址：

在NSAP地址格式中介绍过，NSAP地址中包含了很多不同的字段，看起来有些复杂。可以将NSAP地址进行简化，其中各种字段可以归类为3个部分：区域ID、SysID和NSEL。这样解释NSAP格式就显得清晰得多了，这样的结构也称为简化的NSAP格式，如下图所示。

如上图所示，简化的NSAP地址格式中的区域ID字段包括AFI（第一个字节）和ID（SysID）前面的字段，组成了可变长度的区域地址。虽然SysID长度为1~8个字节，但是目前实现的IS-IS中，都采用了定长的6字节表示SysID。SEL（NSEL）为1字节。简化的NSAP地址最长也为20字节。

由于SysID为6字节，NSEL为1字节，那么区域地址部分可为1~13字节不等。由于1字节足够用于定义区域ID，所以在大多数的IS-IS实现中NSAP地址最小长度为8字节。

对于IP应用程序而言，在NSAP地址中，1字节定义AFI，最少2字节定义实际的区域信息，6字节定义SysID，1字节定义NSEL，所以NSAP地址最少为10字节。NSAP使用16进制格式进行配置，以AFI（十进制数值）字节开始，NSEL字节（00）结束，用点进行分隔。AFI和NSEL之间的每隔字段是4个数字（16进制中的2字节）组，用点进行分隔。相反，IP地址使用点分十进制表示法。

如下所示为在路由器中配置的NSAP地址：

NET地址

在IS-IS路由选择过程中，没有使用NSAP地址中的NSEL，所以NSEL始终保持为00。当NSEL为00时，我们就称这个NSAP地址为NET（Network Entity Titile，网络实体名）地址，NET地址用来唯一地表示IS-IS路由选择域中的OSI主机。路由器使用NET地址来标识自己。

路由器在发送的链路状态数据包（LSP）中用NET来标识自己，这类似于OSPF发送的LSA中的路由器ID（Router ID）。

在NET地址中，还有三个与其相关的术语：SNPA、电路ID（Circuit ID）和链路。之前已经提到过，在ISO术语中，数据链路层地址常被称为子网连接点（SNPA，Subnetwork Point of Attachments）。

SNPA通常为：

LAN接口的MAC地址。
X.25、或ATM的虚电路（VC）ID，或Frame-Relay中的DLCI（数据链路标识符）。
对于HDLC（高级数据链路控制）接口，SNPA被设置为“HDLC”。

术语电路相当于接口。由于NET地址用来标识整个设备（路由器），所以Circuit ID用来表示不同的接口。路由器按照如下方式为接口指定1字节的Circuit ID。

对于点到点接口，SNPA是电路的唯一标识符。例如在HDLC点到点链路上，电路ID为0x00。
对于LAN接口，将1字节的电路ID附加到6字节的指定中间系统（DIS）的SysID的后面，例如aabb.ccdd.eeff.01。

术语链路是位于两个IS（路由器）之间的路径，当两个相邻的SNPA可以通信是，链路就处于UP状态。

系统ID（SysID）

已经了解到SysID是NSAP地址的三个重要组成部分之一，另外两个部分是区域地址和NSEL。根据ISO 10589中的规定，SysID长度可以为1~8个字节。但是目前实现的IS-IS中，都遵循GOSIP2.0标准采用了定长的6字节表示SysID。6字节的长度也与LAN MAC地址的长度一致。所以在配置路由器的NET地址时，可以使用路由器上某个LAN接口的MAC地址作为SysID，也就是在三层的NSAP地址中嵌入一个二层的MAC地址。但SysID也可以不为MAC地址，也可以取其他的任意值，但要满足6个字节的长度。

定义SysID时，需要注意以下几点：

IS-IS路由域中的每个节点的SysID必须唯一。
IS-IS路由域的所有节点的SysID长度必须一致，通常都为6个字节。
在同一区域中的每个节点的SysID必须唯一。

如果两台路由器属于不同的区域，并且都没有参与到L2的路由选择中，那么就不需要SysID唯一。但如果这两台路由器都连接到L2骨干区域中，即参与L2路由选择，那么就需要保持SysID唯一。但是推荐按照第一条中描述的，保证IS-IS路由域中的每个节点的SysID都唯一。以免产生路由信息计算问题。

在配置路由器NET地址中的SysID时，有几种方法可行。

第一就是使用LAN接口的MAC地址作为SysID，由于MAC地址是唯一的，所以这样设置可以保证SysID在整个域中都唯一。
第二种方法就是将IP地址转化成SysID，使用这种方式时通常都使用Loopback接口的地址。具体方法是将带0的淀粉十进制环回IP地址转换成12字符的地址，然后吧12个字符4个数字为一组，分为3组，以点隔开，以十六进制形式表示6字节的SysID。以下是一个将IP地址转换为SysID的例子。

假设路由器有一个Loopback接口，IP地址为192.168.1.11，转换步骤如下：

对于点分十进制环回IP地址的每一个字节不够3为数字的，使用0在前面进行填充，以补足3为，也就是将192.168.1.11转换为192.168.001.011。

此时IP地址变为了12个数字，然后按照每4个数字一组分为3组，192.168.001.011转换为1921.6800.1011。

1921.6800.1011就作为NET地址中的SysID字段，再加上区域地址和NSEL（00）后便形成了NET地址。

假设区域地址为49.0001，那么使用IP地址转换为SysID的完整NET地址就为：

49.0001.1921.6800.1011.00

由于同一区域内的所有路由器的区域地址是相同的，NSEL为00也是相同的，所以SysID成为区别路由器间不同NET地址的关键，也就是必须要保证SysID唯一。

使用多个NET地址

在ISO 10589中规定，一个节点最多可以拥有3个NSAP地址，但每个地址的SysID必须一致，不同的是区域地址。当一个运行IS-IS的路由器上具有多个NET地址时，被称为多宿主（Multihoming）。需要注意的是，多宿主并不代表路由器连接到多个区域，而是在一台路由器上配置多个具有不同区域地址的NET地址，这主要用于区域合、区域分离、重编址。

区域合并

使用多宿主功能，可以将不同区域合并到一个区域。一台L1路由器只在本区域内扩散链路状态信息，如果这台路由器连接了两个区域，那么可以实现在多个区域内扩散链路状态信息，使用这个机制，可以有效的完成区域的合并。

如下图所示，R1与R2都为L1/2路由器。R1与R2分别属于不同的区域49.0001和49.0002，之间建立了L2邻接关系，R1与R2都向L2骨干区域通告链路状态信息。现在需要将这两个区域合并为一个区域。这时可以为R1赋予两个NET地址，这两个NET地址包含不同的区域地址，分别为49.0001和49.0002，但是SysID是相同的。由于R1也具有了区域地址为49.0002的NET地址，与R2的区域地址相同，这时根据IS-IS建立邻接关系的规则，R1与R2之间也建立了一个L1邻接关系，并且拥有一个合并的L1链路数据库。最后可以将R1原先的49.0001的NET地址删除，这样就完成了区域的合并。

区域分离

区域分离的操作与区域合并的正好相反。区域分离可以将原有的一个区域分离为两个不同的区域。如下图所示，R1与R2都为L1/2路由器。起初R1和R2属于同一个区域中，都拥有相同的区域地址49.0001，之间形成了L1和L2邻接关系，共享相同的L1和L2链路状态数据库。现在需要将这两个区域分离开。与区域合并一样，可以先赋予R2两个NET地址，区域地址分别为49.0001和49.0002。之后再将R2原先区域地址为49.0001的NET地址删除，这时由于R1和R2处于不同的区域，L1邻接关系将不存在，但L2邻接关系和L2链路状态数据将保留，此时便完成了区域分离。

重编址

重编址过程与区域合并、区域分离相似，重编址可能需要清除一些或者全部路由器的区域前缀，用新的区域前缀代替。如下图所示，现在希望将原先的49.0001区域迁移到49.0002区域，这就需要更改路由器上的区域地址。R1和R2属于同一个区域49.0001中，要将R1和R2迁移到49.0002区域中，可以为R1和R2都赋予两个NET地址，两个NET地址包含不同的区域地址，49.0001和49.0002，然后依次删除R1和R2的包含49.0001区域地址的NET地址，这样就实现了路由器新的NSAP地址的无缝、无冲突的重新配置。

注意，IS-IS多宿主与IP中的辅助地址（secondanary IP）是不同的，辅助地址可以在同一条链路上创建多个隔离的逻辑子网。另外，辅助IP地址是在一条链路上配置多个子网。

NSEL

NSEL定义了网络层服务的用户，路由层是特殊的网络层服务用户，它的NSEL值为0。之前多次提到，在IS-IS路由器上配置的NSAP地址采用00作为NSEL，这时NSAP地址被称为NET。NSEL的值与IP报头中的协议类型或TCP/UDP报头中的TCP、UDP端口号类似，NSEL帮助网络层把数据发送到适当的应用程序或服务。在OSI分层模型中，网络层服务的是传输层。目标不是路由进程的CLNP数据包具有非0的NSEL值的NSAP地址，表示节点需要将数据发送到传输层。我们在使用IS-IS进行IP路由选择中，只要记住始终保持NSEL为00即可。

1. IS-IS报文结构

与OSPF一样，运行IS-IS路由选择协议的路由器也是通过收集其他路由器泛洪的链路状态信息来构建自己的链路状态数据库。在OSPF中，OSPF路由器通告链路状态信息是通过LSA（Link State Advertisment），在IS-IS中，与LSA具有同样功能的包含链路状态信息的报文称为LSP（Link State Packets，链路状态数据包）。LSP包含了由IS-IS路由器产生的描述其周围环境的路由选择信息。

在IS-IS中，路由协议使用的三大类报文：Hello报文、链路状态数据包（LSP）和序列号数据包（SNP），Hello报文用来建立和维持IS-IS路由器之间的邻接关系；LSP用来承载和泛洪路由器的链路状态信息，并且LSP（确切的说应该是链路状态数据库）是路由器进行SPF计算的依据；SNP用来进行链路状态数据库的同步，并且用来对LSP进行请求和确认。

下面所示为IS-IS中所使用的PDU数据包类型，使用这些数据包，IS-IS可以完成从邻接关系的建立、链路状态信息的扩散和链路状态数据库的同步的操作。每种PDU都有一个特定的类型号，在IS-IS的PDU报文头中，有一个PDU类型字段，此字段中所包含的信息就是PDU的类型号，路由器就是通过类型号来识别所收到的PDU报文类型。

Hello数据包分为三种类型：

L1 LAN IS-IS Hello PDU（类型号15）
L2 LAN IS-IS Hello PDU（类型号16）
点到点IS-IS Hello PDU（类型号17）

链路状态数据包LSP分为两种类型：

L1 LSP（类型号18）
L2 LSP（类型号20）

序列号数据包SNP分为四种类型：

L1完全序列号数据包（CSNP，Complete SNP）（类型号24）
L2完全序列号数据包（CSNP）（类型号25）
L1部分序列号数据包（PSNP，Partial SNP）（类型号26）
L2部分序列号数据包（PSNP）（类型号27）

a) IS-IS PDU报头格式

在所有IS-IS PDU起始的8个字节都是该数据包的头部字段，并且对于所有的PDU数据包类型（包括Hello报文、LSP和SNP）都是公用的、相同的。

下图所示为IS-IS PDU数据包起始的8个字节：

Figure . IS-IS header fields

Intradomain Routing Protocol Discriminator：域内路由选择协议鉴别符。这是ISO 9577分配给IS-IS的一个固定的值，用于标识网络层PDU的类型，对于IS-IS PDU，该字段的值永远都为0x83。
Length Indicator：长度标识符。标识该固定头部字段的长度。
Version/Protocol ID Extension：版本/协议ID扩展。当前始终为1。
ID Length：ID长度。用于表示源ID（SysID）的长度。值为0表示长度为6字节；值为255表示长度为0，即为空；1~8的整数，表示SysID具有相同长度的字节数。
PDU Type：PDU类型。这是一个5bit的字段，用于标识IS-IS数据包的类型。值为15表示L1 LAN IIH；值为16表示L2 LAN IIH；值为18表示L1 LSP；值为20表示L2 LSP；值为24表示L1 CSNP；值为25表示L2 CSNP；值为26表示L1 PSNP；值为27表示L2 CSNP。
Version：版本。当前为1。
Reserved：保留位。没有使用的bit位，始终为0。
Maximum Area Addresses：最多区域地址。表示我们可以为一个路由器配置多少个不同的区域前缀。值为0表示最多支持3个区域地址数，默认情况下值为0。
Additional Header Fields：附加报头字段。至此字段之前的8个字节对于所有的IS-IS PDU都是相同的。附加报头字段将根据不同的PDU类型而不同。
TLV Fields：TLV字段。用于承载IS-IS TLV。

如下图采集到PDU报头。

b) IS-IS Hello PDU格式

对于L1 LAN IIH PDU和L2 LAN IIH PDU，它们有着相同的报文格式和功能：

Figure 3-5. IS-IS LAN Hello (PDU Types 15, 16).

Reserved：保留的6bit位。当前没有使用，始终为0。
Circuit Type：电路类型。01表示L1路由器，10表示L2路由器，11表示L1/2路由器。
Source ID：源ID。发送该PDU的路由器的SysID。
Holding Time：保持时间。用来通知它的邻居路由器在认为这台路由器失效之前应该等该的时间。如果在保持时间内收到邻居发送的Hello PDU，将认为邻居依然处于存活状态。这个保持时间就相当于OSPF中的dead interval（死亡间隔）。在IS-IS中，默认情况下保持时间是发送Hello PDU间隔的3倍，但是在配置保持时间时，是通过指定一个Hello报文乘数（hello-multiplier）进行配置的。例如，如果Hello PDU的间隔为10s，Hello报文乘数为3，那么保持时间就是30s（10s x 3）。
PDU Length：PDU长度。整个PDU报文的长度。包括固定报头和TLV字段。
Priority：优先级。接口的DIS优先级，用来在广播LAN中选举DIS。优先级数值越高，路由器成为DIS的可能性越大。
LAN ID：局域网ID。由DIS的SysID与1字节的伪节点ID组成，LAN ID用来区分同一台DIS上的不同LAN。

如下图采集到的报文格式。

下图所示为点到点IIH PDU的报文格式：

从点到点IIH PDU的格式可以看出，大部分字段与L1/L2 LAN IIH PDU的报文格式相同。但是在点到点IIH PDU中没有“Priority”字段，因为在点到点网络上不需要选举DIS。而且使用“Local Circuit ID”代替了LAN IIH PDU中的“LAN ID”字段。

Local Circuit ID（本地电路ID）由发送Hello PDU的路由器分配给这条电路的标识，并且在路由器的接口上是唯一的。在点到点链路的另一端，Hello报文中的本地电路ID可能或也可能不为同样的值。

Figure 3-4. Point-to-Point Hello Packet (PDU Type 17).

c) IS-IS LSP PDU格式

LSP PDU分为L1 LSP和L2 LSP。L1 LSP和L2 LSP各自承载了IS-IS不同层次的路由选择信息，但是它们有着相同的报文格式。

Figure. LSP format

每个LSP都包含着这些重要的信息：LSP ID、LSP序列号、LSP校验和、剩余时间、区域关联状态、超载状态以及区域划分。

PDU Length：PDU长度。整个PDU报文的长度。包括固定报头和TLV字段。
Remaining Lifetime：剩余时间。此LSP到期前的生存时间。当生存时间为0时，LSP将被从链路状态数据库中清除。
LSP ID：LSP标识符。用来标识不同的LSP和生成LSP的源路由器。LSP ID包括三个部分：SysID、伪节点标识符（Pseudonode ID）和LSP编号。
Sequence Number：序列号。LSP序列号主要用于使路由器能够识别一个LSP的新旧版本，这也与OSPF的LSA中携带的序列号是相同的作用。
Checksum：校验和。校验和主要用于检查被破坏的LSP或者还没有从网络中清除的过期LSP。当一台路由器收到一个LSP，在将该LSP放入到本地链路数据库和将其再泛洪给其他邻接路由器之前，会重新计算LSP的校验和，如果校验和与LSP中携带的校验和不一致，则说明此LSP传输过程中已经被破坏。
P：Partition，分区。表示区域划分或者分段区域的修复位。当P位被设置为1时，表明始发路由器支持自动修复区域的分段情况。
ATT：Attached，区域关联。L1/L2路由器在其生成的L1 LSP中设置该字段以通知同一区域中的L1路由器自己与其他区域相连。通常来说就是L2骨干区域相连。当L1区域中的路由器收到L1/2路由器发送的ATT位被置位的L1 LSP后，它将创建一条指向L1/2路由器的默认路由，以便数据可以被路由到其他区域。虽然ATT位同时在L1 LSP和L2 LSP中进行了定义，但是它只会在L1 LSP中被置位，并且只有L1/2路由器会设置这个字段。
OL：Overload，超载。表示路由器的资源状态。如果该bit被置位，就表示路由器发生了超载。超载是指路由器没有足够的系统资源（CPU资源和内存资源）用来处理路由选择交换信息。被设置了超载位的LSP不会在网络中进行泛洪，并且当其他路由器收到设置了超载位的LSP后，在计算路径信息时不会考虑此LSP，因此最终计算出来的到达目的地的路径将绕过超载的路由器。设置超载位还可以使数据的传输路径绕过某个特定的路由器。
IS Type：中间系统类型。该字段表示了此LSP是来自L1路由器还是L2路由器。这也表示了收到此LSP的路由器将把这个LSP放到L1链路状态数据库还是L2链路状态数据库。01表示L1，11表示L2，00与10未使用。

下图是采集到报文。

d) IS-IS SNP PDU格式

SNP PDU分为CSNP和PSNP。其中CSNP包含L1 CSNP和L2 CSNP；PSNP包含L1 PSNP和L2 PSNP。CSNP与PSNP都包含了路由器本地链路状态数据库中LSP的摘要信息。其中CSNP包含的是所有LSP的摘要信息，PSNP包含的是部分LSP的摘要信息。下图所示为CSNP的报文格式。

Level 1/2 Complete Sequence Numbers PDU

PDU Length：PDU长度。整个PDU报文的长度。包括固定报头和TLV字段。
Source ID：源ID。发送该PDU的路由器的SysID。
Start LSP ID：起始LSP ID。表示TLV字段中描述的LSP范围的第一个LSP ID。
End LSP ID：结束LSP ID。表示TLV字段中描述的LSP范围的最后一个LSP ID。

如下图所示，是采集到的报文。

下图所示为PSNP的报文格式。

Level 1/2 Partial Sequence Numbers PDU

通过上图可以看出，PSNP报文的格式与CSNP的相似，只不过没有Start LSP ID和End LSP ID两个字段。由于PSNP携带的只是部分LSP的摘要信息，所以不需要起始和结束字段。

如下图是采集到的报文。

e) IS-IS TLV

根据不同的IS-IS PDU类型和特定的网络环境，紧跟在各种类型IS-IS PDU之后的是TLV（Type/Length/Value）字段，PDU报头与TLV字段构成了一个完整的IS-IS PDU。在ISO10589和RFC1195这二种当前IS-IS标准中，使用代码（code）这个词，而不是类型（type），但由于TLV用于其他协议标准中，故TLV比CLV在网络文献中使用的多，在这里我们也使用TVL代替CLV。在IS-IS PDU所使用的各种TLV中，既有ISO 10589中定义的，也有RFC 1195中定义的。ISO中定义的TLV用于CLNP网络环境，但是其中的大多数也用于IP网络环境。RFC中定义的TLV只用于IP环境。对于一个IS-IS PDU，后面既可以携带支持CLNP协议的TLV，又可以携带支持IP协议的TLV。如果一个路由器不能识别一个TLV，那么将忽略它。

Encoding of Variable Length Fields

如上图中所示，TLV中包括Type、Length和Value三个字段：

Code（Type）：表示TLV的类型，不同的TLV使用不同的类型号来区别，Type长度为1字节。
Length：表示TLV中Value字段的长度，长度为1字节，所以这意味着Value字段长度的最大值为255字节。
Value：表示实际承载的值，长度是可变的，最大为255字节。

下表中列出了IS-IS中所使用的各种TLV，以及这种TLV由哪种标准进行定义：

类型	TLV	ISO 10589	RFC 1195
1	区域地址	X
2	中间系统邻居（LSP）	X
3	终端系统邻居	X
4	区域分段指定L2中间系统	X
5	前缀邻居	X
6	中间系统邻居（Hello）	X
8	填充	X
9	LSP条目	X
10	验证信息	X
14	LSP缓存	X
128	IP内部可达性信息		X
129	支持的协议		X
130	IP外部可达性信息		X
131	域间路由选择协议信息		X
132	IP接口地址		X
133	验证信息		X

对于TLV 4，它用于之前我们介绍的区域修复功能；TLV 133是IETF为IP验证而定义的TLV，但是大多数实现中都使用TLV 10来支持验证。

使用TLV的最大优点就是增强了协议的扩展性，当需要扩展协议的功能时，只需要定义新的TLV就可以。下表中列出了部分IETF为增强IS-IS协议的功能所定义的一些新的TLV。

类型	TLV	RFC	作用
12	可选的校验和	3358	为SNP增加校验和
22	扩展的IS可达性	3784	增加流量工程特性，替代TLV 2
134	流量工程路由器ID	3784	增加流量工程特性
135	扩展的IP可达性	3784	增加流量工程特性和扩展度量，替代TLV 128和TLV 130
137	动态主机名	2763	增加节点标识能力，使用主机名代替SysID的显示
211	温和重启动	3847	增加温和重启动（Graceful Restart）的特性

每种IS-IS PDU都使用特定的TLV，但是有一些TLV也被多种类型的IS-IS PDU所共享，下表中列出了各种IS-IS PDU所使用的TLV：

TLV 类型	L1 LAN IIH	L2 LAN IIH	点到点IIH	L1 LSP	L2 LSP	L1 CSNP	L2 CSNP	L1 PSNP	L2 PSNP
1	X	X	X	X	X
2				X	X
3				X
4					X
5					X
6	X	X
8	X	X	X
9						X	X	X	X
10	X	X	X	X	X	X	X	X	X
128				X	X
129	X	X	X	X	X
130				X	X
131					X
132	X	X	X	X	X

从上表可以看出，唯一一个被所有IS-IS都使用的是TLV 10，验证信息。下面我们将对这些TLV中一些常用的和重要的TLV进行介绍，关于其他的TLV和扩展的TLV可以参见相应的标准文档。

1. 区域地址TLV（TLV 1）

区域地址TLV列出了始发路由器上配置的区域地址。它只出现在非伪节点LSP中。当一台路由器配置了多个区域前缀时，此TLV将携带多个区域地址。

类型——1
长度——1字节
值——nx（1字节的地址长度+可变的区域地址）

如下图所示：从采集到数据的代码中可以看到其值为十六进制01，如红框中所示。

2. 中间系统邻居TLV（LSP）（TLV 2）

中间系统邻居TLV（LSP）用于LSP PDU中，它列出了始发路由器的IS-IS邻居（包括伪节点）和到达每个邻居的链路的度量值。

类型——2
长度——1字节
值——1字节

3. 终端系统邻居TLV（TLV 3）

终端系统邻居TLV只用于L1 LSP中，它列出邻接的L1路由器和ES。例如通过ES-IS协议发现运行CLNP协议的工作站。

类型——3
长度——1字节
值——可变

4. 中间系统邻居TLV（Hello）（TLV 6）

中间系统邻居TLV用于Hello PDU中，它列出了本地路由器所有邻居的SysID。与OSPF中Hello报文中的邻居列表一样，当IS-IS路由器收到其他路由器的Hello PDU后，便将其SysID加入到自己发送的Hello PDU中。在点到点Hello PDU中不使用此TLV，因为在点到点链路中不需要选举DIS。在L1 LAN IIH中只列出L1邻居，同样在L2 LAN IIH中也只列出L2邻居。

类型——6
长度——1字节
值——可变

5. 填充TLV（TLV 8）

填充TLV用于所有Hello PDU中。为了建立邻接关系，IS-IS协议与OSPF协议一样都需要双方具有同样的接口MTU（Maximum Transmission Unit，最大传输单元）。这种保持两个邻接的路由器具有同样的MTU的机制是必需的。这样就不会产生由于双方的MTU值不匹配而导致一方不能接收另一方发送的报文。OSPF与IS-IS使用了不同的机制来检查MTU不匹配的情况。在OSPF中，通过在DBD报文中嵌入接口MTU字段使路由器检查MTU是否匹配。在IS-IS中，路由器将Hello PDU的大小填充至接口MTU的大小。由于一个TLV的长度最长为255字节，所以通常会使用多个填充TLV。

类型——8
长度——1字节
值——可变

6. LSP条目TLV（TLV 9）

LSP条目TLV只用于CSNP和PSNP报文中。它列出了每个LSP的LSP ID、剩余时间、序列号和校验和。这些字段可以唯一的标识出一个LSP的实例。

类型——9
长度——1字节
值——可变

7. 验证信息TLV（TLV 10）

验证信息TLV是唯一一个用于所有IS-IS PDU的TLV。验证信息TLV只有在配置了验证时才会使用。路由器通过将密码或者密文插入到IS-IS的PDU中实现路由选择信息交互的安全性。

类型——10
长度——1字节
值——可变

8. IP内部可达性信息TLV（TLV 128）

IP内部可达性信息TLV用于LSP PDU中。它列出了与始发LSP的路由器相直连的IP地址及掩码信息。每个IP前缀都被分配了一个度量值，这个度量值表示该IP前缀对应的链路度量值。该TLV不会出现在伪节点LSP中。

9. 支持的协议TLV（TLV 129）

支持的协议TLV用来标识始发路由器所支持的第三层网络层协议，例如仅支持CLNP、仅支持IP或同时支持CLNP和IP。

10. IP外部可达性信息TLV（TLV 130）

与IP内部可达性信息TLV一样，这类TLV也只用于LSP PDU中。它列出了IS-IS路由选择域外部的IP地址和掩码信息。这类路由信息通常都是通过路由重分发引入到IS-IS路由域中的外部路由信息。

11. 域间路由选择协议信息TLV（TLV 131）

域间路由选择协议（IRDP）信息TLV只用于L2 LSP中。IETF定义此TLV用于支持在IS-IS路由域边界上与其他域间路由选择协议的交互，用来透传来自外部路由选择协议的信息。

12. IP接口地址TLV（TLV 132）

IP接口地址TLV用于列出始发IS-IS PDU的接口的地址（IP地址）。

13. 扩展的IS可达性TLV（TLV 22）

IETF后来定义扩展的IS可达性TLV用来代替类型2的中间系统邻居TLV（LSP）。不使用IS-IS扩展度量（使用窄度量）时，只有6bit（0~63）可以用来表示度量值；当使用IS-IS扩展度量（或称作宽度量）时，这个TLV就用来代替类型2的TLV。扩展的IS可达性TLV使用24bit表示度量值，扩大了度量的取值范围。

14. 扩展的IP可达性TLV（TLV 135）

与扩展的IS可达性TLV一样，IETF定义扩展的IP可达性TLV用来代替类型128（IP内部可达性TLV）和类型130（IP外部可达性TLV）的TLV。当使用IS-IS扩展度量（宽度量）时，这个TLV就用来代替类型128和类型130的TLV。扩展的IP可达性TLV使用32bit表示度量值。

1. 链路状态数据库（LSDB）

IS-IS路由器在区域内交换LSP的过程成为链路状态扩散或链路状态泛洪（flooding）。泛洪是网络中实现链路状态数据库复制与分发的操作方式，它是链路状态路由选择协议所表现的一种重要现象。IS-IS路由器生成本地的LSP，该LSP通过启用了IS-IS协议的接口发送到所有的邻接路由器。同样，这台路由器也接收并处理其他路由器生成的LSP。如果一台路由器从邻接路由器中收到一个LSP，它将在本地链路状态数据库中保留一份该LSP的备份。之后它再把收到的这个LSP从除接收接口之外的其他运行IS-IS协议的接口泛洪出去，以便其他接口上的邻居可以收到这个LSP。在IS-IS中，点到点链路的LSP扩散与广播网络中的是不同的。

IS-IS支持两个层次的分层路由选择，层1（Level 1）路由选择和层2（Level 2）路由选择。对于这两个层次的路由选择，分别维护着不同的链路状态数据库。Level 1链路状态数据库支持对区域内的路由，Level 2链路状态数据库支持对区域间的路由。可以说，Level 1链路状态数据库是区域内所有路由器泛洪的L1 LSP的集合，Level 2链路状态数据库是整个路由域中所有L1/2路由器和L2路由器扩散到骨干区域的L2 LSP的集合。如下图所示

在一个典型的多区域IS-IS路由域中，同时存在着Level 1链路状态数据库和Level 2链路状态数据库。区域内的L1路由器维护着各自区域的Level 1链路状态数据库，Level 2链路状态数据库由具有L2路由选择功能的路由器（L2路由器和L1/2路由器）进行维护，而且所有具有L2路由选择功能的路由器都拥有一个相同的Level 2链路状态数据库。对于L1/2路由器，它同时维护着两个链路状态数据库，Level 1链路状态数据库和Level 2链路状态数据库。Level 1链路状态数据库中存放的是它所连接的非骨干区域的链路状态信息的集合，Level 2链路状态数据库中存放的是骨干区域的链路状态信息的集合。下图所示为一个典型的IS-IS多区域的拓扑中的链路状态数据库：

从上图中可以看出L1路由器只维护着一个Level 1链路状态数据库，L1/2路由器维护着两个（Level 1和Level 2）链路状态数据库。默认情况下路由器同时支持L1路由选择和L2路由选择，即L1/2类型的路由器。如果某台路由器无需参与到骨干区域的路由选择时，可以将其设置为L1路由器，这样可以节省路由器的CPU与内存资源。

当路由域中只需要采用非层次化结构就可以满足网络需求时，可以将所有路由器都部署在一个单一的区域中，这样将无需采用骨干区域以对区域间的数据流进行中转。如下图所示为采用单一L1区域的拓扑：

从上图中可以看出，单个L1区域中的路由器都只维护一个Level 1链路状态数据库，但这前提是这些路由器都是L1类型的路由器。如果按照默认情况的L1/2路由器，这些路由器之间还将建立L2邻接，并同时维护一个Level 2链路状态数据库。对于这种不需要骨干区域的拓扑，为了节省路由器的CPU和内存资源，可以将其都设置为L1路由器。

对于之前的单区域拓扑，我们也可以将所有路由器设置为L2路由器，这样所有路由器之间将建立L2邻接关系，并只维护相同的Level 2链路状态数据库。这时所有的路由器将组成了一个仅存在骨干区域的但区域拓扑。这种拓扑的优点主要是利于后续的网络扩展，很多运营商的单区域网络中都使用了全L2路由器的拓扑，以便后续区域的添加和骨干区域的扩充。如下图所示为采用单一L2骨干区域的拓扑：

运行IS-IS的路由器通过泛洪和接收链路状态数据包（LSP）进行路由选择信息的扩散和链路状态数据库的构建。LSP也是IS-IS所使用的三种报文类型之一。LSP包括两种类型，L1 LSP与L2 LSP。L1 LSP用于承载区域内路由器（L1路由器）的链路状态信息，L2 LSP用于承载区域间（骨干区域）的链路状态信息。L1 LSP只会在单个区域内进行扩散，L2 LSP将在L2骨干区域中进行扩散。

虽然L1 LSP和L2 LSP各自承载了IS-IS不同层次的路由选择信息，但是它们之间有着相似的数据包格式和功能。对于L1 LSP和L2 LSP，PDU类型分别为18和20。如下图所示。

在PDU长度（PDU Length）之前的字段，对于所有IS-IS PDU都是相同的，PDU长度之后的字段是LSP数据包所特有的。跟随在LSP报文后面的TLV字段，用来通告各种不同的路由选择信息。每个LSP都包含着如下重要的信息：LSP ID、LSP序列号、LSP校验和、剩余时间、区域关联状态、超载状态以及区域划分。如下图所示，在路由器使用show isis database命令获得的详细信息。

1. LSP剩余时间（Remaining Lifetime）

对于运行IS-IS的路由器发送的每个LSP，都有一个定时器用来跟踪LSP的生存时间。这样可以保证链路状态数据库及时的清除旧的或无效的链路状态信息。这与OSPF中的操作机制是一样的。在OSPF中，每个LSA也都有一个老化时间（age-time），默认情况下为3600s。如果一个LSA在链路状态数据库中保留的时间超过了3600s，那么此LSA将被从链路状态数据库中清除。

每个LSP都有一个最大生存时间，它是每个LSP在被从链路状态数据库中删除前可以保留的最长时间。ISO 10589中定义LSP的最大生存时间为1200s（20分钟）。当路由器一生成LSP时，便将剩余时间设置为最大生存时间，然后泛洪到所有的邻接路由器，并在本区域内进行扩散。LSP的剩余时间随着时间的推移而减少。

在IS-IS中，还存在另外一个定时器，就是LSP刷新间隔定时器。当路由器生成一个LSP后，便启动这个定时器。当刷新间隔定时器到期后，路由器将重新生成（刷新）这个LSP，并泛洪到本区域内的所有路由器。每当路由器重新生成新的LSP后，便将LSP的剩余时间重置为最大生存时间。如果某条LSP的剩余时间达到0时还没有收到生成这个LSP的路由器的刷新LSP后，这个LSP将被从链路状态数据库中清除。ISO 10589中定义LSP刷新间隔为900s（15分钟）。

可以通过调整LSP的最大生存时间和刷新间隔来影响LSP的泛洪。更大的LSP生存时间意味着路由器在其链路状态数据库中将保留LSP更长的时间，但这可能会造成过于陈旧的路由选择信息被保留更长的时间。调整LSP的最大生存时间时，也要根据实际情况相应的调整LSP刷新间隔。如果LSP刷新间隔过长，那么可能也会增加其他路由器保留陈旧路由信息的时间，但是增大LSP刷新间隔可以减少网络资源的开销。如果LSP刷新间隔过短，将增大网络资源的利用率，而且增加了路由器系统资源的开销。此外，在调整这两个定时器时，要保证LSP最大生存时间大于LSP刷新间隔，以便让路由器在将LSP清除出链路状态数据库之前有足够的时间可以接收到其他路由器重新生成的LSP。对于这两个定时器的值，推荐使用其默认值，如果不是特殊需求，可以不对其进行修改。只有在非常稳定的网络环境中才推荐使用比默认值大的LSP刷新间隔。在OSPF中，这两个定时器的值为3600s和1800s。但这里IS-IS与OSPF有一点不同的是，对于剩余时间（OSPF中的age-time），IS-IS的定时器是从最大生存时间（1200s）递减至0，而OSPF而是从0递加到最大生存时间（3600s），两个定时器在计数方法上略有不同。

2. LSP标识符（LSP ID）

路由器生成的每个LSP都有一个LSP标识符（LSP ID），LSP主要用来标识不同的LSP和生成LSP的源路由器。就像OSPF中一样，每个LSA都使用通告路由器（通告此LSA的路由器的Router ID）进行标识。每个LSP ID都包括三个部分：

SysID
伪节点标识符（Pseudonode ID）
LSP编号（LSP number）

其中SysID为路由器的系统ID，6字节长，用于标识生成此LSP的源路由器，与OSPF中的Router ID相似。

Pseudonode ID长度为1字节，用于标识此LSP是否是由网络中的指定中间系统（DIS，Designated Intermediate System）为网络产生的伪节点LSP。当LSP ID的Pseudonode ID不为0时，则表示此LSP是由DIS为网络产生的伪节点LSP，如果Pseudonode ID为0，则表示这是路由器产生的一个常规LSP。

LSP编号长度也为1字节，用于标识此LSP是否被分片。在OSPF中，使用了多种类型的LSA来通告路由信息，而在IS-IS中，路由器并不是用多种类型的LSP来通告路由信息，而是将所有路由信息都封装到一个LSP中进行传输。当LSP多大时，也就是包含的路由信息过多时，数据包将被进行分段，这与我们熟悉的IP分段是一样的。对于任何的分片操作，都是由路由器的CPU进行处理的，也就是执行进程交换，如果有过多的报文需要进行分片，那么将消耗大量的CPU资源，影响路由器的正常运行。对于分片的重组也是一样，也是要通过CPU进行处理，这样也会对接收分片的路由器造成严重的后果。IS-IS为了避免这样的问题产生，采取了一种对LSP预分段的操作机制。路由器将较大的LSP预先拆分成很多更小的LSP后再扩散出去，而无需路由器在底层对其进行分片，这样可以降低由于分片产生的负面影响。当LSP编号为0时，表示这是LSP的一个分段，编号为1时，表示这是LSP的第二个分段，以此类推。

1图是常规LSP的伪节点ID为0，并且这是LSP的第一个分段，或者未分段。2图是伪节点LSP的伪节点ID不为0。3图LSP ID的伪节点ID为0，并且LSP编号为1，表示这是一个常规LSP的第二个分段。如下图所示：

3. LSP序列号（Sequence Number）

LSP序列号是一个用4字节（32bit）进行表示的无符号整数。它的取值从0开始，每次递增1，所以取值范围为0~4294967295。当一台运行IS-IS的路由器接入到网络中后，它产生的第一个LSP的序号为1。当网络环境发生变化时，路由器将重新生成LSP，并将LSP序列号加1。同样，当到达LSP的刷新间隔后，路由器将刷新此LSP并扩散到网络中，这时LSP序列号也同样加1。可以看出，LSP序列号主要用于使路由器能够识别一个LSP的新旧版本，这也与OSPF的LSA中携带的序列号是相同的作用。

当一个路由器从故障中恢复并重新接入到了网络中，这时它也将生成一个序列号为1的LSP报文。这时区域内的其他路由器将收到这个序列号为1的LSP。如果其他路由器还未将链路状态数据库中之前由故障路由器产生的序列号较大的LSP清除，并且LSP中的内容都是相同的，这时它将认为本地链路数据库中的LSP具有更新的版本，便将扩散这个序列号较大的LSP。当恢复故障的路由器收到这个LSP后，发现自己的LSP与收到的LSP的序列号不匹配，那么它将产生一个比收到的LSP的序列号大1的LSP的副本，这样可以是LSP序列号接近于出故障前的LSP序列号的值。

4. LSP校验和（Checksum）

当路由器生成一个LSP后，为了保证LSP中信息的完整性，它将对LSP进行校验和计算，然后封装进LSP的LSP校验和字段（checksum）。校验和的计算包括从LSP中的剩余时间字段之后的字段一直到数据包的末尾，由于剩余时间是一个不断变化的字段，所以校验和计算将不包括这部分内容。校验和主要用于检查被破坏的LSP或者还没有从网络中清除的过期LSP。当一台路由器收到一个LSP，在将该LSP放入到本地链路数据库和将其再泛洪给其他邻接路由器之前，会重新计算LSP的校验和，如果校验和与LSP中携带的校验和不一致，则说明此LSP传输过程中已经被破坏。

当路由器收到了一个被破坏的LSP后，会采取一个清除的操作。它将该LSP的剩余时间设置为0然后再泛洪到网络中。当网络中的其他路由器收到这个剩余时间被置为0的LSP后，会将其本地链路状态数据库中相应的LSP清除。当产生这个被破坏的LSP的源路由器收到这个剩余时间被置为0的LSP并发现这个LSP是自己生成的后，会重新生成一个正确的LSP然后泛洪到网络中。

IS-IS的这种LSP清除操作虽然可以有效的清除网络中被破坏的LSP，给运行IS-IS路由协议的网络提供了一种自动修复的能力，但是它也带来了一种负面的影响。如果网络中的介质存在问题，就有可能产生LSP被连续破坏的现象。这些被破坏的LSP会被路由器不断的清除，同时源路由器也会不断的重新生成新的LSP，这种现象被称为LSP破坏风暴。LSP破坏风暴将消耗大量的网络资源。我们可以对路由器进行配置，使其在收到被破坏的LSP后忽略它，即丢弃被破坏的LSP，从而启动清除操作。在后续IS-IS配置章节中将介绍具体的配置方法。

5. 区域修复（Partition）

在LSP报头中最后一个字节的P（Partition）位占1bit，表示区域划分或者分段区域的修复位。当P位被设置为1时，表明始发路由器支持自动修复区域的分段情况。ISO10589中描述了如何通过建立一条穿过L2骨干网的L1路由来修复一个被隔离的L1区域。这种方式利用了每个区域与骨干网之间的连通性以及骨干网的连接性在骨干网中重新连接区域从而建立一条修复路径。这主要通过在每个区域中选举出一个具有L2路由功能的路由器作为区域指定的L2中间系统并在区域间建立一个被称作虚链路或虚连接的特殊邻接关系来实现。虚链路实现了穿过骨干网的L1修复路径。但是目前大多数的实现都不支持此区域修复功能。

如上图所示，区域2中，由于最下方的两个L1路由器间的链路故障，导致了整个L1区域被分离，使得路由信息不能正常交换。通过在骨干区域（Backbone）区域中建立一条虚链路（粗线表示）来连接两个被分离的L1区域，逻辑上修复了被分离的L1区域，使得区域内信息可以正常交换。

6. 区域关联（Attached）

在LSP报头中最后一个字节的ATT（Attached）位占4bit，表示区域关联位。L1/2路由器在其生成的L1 LSP中设置该字段以通知同一区域中的L1路由器自己与其他区域相连。通常来说，这就意味着这个路由器与L2骨干区域相连。ATT位中的4bit用来表明相连的区域是使用哪一种度量方式。如下图所示。

第4位：默认度量
第5位：延迟度量
第6位：开销度量
第7位：差错度量

在IS-IS与OSPF中，将骨干区域的路由（OSPF中的Area 0，IS-IS中的L2区域）通告到非骨干区域（OSPF中的非Area 0区域，IS-IS中的L1区域）的方式是不同。在OSPF中，连接Area 0和非骨干区域的ABR通过3类LSA（Network Sumary LSA，网络汇总LSA）将路由器从骨干区域通告到非骨干区域。但对于IS-IS来说，L1/2路由器从来不会将路由从L2骨干区域通告到L1区域。如果是这样，那L1区域中的路由器是如何得知区域外的路由器信息？如何将数据发送到其他区域？

在ISO 10589中，定义IS-IS的非骨干区域为末节区域（Stub Area），我们可以把IS-IS的L1区域想象成OSPF中的完全末节区域。OSPF的完全末节区域不允许区域外路由和外部路由（来自其他路由域）的进入，完全末节区域中的路由器通过ABR通告的一条默认路由作为外出区域的路径。同样，IS-IS的L1区域中的路由也是通过一条指向L1/2路由器的默认路由将数据路由到其他区域。当L1区域中的路由器收到L1/2路由器发送的ATT位被置位的L1 LSP后，便知道生成此LSP的路由器与其他区域（L2骨干区域）相连，即一个L1/2路由器，这时它将创建一条指向L1/2路由器的默认路由，以便数据可以被路由到其他区域。

对于上述的这种操作方式，非骨干区域中的路由器对区域外的拓扑一无所知，只是单纯的依靠默认路由将数据转发到其他区域，在通向区域外有多个出口时，这可能会产生次优路径的选择。在RFC 2966中定义了一种可以将L2路由通告到L1区域的操作方式，术语称之为“路由泄漏（Route Leaking）”。使用路由泄漏机制，可以使L1/2路由器以受控的方式将特定的L2路由通告到L1区域中，以避免次优路径的选择。

虽然ATT位同时在L1 LSP和L2 LSP中进行了定义，但是它只会在L1 LSP中被置位，并且只有L1/2路由器会设置这个字段。

7. 超载（Overload）

在LSP报头中最后一个字节的OL（Overload）位占1bit，表示超载位。此位用来表示路由器的资源状态。如果该bit被置位，就表示路由器发生了超载。超载是指路由器没有足够的系统资源（CPU资源和内存资源）用来处理路由选择交换信息。被设置了超载位的LSP不会在网络中进行泛洪，并且当其他路由器收到设置了超载位的LSP后，在计算路径信息时不会考虑此LSP，因此最终计算出来的到达目的地的路径将绕过超载的路由器。设置超载位还可以使数据的传输路径绕过某个特定的路由器。

当路由器的系统资源不足时将会自动在发送的LSP中设置超载位，或者可以通过特定的命令可以手工设置超载位。

8. 中间系统类型（IS Type）

在LSP报头中最后一个字节的中间系统类型（IS Type）位占2bit，路由器的类型。该字段表示了此LSP是来自L1路由器还是L2路由器。这也表示了收到此LSP的路由器将把这个LSP放到L1链路状态数据库还是L2链路状态数据库。该2bit中01表示L1；11表示L2；00与10未使用。

2. DIS和伪节点

LSP ID中包括一部分称为伪节点标识符（Pseudonode ID），用来标识此LSP是否是由网络中的指定中间系统（DIS，Designated Intermediate System）为网络产生的伪节点LSP。

在广播类型的网络（LAN）中，IS-IS需要为每个网段选择一个指定中间系统DIS，这里的指定中间系统DIS的作用与OSPF中的指定路由器DR的非常相似。在OSPF网络中，DR用来负责将链路状态信息泛洪到每个非DR路由器，并且帮助其进行链路状态数据库的同步。在IS-IS中也是如此，为了使链路状态信息更加准确和实时的同步给网络中的所有路由器，并且要减小带宽的利用率和路由器的处理开销，IS-IS也要在广播网络中选举出一个路由器（DIS）来达到这个目的。

在IS-IS中选举DIS的过程也是非常简单的。每个运行IS-IS协议的路由器的接口都拥有一个优先级（Priority），默认的优先级为64，同样也可以通过命令手工修改默认的优先级。路由器之间发送的Hello PDU中将携带接口的优先级信息。每个路由器收到网络中其他路由器发送的Hello PDU后，通过比较优先级来进行DIS的选举。优先级数值越大的路由器将被选举为此网段的DIS。这里与OSPF不同的是，在OSPF中，如果接口的优先级为0，那么这台路由器将被认为没有资格成为此网段的DR。在IS-IS中，如果接口的优先级为0，这仅仅表示最低的优先级，但是此路由器还拥有成为DIS的资格。当两台路由器的接口优先级相同时，那么拥有更大的SNPA（在LAN中通常为MAC地址）的接口的路由器将成为DIS。在OSPF中如果优先级相同将比较Router ID 。

在OSPF中，选举完DR后，还将选举出一个备份DR，BDR（Backup DR），以用来在原先DR出现故障时接替新的DR角色，并重新选举出BDR。但在IS-IS中，将不进行备份DIS的选举。如果DIS出现故障了，其他路由器将会重新选举出一个DIS。其次，在OSPF中，DR和BDR的选举是非抢占模式的，也就是说当有更优优先级的路由器加入到现有网络中后，也不会抢占原先DR和BDR的角色。从某种意义上来讲，在OSPF网络中，第一台启动的路由器将成为网络的DR，第二台启动的路由器将将成为BDR。与OSPF相比，DIS的选举是抢占的，即当有更优DIS资格路由器加入网络后，它会成为网络中新的DIS。这样，每次DIS的变更必须泛洪一组新的LSP。

默认情况下，运行IS-IS的路由器将以每10s的间隔发送Hello PDU。但是对于一个DIS来说，由于它在网络中起到重要的作用，所以它发送Hello PDU的间隔的频率将是其他路由器的3倍，也就是说DIS以每3.3s的间隔发送Hello PDU。这样其他路由器可以迅速检测出DIS出现故障并开始新的选举过程，增加了网络的收敛速度。

另外，在OSPF中，非DR和非BDR（DROTHER）路由器只与DR与BDR建立邻接关系（FULL关系）。但在IS-IS中，所有的路由器之间都会建立邻接关系，而不仅仅是DIS。在IS-IS网络中，每一台路由器都已组播方式发送它们的LSP数据包给所有的邻居路由器。DIS通过使用序列号数据包（SNP）来确保LSP泛洪的可靠性。关于序列号数据包的详细信息将在下面章节中进行介绍。

在ISO 10589中定义了3种类型的DIS：

L1 DIS
L2 DIS
部分指定的L2 DIS

部分指定的L2 DIS用于区域修复中，由于多数实现不支持区域修复，所以不对部分指定的L2 DIS进行介绍。

对于IS-IS来说，需要在一个网络上分别为L1和L2选举出单独的DIS，即L1 DIS和L2 DIS。对于一个接口上的优先级也分为L1优先级与L2优先级，而且这两个优先级可以不同。网络中的L1 DIS和L2 DIS可以是相同的路由器也可以是不同的路由器，即某台路由器可能是L1的DIS，但是它可能不是L2的DIS。我们可以通过命令调整接口默认的L1优先级和L2优先级来影响DIS的选举结果。

L1 DIS和L2 DIS需要为网络生成伪节点LSP，向广播网络中的所有路由器通告链路状态信息。同时L1 DIS和L2 DIS也要负责网络中的链路状态数据库的同步工作，保证网络中所有路由器都拥有一致的链路状态数据库。

在IS-IS中，整个网络被视为一个伪节点，伪节点是一个虚拟的节点，由选举出的DIS代表。使用DIS主要是为了减少广播网络中需要管理许多邻接关系的复杂性，同时利用高效的LSP扩散最小化带宽占用。伪节点是一个虚拟的节点。DIS作为伪节点的代表通过发送伪节点LSP会通告与之相连的所有路由器。伪节点LSP相当于OSPF中的2类LSA（Network LSA，网络LSA）。伪节点LSP中只包含关于邻接路由器的信息，用于建立网络拓扑图和SPF计算。

在IS-IS中，点到点类型的链路上上无需选举DIS，因为链路两端只连接两个路由器。这也与OSPF中一样，对于OSPF的点到点链路，也无需选举DR和BDR。

下表中所示为IS-IS在广播类型链路与点到点类型链路上之间操作的比较：

	广播链路	点到点链路
适用的网络类型	LAN（Ethernet等）、全互联WAN	PPP、HDCL、部分互联WAN
Hello PDU定时器	10s，DIS为3.3s	10s
Hello PDU类型	L1 IIH、L2 IIH	点到点IIH
是否使用DIS	是	否
邻接关系数	n(n-1)/2	n-1

3. 路由选择信息扩散

SNP通过描述链路状态数据库中部分或全部的LSP信息来保证路由器之间链路状态数据库的同步。此外，SNP还可以用来进行LSP的请求和确认。因此，SNP也具有类似OSPF中的LSR（Link State Request，链路状态请求）、LSAck（Link State Acknowledgement，链路状态确认）和DBD（Database Description，数据库描述）报文的作用。

SNP分为两种类型：

完全序列号数据包（CSNP，Complete Sequence Number Packets）
部分序列号数据包（PSNP，Partial Sequence Number Packets）

CSNP与PSNP具有相似的数据包格式，并且都携带了链路状态数据库中的LSP摘要信息。对于CSNP，数据包中携带了路由器链路状态数据库中所有LSP的摘要信息，而PSNP顾名思义，只携带了一部分LSP的摘要信息，CSNP和PSNP分别用于不同的操作机制中。路由器为L1和L2分别产生CSNP和PSNP，其中CSNP包含L1 CSNP和L2 CSNP，同样PSNP包含L1 PSNP和L2 PSNP。例如，L1 CSNP中包含路由器L1链路状态数据库中所有LSP的摘要信息，L2 CSNP中则包含路由器L2链路状态数据库中所有LSP的摘要信息。

所谓LSP的摘要信息，并不是某个LSP的所有内容，摘要信息只是包含了能够唯一标识某个LSP的必要的信息，这些信息是从LSP报头中提取出来的。LSP摘要信息包括：

LSP ID
剩余时间
序列号
校验和

这些字段之前都已经在介绍LSP报文结构时进行了详细的介绍。使用这些字段，路由器就可以唯一的标识出一个LSP。注意，LSP摘要信息并不包括LSP承载的具体的地址、掩码等信息，这些信息都是由TLV字段进行承载。

在广播网络中，路由器使用CSNP来保证链路状态数据库的完整性，并且只有DIS才会发送CSNP报文，DIS发送CSNP报文的间隔为10s。CSNP报文中描述了DIS的链路状态数据库中所有LSP的摘要信息。当其他路由器收到DIS发送的CSNP后，会使用CSNP中的LSP摘要信息与与本地的链路状态数据库中的LSP进行比较，进行比较的目的是确定本地链路状态数据库中的信息是否已经同步和完整。如果路由器发现本地数据库中缺少某个LSP条目，那么它将使用PSNP向DIS请求这个缺少的LSP条目。这个PSNP报文中包含就是请求的LSP条目的摘要信息。当DIS收到其他路由器发送的PSNP报文后，将会发送一个完整的LSP报文，这个LSP就是其他路由器所缺少的LSP条目。在广播网络中，DIS使用周期性的CSNP报文向网络中发送同步链路状态数据库的信号，而其他路由器使用PSNP报文来请求缺少的LSP条目。

在IS-IS的点到点类型的网络中，链路状态数据库同步的操作与广播网络中略有不同，而且路由器发送CSNP与PSNP报文的方式和其作用也有一些差别。

在点到点网络中不存在DIS，路由器不会周期性的发送CSNP报文，CSNP报文只在链路链路被激活时发送一次，而且链路两端的路由器都会发送CSNP报文以描述本地链路状态数据库中所有LSP的摘要信息。当路由器发送对端发送的CSNP中含有本地缺少的LSP信息时，也会使用PSNP报文向对端请求LSP。当对端收到PSNP报文后，将向请求方发送包含完整LSP信息的LSP报文，这点上与广播网络中的操作是相同的。但是在点到点链路上，收到LSP报文的路由器还会向对方再次发送一个PSNP报文以对之前收到的LSP进行确认。可以说，在点到点网络中的LSP交换是可靠的。这点与广播网络不同，在广播网络中路由器不使用PSNP报文对收到的LSP进行确认，而是通过DIS周期性地发送CSNP报文以弥补广播网络中不可靠的LSP交换。

在点到点链路上，路由器使用PSNP对收到的LSP报文进行确认，所以在点到点链路上是可靠的泛洪机制。

IS-IS路由协议支持两种网络类型：广播链路和点到点链路。默认情况下，IS-IS将广播网络和NBMA网络看作是广播类型。对于封装了PPP或HDCL等协议的链路看作是点到点类型。对于NBMA网络中的主接口和点到多点子接口，IS-IS将其看作是广播类型；对于NBMA网络中的点到点子接口，将其看作是点到点类型。 IS-IS不像OSPF那样，提供了对NBMA网络（例如Frame-Relay、ATM）的专门支持。对于NBMA网络，IS-IS认为其网络拓扑是PVC全互联（mesh）的，就是把它看作广播网络。但如果实际网络拓扑中并不是PVC全互联的结构时，例如部分互联的结构和Hub-Spoke结构，推荐使用点到点类型网络，即使用点到点子接口，以免造成NBMA网络中的链路状态数据库同步出现问题。

当我们使用点到点子接口将NBMA网络转化为点到点的链路时，整个NBMA网络将产生过多的PVC部分互联或全互联的网状结构，但这将产生一定的负面影响，会使网络中产生大量的LSP泛洪流量。我们都知道，运行IS-IS的路由器当接收到一个LSP报文后，会将此LSP从除接收接口以外的所有启用了IS-IS协议的接口泛洪出去，以使网络中的其他路由器都可以接收到此LSP。但是这种泛洪机制对于存在大量部分互联或全互联的网络将产生过多冗余的LSP扩散。

所谓全互联或全网状网络拓扑，是指所有路由器都与其他路由器向连接（通常是点到点子接口）。在这样的一个网络中，当一台路由器从某接口收到邻居泛洪过来的LSP后，由于它并不知道这个LSP是否已经被其他邻居路由器收到，所以会再从其他接口泛洪出去，即使其他路由器的链路状态数据库中已经存在这个LSP。如果网络中有n个路由器的话，那么网络中的每台路由器都会扩散n-2条冗余的LSP，这样总共被泛洪的多余的LSP将为（n-1）x（n-2），条而这些LSP的扩散是多余。如果每台路由器都刷新一条LSP的话，那么这个数量还将会成倍数的增长，导致了大量带宽资源的浪费。

为了解这种在全互联或高度互联的网络中出现的LSP泛洪的冗余现象，IS-IS提供了一种解决方案——IS-IS全通组，也称作Mesh组。IS-IS全通组在RFC 2973中进行了定义。所谓全通组，就是假设所有路由器之间都是完全互联的，每个路由器都会直接收到其他路由器泛洪的原始的LSP的拷贝。

可以将路由器的接口加入到某个全通组中，一个路由器上可以存在多个全通组，全通组内接口之间的LSP泛洪是受限制的，全通组之间的LSP泛洪是正常的操作，未加入全通组的接口与全通组之间也是正常的LSP泛洪操作。

以下为使用了IS-IS全通组后路由器对LSP的处理方式：

如果路由器从一个接口收到LSP后，路由器将不会把它再从与接收接口属于同一个全通组的接口泛洪出去，但路由器将向其他全通组内的接口和其他不属于全通组的接口泛洪LSP。
如果接收接口不属于任何全通组，那路由器也将向其他全通组内的接口和其他不属于全通组的接口泛洪LSP。
使用IS-IS全通组来解决高度互联的网络中的冗余LSP扩散的问题时需要注意一下几点：
全通组只是一个路由器本地的概念，接口加入的全通组也只是本地有意义的，不同路由器的mesh group编号无需保持一致，但通常推荐的做法是为全互联的一组设备使用同一个mesh group编号。
全通组的操作方式只是对于路由器收到的LSP有效，对于由路由器本地生成的LSP将按照正常的操作方式，被泛洪到所有启用了IS-IS协议的接口。
通常全互联或高度互联的网络拓扑的设计的初衷是为了提供链路的冗余性，使得当某条链路出现故障时路由器仍然可以收到泛洪的LSP。使用全通组会在一定程度上破坏了网络的健壮性，所以在部署全通组技术时应该慎重的设计全通组的结构。

4. IS-IS度量与扩展度量

1. IS-IS度量

每一种路由协议都使用度量值来衡量到达某个目的地所经路径的优劣。在RIP路由协议中，使用跳数（hop）作为路由的度量值，即到达目的地所经过的路由器的数目；在OSPF路由协议中，使用花费（cost）作为路由的度量值。而且在OSPF中，接口的花费值是通过接口的带宽计算出来的，接口带宽越大，花费值越小，也就是更有可能被选为最佳路径，OSPF的花费值与带宽是成反比的。

在IS-IS标准中，定义了四种类型的度量值：

默认度量——默认的度量类型。
延迟度量——表示链路的传输延迟。
开销度量——表示链路的开销。
差错度量——表示链路的出错概率。

虽然IS-IS定义了四种类型的度量，可以通过多种不同的方式衡量链路的可靠性，但是多数实现中，包括在锐捷路由器中，只支持默认度量。默认度量就相当于OSPF中花费（cost）值。默认度量是域中所有路由器都必须支持的。延迟度量、开销度量和差错度量都是可选类型，它们主要是为支持QoS（Quality of Service，服务质量）的路由选择而定义的。与OSPF的自动计算cost值不同（通过带宽进行计算），默认情况下，IS-IS的所有接口的cost值都为10，它不是通过带宽进行计算的。所以如果使用接口默认的cost值的话，IS-IS的度量就相当于RIP中的条数，这在包含不同链路类型和链路速度的网络中会造成次优路径的选择。

在实际网络环境中，强烈推荐根据接口的带宽修改默认的接口cost值，以避免次优路径的选择。

2. IS-IS扩展度量（宽度量）

默认情况下，IS-IS接口的cost值为10，而且在不使用扩展度量（或称窄度量）的情况下，接口的cost值的取值范围只能为0~63，即在TLV字段中（TLV类型2和TLV类型128）只能够使用6bit来表示接口度量值。显然最大值为63的接口cost将带来很大的局限性。IETF通过定义扩展的TLV类型（TLV类型22和TLV类型135）来增大度量值的取值范围。在TLV类型22中提供了24bit的度量值字段，TLV类型135提供了32bit的度量值字段。

本文转自：http://xuanbo.blog.51cto.com/499334/201504

继续阅读《IS-IS 路由协议》的全文内容...

分类: Cisco | Tags: | 添加评论(0)

还没有相关文章，您来说两句？

junos软件包操作

godupgod@163.com (godupgod) — Mon, 23 Nov 2009 21:00:43 +0800

安装JUNOS版本的顺序

在PC上安装FTP服务器
在路由器上通过ftp命令登录到FTP服务器，下载新版本的JUNOS版本到路由器硬盘
最后使用命令request system software add 进行安装

注意事项：

在request system software add命令后可以增加参数no-validate，从而不对软件包进行校验，而是直接安装（不推荐这样的操作）
从升级后的提示来看，要求升级后重启路由引擎。这里，通过show version查看，可以看到最后的JUNOS Installation Software，这个进程用来在重启路由引擎后，自动安装新版本的JUNOS。说明在运行命令software add后，只是将JUNOS软件包的相应文件放到各个目录下，但实际上还没有进行升级。所以在路由器重启前，可以通过request system software delete jinstall删除这个安装进程，从而取消安装。

路由器的JUNOS文件在安装过程中被会被复制到/var/sw/pkg下，如果路由器新JUNOS升级失败，可以通过命令request system software rollback，回滚到升级失败之前的版本。注意：在J系列上，无所升级成功或失败，都可以回滚到上一个版本，而在M和T系列上，只有升级失败，才能回滚到上一个版本，而如果升级成功，路由器会删除/var/sw/pkg目录下旧的JUNOS文件，只保留当前JUNOS软件的备份，这时rollback命令无效
这里取消安装和回滚是有区别的，取消安装只能在升级重启之前进行，回滚只能在升级重启后进行。

此外在JUNOS通过ftp下载到路由器之前，可以通过show system storage查看硬盘的大小，以便确定新的JUNOS软件的保存位置（一般可以保存在/tmp目录下）：

如果设备是带FLASH卡的，还可以在准备升级前，使用命令request system snapshot备份“/”下的文件（也就是root目录）到/altroot，备份/config到/altconfig下，从而当升级失败后，可以进行配置文件的快速回复。因为如果FLASH卡是主存储设备的话，/root和/config是保存在FLASH卡上的，而备份的/altroot和/altconfig是保存在硬盘上的，

正确的带冗余路由引擎的路由器的升级顺序（防止网络服务中断）：

在主路由引擎上关闭平滑路由引擎切换【graceful Routing Engine switchover (GRES)】
安装新的JUNOS版本在备份路由引擎上，同时保留主路由引擎的JUNOS版本不变
在确认新的JUNOS版本在备份路由引擎上正确运行后，将备份路由引擎切换为主引擎。
最后在原来的主路由引擎（现在为备份路由引擎）上安装新的JUNOS版本

继续阅读《junos软件包操作》的全文内容...

分类: Juniper | Tags: | 添加评论(0)

还没有相关文章，您来说两句？

JUNOS 路由表操作

godupgod@163.com (godupgod) — Mon, 16 Nov 2009 16:44:09 +0800

在JUNOS中，路由表被称作RIB (Routing Information Base)

不同的RIBs有不同的作用

inet.0 - IPv4 unicast routes
inet.1 - IPv4 multicast forwarding cache (incoming/outgoing interface lists)
inet.2 - IPv4 multicast RPF table
inet.3 - MPLS next-hops for BGP resolution
inet.4 - MSDP SAs
inet6.0 - IPv6 unicast routes, etc.
iso.0 - ISO routes for IS-IS.
mpls.0 - MPLS label-switched path (LSP) next hops.

将路由表inet.0中的静态路由，ospf路由，直连路由导入inet.2路由表

routing-options {
    interface-routes {
        rib-group inet if-rib;
    }
    static {
        rib-group static-rib;
    }
    rib-groups {
        if-rib {
            import-rib [ inet.0 inet.2 ];      //第一个表为主路由表
        }
        static-rib {
            import-rib [ inet.0 inet.2 ];
        }
        ospf-rib {
            import-rib [ inet.0 inet.2 ];
        }
    }
}
protocols {
    ospf {
        rib-group ospf-rib;
    }
}

想把什么协议的路由放入inet.2表中，就要在该路由协议配置层下引用rib-group rpf－table(表名)，并通过import-rib导入

这样的路由表操作，也可以是从inet.0路由表导入routing-instance的路由表中，这样做，可以用来配置类似CISCO的PBR的功能，对于某些条目，优选哪个出口，这些都是通过routing-instance配合rib进行的，因为在routing-instance中，并没有主路由表的路由信息，包括直连接口的信息，所以要将主路由表的直连路由导入routing-instance的路由表中，进行选路。

继续阅读《JUNOS 路由表操作》的全文内容...

分类: Juniper | Tags: | 添加评论(0)

还没有相关文章，您来说两句？

VPLS（Virtual Private LAN Service）

godupgod@163.com (godupgod) — Wed, 04 Nov 2009 22:09:03 +0800

VPLS即Virtual Private LAN Services（虚拟专用LAN业务），是一种在MPLS网络上提供类似LAN的一种业务，它可以使用户从多个地理位置分散的点同时接入网络，相互访问，就像这些点直接接入到LAN上一样。VPLS使用户延伸他们的LAN到MAN，甚至WAN上。

VPLS具有以下优点：

VPLS在面向用户网一侧使用以太网接口，简化了LAN/WAN边界，可以支持快速和灵活的服务部署；
VPLS将用户网络的路由策略控制和维护权利交给了用户，简化了运营商网络的管理；
VPLS服务内的所有用户路由器CE是相同子网的一部分，简化了IP寻址规划；
VPLS服务既不需要感知，又不需要参与IP寻址和路由。

VPLS主要组件：

伪电路（Pseudo Wire, PW）：简单的说，伪电路就是VC加隧道，隧道可以是LSP，L2TPV3，或者是TE。虚连接是有方向的，VPLS中虚连接的建立是需要通过信令(LDP或者BGP)来传递VC信息，然后通过VSI管理来将VC信息和隧道管理，形成一个PW。PW对于VPLS系统来说，就像是一条本地AC到对端AC之间的一条直连通道，完成用户的二层数据透传。
虚拟交换实例（Virtual Switch Instance,VSI）：每个VSI提供单独的VPLS服务。VSI实现以太桥接功能，并能够终结PW。
虚电路（Virtual Circuit,VC）：。在两个节点之间的一种单向逻辑连接。一个PW由一对反向VC组成。
接入链路（Attachment Circuit, AC）：在L2VPN中，CE通过AC接入到PE。AC可以是物理链路，也可以是逻辑链路，AC用于在CE和PE之间传输帧。
转发器（Forwarders）：PE收到AC上送的数据帧，由转发器选定转发报文使用的PW，转发器事实上就是VPLS的转发表。
信令协议（pseudowire signaling,pw），pw信令协议是vpls的实现基础，用于创建和维护pw。pw信令协议还可用于自动发现vsi的对端pe设备。目前，pw信令协议主要有ldp和bgp。
隧道（tunnel），用于承载pw，一条隧道上可以承载多条pw，一般情况下为mpls隧道。隧道是一条本地pe与对端pe之间的直连通道，完成pe之间的数据透传。

以CE1到CE3的VPN1报文流向为例，说明基本数据流走向：CE1上送二层报文，通过AC接入PE1，PE1收到报文后，由转发器选定转发报文的PW，系统再根据PW的转发表项压入PW标签，并送到外层隧道（PW标签用于标识PW，然后穿越隧道到达PE2），经公网隧道到达PE2，PE2的利用PW标签转发报文到相应的AC, 将报文最终送达CE3。

报文传送过程：

PW的创建

PW是VPLS在公网上的通信隧道，它建立在MPLS（包括普通LSP和CR-LSP）或GRE等隧道之上。创建PW需要：

首先在本端和对端PE之间建立MPLS或GRE等隧道。
确定对端PE的地址。对于同一个VSI内的PE设备，可以通过手工配置来指定对端PE地址，也可以通过信令协议自动发现对端PE。
利用LDP或BGP信令协议为PW分配多路复用分离标记（VC标签），并将分配的VC标签通告给对端PE，建立单向的VC，从而创建PW。如果PW建立在MPLS隧道之上，则PW上传输的报文将包括两层标签：内层标签为VC标签，用来判断报文属于的VC，从而将报文转发给正确的CE；外层标签为公网MPLS隧道标签，用来保证报文在MPLS隧道上的正确传输。

下面将分别介绍通过两种信令协议（LDP和BGP）创建PW的过程。

LDP信令协议

采用扩展LDP（远端LDP会话）作为PW信令协议的VPLS，称为Martini方式的VPLS。

利用LDP信令协议建立PW的过程为：

PE和特定的VSI关联后，采用LDP的DU（Downstream unsolicited，下游自主）方式主动向对端PE发送标签映射消息，该消息中包含PWID FEC和与该PWID FEC绑定的VC标签，以及接口参数（如最大传输单元等）。
如果对端PE和这个特定的PWID关联，它将接受标签映射消息，并回应自己的标签映射消息。
一对单向的VC建立成功后，它们组合起来形成双向的PW，这个双向的PW可以看作是VSI上的一个虚拟以太网接口。

Martini方式实现简单。但是LDP不能提供VPLS成员的自动发现机制，需要手工指定PE的各个对等体。新的PE加入时，每个PE上都要修改配置。

BGP信令协议

采用扩展BGP作为PW信令协议的VPLS，称为Kompella方式的VPLS。

利用BGP信令协议建立PW的过程为：

PE利用BGP的Update消息向所有对端PE设备发送VE ID和标签块信息。其中，VE ID为与PE相连的每个Site在VPN内的唯一编号，由服务供应商统一规划；标签块包含一组连续的标签。
接收到Update消息的PE设备，根据自己的VE ID和报文中的标签块，计算出唯一的一个标签值，作为VC标签。同时，接收Update消息的PE设备，根据报文中的VE ID和本地的标签块，也可以得知对端PE的VC标签值等信息。
两个PE设备互相发送Update消息，并计算出VC标签后，两台设备间的PW创建成功。

Kompella方式中，通过配置VPN Target实现了VPLS成员的自动发现，增加或删除PE时，无需手工配置，具有较好的可扩展性，但BGP协议本身比较复杂。

属性 / 信令	Kompella 方式	Martini 方式
对PE的能力要求	高	一般
是否支持自动发现	是	否
实现的复杂程度	高	低
可扩展性	好	差
标签利用率	低	高
配置工作量	小	大
跨域时的限制	小	大

MAC地址学习

以太网的特点之一是：对于广播报文、组播报文和目的MAC地址未知的单播报文，将发送给本以太网段内的所有其它端口。

在VPLS中，PSN网络模拟网桥设备，由PE进行MAC地址学习。为了能够转发报文，PE必须能够将目的MAC地址与PW进行关联。PE通过PW学到远端MAC地址，通过AC学到直接接入的MAC地址。

MAC地址学习有两种模式：

qualified：PE根据用户以太报文的MAC地址和VLAN tag进行学习，即，基于每个VSI的每个VLAN进行学习。这种模式下，每个用户VLAN形成自己的广播域，有独立的MAC地址空间。
unqualified：PE仅根据用户以太报文的MAC地址进行学习，即，基于每个VSI进行学习。这种模式下，所有用户VLAN共享一个广播域和一个MAC地址空间，用户VLAN的MAC地址必须唯一，不能发生地址重叠。

如果PE收到本地用户发出的广播流量，它将向同一VPLS的所有其它端口以及同一VPLS的所有其他PE转发广播流量。
如果PE收到远端PE发来的广播流量，它只向同一VPLS的所有直连端口转发流量，不向其他PE转发。
对于目的MAC地址为非广播地址的报文，如果PE还没有学习到该MAC地址，则PE将广播该报文。

AC上的报文封装

Ethernet接入：（又称为QinQ接入）运营商PE忽略用户报文中的 802.1Q tag，根据QinQ VLAN为用户报文选择所属VPN，此方式不用干预用户的VLAN规划，一个PE设备上允许不同CE的VLAN重叠。
VLAN接入：运营商给用户分配一个VLAN用于用户接入的VLAN，用户所有报文必须是打该VLAN的tag发送到PE，否则无法通信；此方式需干预用户VLAN规划，而且一个PE上不同CE VLAN不能重叠。

继续阅读《VPLS（Virtual Private LAN Service）》的全文内容...

分类: Cisco | Tags: MPLS VPLS | 添加评论(1)

城域网MPLS VPN的几种实现方法 (2009-11-4 9:45:42)

城域网MPLS VPN的几种实现方法

godupgod@163.com (godupgod) — Wed, 04 Nov 2009 09:45:42 +0800

一、MPLS VPN技术的发展

随着IP城域网逐步发展成为城域网建设的主流方案，具有解决企业互连能力和提供丰富业务能力的MPLS VPN技术，正在成为IP网络运营增值业务的重要手段。MPLS VPN技术可将IP网络分解为逻辑上隔离的网络，这种逻辑隔离的网络的应用可以千变万化：企业单独互连、政府办事部门单独互连、提供新业务---如为IP电话业务开辟VPN、解决IP网络地址不足、保证QoS等。

二、MPLS VPN的实现技术

1）MPLS BGP VPN

如图1所示，基于BGP扩展实现的MPLS三层VPN包含以下基本组件：

PE（Provider Edge Router）：骨干网边缘路由器，存储VRF，处理VPN-IPv4路由，是MPLS三层VPN的主要实现者。
CE（Custom Edge Router）：用户网边缘路由器，分布用户网络路由。
P router（Provider Router）：骨干网核心路由器，负责MPLS转发。
RR（Route Reflector）：BGP路由反射器。
ASBR：自治系统边界路由器，在实现跨自治系统的VPN时，与其它自治系统交换VPN路由。
MP-BGP：多协议扩展BGP，承载携带标签的IPv4/VPN路由，包括MP-IBGP、MP-EBGP。
PE-CE路由协议：在PE、CE之间传递用户网络路由，可以是静态路由，或RIP、OSPF、ISIS、BGP协议。
LDP：在PE之间建立尽力而为的LSP，经过P路由器，所有PE、P路由器均需要支持。
RSVP-TE：在VPN需要QoS保障时，在PE之间建立具有QoS能力的ER-LSP。
VRF（Virtual Routing Forwarding Table）：虚拟路由转发表，它包含同一个Site相关的路由表、转发表、接口（子接口）、路由实例和路由策略等。在PE设备上，属于同一VPN的物理端口或逻辑端口对应一个VRF，可通过命令行或网管工具进行配置，主要参数包括RD（Route Distinguish）、Import Route-Targets、Export Route-Targets、接口（子接口）等。
VPN用户站点（Site）：Site是VPN中的一个孤立的IP网络，一般来说，它不通过骨干网，公司总部、分支机构都是Site的具体例子。CE路由器通常为VPN Site中的一个路由器或交换设备，Site通过一个单独的物理端口或逻辑端口（通常是VLAN端口）连接到PE设备。

图1　基于BGP扩展实现的MPLS VPN模型

用户接入MPLS VPN后，每个Site提供一个或多个CE与骨干网的PE连接，并在PE上为该Site配置VRF，将连结PE-CE的物理接口、逻辑接口、甚至L2TP/IPSec隧道绑定到VRF上，但不可以是多跳的三层连接。

BGP扩展实现的MPLS VPN扩展的BGP NLRI的IPv4地址，在其前增加了一个8字节的RD（Route Distinguisher），用于标识VPN的成员（Site）。每个VRF可配置某些策略，规定VPN可以接收哪些Site的路由信息，可以向外发布哪些Site的路由信息。PE根据BGP扩展发布的信息进行路由计算，生成相关VPN的路由表。
通常，PE-CE之间通过静态路由交换路由信息，也可通过RIP、OSPF、BGP、IS-IS等协议，静态路由方式可以减少因CE设备管理不善等原因造成的对骨干网BGP路由的震荡，从而提高骨干网的稳定性。

MPLS BGP三层VPN适用于固定的Intranet/Extranet用户，每个Site可代表Intranet/Extranet的总部或分支机构。MPLS三层VPN的CE与PE设备之间只需要一条物理或逻辑链路，但PE设备必须保存多个路由表。如果在CE和PE之间运行动态路由协议，则PE还必须支持多实例，对PE性能要求较高。PE与PE之间需要运行BGP协议，可扩展性较差，目前可通过一个或多个路由反射器解决这一问题。对于同一AS域的VPN，必须建立运营商之间路由器IBGP连接的PE，与路由反射器建立IBGP连接即可。
MPLS BGP三层VPN可通过与Internet路由之间配置一些静态路由的方式，实现VPN的Internet上网服务，并可为跨不地域的、属于同一个AS但没有骨干网的运营商提供VPN互连，即提供"运营商的运营商"模式的VPN网络互连。

2）MPLS L2 VPN

对于MPLS二层VPN，网络运营商负责向用户提供二层的连通性，而不需参与VPN用户的路由计算。在提供全连接的二层VPN时，和传统的二层VPN一样（如ATM PVC提供的VPN），存在N方问题，每个VPN的CE到其它的CE都需要在CE与PE之间分配一条连接。对PE设备来说，当一个VPN有N个Site时，CE-PE必需有N-1个物理或逻辑端口连接。由于与用户的路由无关，二层MPLS VPN的可扩展性只与连接的VPN用户数目相关。

二层VPN可以通过MP-BGP扩展实现，也可以通过LDP扩展实现，两者草案分别为：

draft-kompella-ppvpn-l2vpn
draft-martini-l2circuit-trans-mpls

Kompella MPLS L2 VPN：

简单地说，MPLS L2 VPN就是在MPLS网络上透明地传递用户的二层。从用户角度来看，该MPLS网络就是一个二层交换网络，用户可在网络在不同站点之间建立二层连接。以ATM为例，每个用户边缘设备（CE）配置一个ATM虚电路，通过MPLS网络与远端CE设备相连，这一过程与通过ATM网络实现互联完全一样。数据

图2 L2 VPN组网示意图

在Kompella MPLS L2 VPN中，CE、PE和P的概念与BGP/MPLS VPN一样，原理也很近似，也是利用标记栈来实现用户报文在MPLS网络中的透明传送，其中外层标记（Tunnel标记）用于将报文从一个PE传递到另一个PE，内层标记（VC标记）用于区分不同VPN中的连接，接收方PE可根据VC标记决定将报文传递到哪个CE。在转发过程中，报文标记栈的变化如图3所示。

图3 L2 VPN标记栈处理

目前，Kompella L2 VPN是通过MP-BGP来实现的，它不直接对CE与CE之间的连接进行操作，而是在整个SP（Service Provider）网络中划分不同的VPN，在VPN内部对CE进行编号。在建立两个CE之间的连接时，只需要在PE上设置本地CE和远程CE的CD ID，并指定本地CE为该连接分配Circuit ID（如ATM VPI/VCI）。
与MPLS　BGP VPN一样，Kompella L2 VPN也是采用Route Target来区分VPN，因此VPN的组网具有很大的灵活性。
在标记分配方面，Kompella L2 VPN可采取标记块方式一次为多个连接分配标记。用户可以指定本地CE的范围（CE Range），表明该CE可与多少个CE建立连接，系统将一次为该CE分配一个标记块，标记块的大小与CE Range相同。这种标记方式允许用户为VPN分配一些额外的标记备用，这会造成标记资源浪费，但却可以减少VPN部署和扩容的配置工作量。

Martini MPLS L2 VPN：

Martini L2 VPN方式是通过扩展LDP来实现的，它着重解决"如何在两个CE之间建立VC（Virtual Circuit）"的问题。Martini L2 VPN采用VC-TYPE+VC-ID来识别VC，其中，VC-TYPE表明VC的类型为ATM、VLAN或PPP，而VC-ID用于唯一标志一个VC。在同一VC-TYPE的所有VC中，VC-ID在整个SP网络中具有唯一性，连接两个CE的PE通过LDP交换VC标记，并通过VC-ID将对应的CE绑定起来。
在连接两个PE的LSP建立成功，双方的标记交换和绑定完成后，一个VC就建立起来了，两个CE即可通过该VC传递二层。
为了在PE之间交换VC标记，Martini草案对LDP进行了扩展，增加了VC FEC的FEC类型。此外，由于交换VC标记的两个PE可能不是直接相连的，因此LDP必须采用Remote peer来建立session，并在该session上传递VC FEC和VC标记。数据

三、MPLS VPN技术的对比分析

表1 BGP/MPLS、Kompella L2和Martinni L2 VPN的技术对比

从表1的比较可以得出以下结论：

BGP/MPLS VPN适用于中小企业、小区、写字楼等场合，其特点是每个站点不大，站点内路由数目少，接入方式多样，网络管理能力差，以前没有使用过专线或传统VPN，可将路由外包给运营商，对运营商而言，其维护的路由数目少，开销不大。
Kompella L2 VPN适用于大型企业，其站点较大，路由数目多，接入方式比较单一，要求站点之间具有QoS保障，网络具有较强的管理能力，传统上部分企业采用过专线或传统VPN，可平稳地过渡到L2 VPN。对运营商而言，主要挑战是必须提供具有严格QoS保证的二层连接。
Martini L2 VPN配置复杂，存在N方问题，且不支持拓扑自动发现功能，扩展性差，不适于大规模应用。但是，该方式比较灵活，适于大企业内部应用，或由小型运营商提供面向局域网用户，解决以太网不能长距离传输的问题。众多以太网交换机厂商都支持这一协议，这也从一个侧面说明，这一方式还是有其存在或应用的理由，实际应用中该技术又称为EoMPLS。

继续阅读《城域网MPLS VPN的几种实现方法》的全文内容...

分类: Cisco | Tags: MPLS | 添加评论(0)

VPLS（Virtual Private LAN Service） (2009-11-4 22:9:3)

JNCIP: JUNOS OSPF虚链路配置

godupgod@163.com (godupgod) — Sat, 31 Oct 2009 21:57:21 +0800

注意：R3/R5间互联链路在OSPF区域0.0.0.3内通告，R5并未通过该链路直链OSPF骨干区域0.0.0.0

实验目标：

确保R7在R5失去到骨干网连接后仍然能够ping通区域10里面的网段；
保证R3与R5通过MD5认证建立虚链路密钥: junos, key-id: 10；
可选目标：降低骨干链路失效检测时间；使骨干区域尽快恢复；

关键点评

JUNOS OSPF虚链路上的邻居认证；
JUNOS实时流量嗅探与跟踪调试OSPF协议信息；
提升JUNOS OSPF收敛时间；

OSPF虚链路的作用在于保持骨干区域的连续性以及修复没有被直连到骨干区域的孤岛区域。另外，除了充当对现网路由状态的维护以外，也可以为保持骨干区域连续性而被应用于备份方案当中。正如实验拓扑所示，在R4与R5之间的直连链路工作正常的时候，全网并没有实现虚链路的需求。然而一旦该链路出现故障，由于R5失去到骨干区域的连接并且使OSPF的骨干区域被区域0.0.0.3分割开来。我们可以在R3与R5之间通过区域0.0.0.3建立虚链路，以保证即便R4与R5之间的直连链路出现故障，因为虚链路的存在使得R3与R5之间的链路成为R5保持到骨干区域的备份连接链路，由此可见虚链路本身实际上是一条通过穿越非骨干区域而传输骨干区域信息的隧道，并且它属于OSPF骨干区域。

更新配置：R3/R4/R5

我们需要稍微修改一下实验拓扑，将R3/R5之间的链路从区域0迁移到区域3当中，注意修改拓扑后需要重置路由器的OSPF数据库：run clear ospf database logical-router

[edit logical-routers] nigel@itaalab# delete r3 protocols ospf area 0 interface fxp1.35 [edit logical-routers] nigel@itaalab# set r3 protocols ospf area 3 interface fxp1.35 nigel@itaalab# delete r5 protocols ospf area 0 interface fxp2.35 [edit logical-routers] nigel@itaalab# set r5 protocols ospf area 3 interface fxp2.35

将R4/R5之间的链路从OSPF区域0移出，将某个接口从OSPF里面关闭可以使用deactivate或者disable参数完成：

[edit logical-routers] nigel@itaalab# set r4 protocols ospf area 0 interface fxp1.45 disable [edit logical-routers] nigel@itaalab# deactivate r5 protocols ospf area 0 interface fxp2.45

清空OSPF数据库以后，虽然R3依然可以从R5上收到LSA-3，但由于LSA-3来自区域3，而不是骨干区域，因此LAS只会停留在数据库，而并没有被安装进入R3路由表：

nigel@itaalab# run show ospf database logical-router r3 netsummary advertising-router 10.0.3.5 extensive OSPF link state database, area 0.0.0.3 Type ID Adv Rtr Seq Age Opt Cksum Len Summary 10.0.3.5 10.0.3.5 0x80000021 49 0x2 0xc751 28 mask 255.255.255.255 TOS 0x0, metric 0 Aging timer 00:59:11 Installed 00:00:45 ago, expires in 00:59:11, sent 1d 04:45:39 ago Summary 10.0.8.0 10.0.3.5 0x80000036 51 0x2 0xa75b 28 mask 255.255.254.0 TOS 0x0, metric 2 Aging timer 00:51:25 Installed 00:08:31 ago, expires in 00:51:25, sent 1d 04:45:39 ago nigel@itaalab# run show route logical-router r3 10.0.8.0/23 [edit] nigel@itaalab# run show route logical-router r3 10.0.3.5

1. JUNOS OSPF虚链路上的邻居认证

为了恢复域间路由，我们需要通过区域3建立OSPF虚链路，连接R3/R5两个接入骨干区域的ABR，从而使分割的骨干区域重新连结起来。正如上文提及，虚链路本身是骨干区域的一部分，因此，虚链路的配置应该在[edit logical-routers r3 protocols ospf area 0.0.0.0]层次下配置。另外，我们更可以通过OSPF认证在一定程度上保障虚链路的安全性。

为了保证与安全的节点建立OSPF邻接关系，以及仅将LSA限制泛洪到可信任的节点，JUNOS允许OSPF在转发的数据包中包含认证信息。JUNOS支持的认证类型包括缺省的“无认证”，明文密码认证，以及MD5加密认证。认证在Area层次等级配置，而密码则通过在该区域当中的每一个接口设置。需要注意的是，假如选择安全性更强的MD5加密认证，接受认证的双方不单要求配置相匹配的密码，同样需要共享相同的Key-ID，关于MD5其他的信息，参看RFC1321. 关于区域认证的设置需要注意JUNOS版本更新过程中的变动，在JUNOS 7.2的版本中，依然保留着在[protocols ospf area x]层次下“authentication-type”的参数。可以通过下面命令指定相关区域的认证类型为明文认证还是MD5加密认证。

set area 0.0.0.0 authentication-type md5 set area 0.0.0.1 authentication-type simple-password

然而，在OSPF认证上，JUNOS不同于IOS拥有对区域认证和链路认证之间明确的划分，由于密码总是在接口配置下进行设置，实际上控制OSPF认证是否成功的关键在于接口上配置的认证类型以及密码是否匹配；因此上面的命令在JUNOS 8.5版本上面已经被淘汰掉，我们根据实验的需求在各个接口上设置相应的密码以及认证类型即可。

根据实验需求，我们在R3和R5之间建立虚链路，并且加入MD5加密认证，下面仅列出虚链路相关部分配置：

[edit logical-routers] nigel@itaalab# show r3 protocols ospf area 0 virtual-link neighbor-id 10.0.3.5 transit-area 0.0.0.3 { authentication { md5 10 key "$9$l37v87wYojHmYgQn"; ## SECRET-DATA } }
[edit logical-routers] nigel@itaalab# show r5 protocols ospf area 0 virtual-link neighbor-id 10.0.3.3 transit-area 0.0.0.3 { authentication { md5 10 key "$9$aFGjqTz6uORz3yK"; ## SECRET-DATA } }

配置完成以后，清空OSPF数据库，重新查阅OSPF接口与邻居关系，在R5上新增了一个虚拟接口：vl-10.0.3.3，R5将使用这个虚拟接口与R3建立基于虚链路的邻居关系。另外，由于虚链路默认接口类型为点到点，因此R3和R5在虚链路上并不选举DR/BDR：

nigel@itaalab# run show ospf interface logical-router r5 Interface State Area DR ID BDR ID Nbrs lo0.5 DRother 0.0.0.0 0.0.0.0 0.0.0.0 0 vl-10.0.3.3 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1 fxp1.56 BDR 0.0.0.1 10.0.9.6 10.0.3.5 1 fxp1.57 BDR 0.0.0.1 10.0.9.7 10.0.3.5 1 fxp2.35 DR 0.0.0.3 10.0.3.5 10.0.3.3 1 nigel@itaalab# run show ospf neighbor logical-router r5 Address Interface State ID Pri Dead 10.0.2.2 vl-10.0.3.3 Full 10.0.3.3 0 36 10.0.8.5 fxp1.56 Full 10.0.9.6 128 38 10.0.8.10 fxp1.57 Full 10.0.9.7 128 33 10.0.2.2 fxp2.35 Full 10.0.3.3 128 32

重新查阅R3上的OSPF数据库，原来仅从区域3收到的由R5通告的LSA-3重新被泛洪到骨干区域当中，而且，两端路由都被安装进入路由表当中。

nigel@itaalab# run show ospf database logical-router r3 netsummary advertising-router 10.0.3.5 detail OSPF link state database, area 0.0.0.0 Type ID Adv Rtr Seq Age Opt Cksum Len Summary 10.0.2.0 10.0.3.5 0x8000006b 800 0x2 0x686e 28 mask 255.255.255.252 TOS 0x0, metric 1 Summary 10.0.8.0 10.0.3.5 0x800003de 354 0x2 0x4d0a 28 mask 255.255.254.0 TOS 0x0, metric 2 OSPF link state database, area 0.0.0.3 Type ID Adv Rtr Seq Age Opt Cksum Len Summary 10.0.3.5 10.0.3.5 0x80000026 570 0x2 0xbd56 28 mask 255.255.255.255 TOS 0x0, metric 0 Summary 10.0.8.0 10.0.3.5 0x8000003e 207 0x2 0x9763 28 mask 255.255.254.0 TOS 0x0, metric 2 nigel@itaalab# run show route logical-router r3 10.0.3.5 inet.0: 20 destinations, 20 routes (20 active, 0 holddown,0 hidden) + = Active Route, - = Last Active, * = Both 10.0.3.5/32 *[OSPF/10] 00:21:49, metric 1 > to 10.0.2.1 via fxp1.35 nigel@itaalab# run show route logical-router r3 10.0.8.0 inet.0: 20 destinations, 20 routes (20 active, 0 holddown,0 hidden) + = Active Route, - = Last Active, * = Both 10.0.8.0/23 *[OSPF/10] 00:21:56, metric 3 > to 10.0.2.1 via fxp1.35

最后，通过测试区域1与区域10之间的互通性，确认在R5失去到骨干网连接后区域1路由器仍然能够ping通区域10里面的网段：

nigel@itaalab# run traceroute 10.0.6.1 logical-router r6 traceroute to 10.0.6.1 (10.0.6.1), 30 hops max, 40 byte packets 1 10.0.8.6 (10.0.8.6) 1.906 ms 1.297 ms 1.009 ms 2 10.0.2.2 (10.0.2.2) 1.272 ms 1.482 ms 1.227 ms 3 10.0.6.1 (10.0.6.1) 1.640 ms 1.569 ms 1.604 ms [edit logical-routers] nigel@itaalab# run traceroute 10.0.6.1 logical-router r7 traceroute to 10.0.6.1 (10.0.6.1), 30 hops max, 40 byte packets 1 10.0.8.9 (10.0.8.9) 1.334 ms 1.357 ms 1.017 ms 2 10.0.2.2 (10.0.2.2) 1.259 ms 1.289 ms 1.105 ms 3 10.0.6.1 (10.0.6.1) 1.300 ms 1.600 ms 1.476 ms

JUNOS实时流量嗅探与跟踪调试OSPF协议信息

继续上文关于邻居认证的话题，要求使用MD5哈希校验加密认证的原因在于使用明文密码很容易在转发的过程中被截获。不需要额外的第三方工具，JUNOS本身内置的嗅探机制：monitor traffic相当于UNIX的tcpdump命令，便能通过实时监控接口流量捕获明文发送的密码。我们先将R5端的认证方式修改为明文认证，密码为：juniper，然后再进行监控：

[edit logical-routers r5 protocols ospf] nigel@itaalab# show area 0 virtual-link neighbor-id 10.0.3.3 transit-area 0.0.0.3 { authentication { simple-password "$9$NYVs4UjqQF/aZF/CtIR-Vw"; ## SECRET-DATA } }

提示：使用monitor traffic的时候，应该对物理接口进行监控，假如仅监控逻辑接口，你进能够获得有限的信息。通常，在监控的过程中终端会快速输出大量的数据，你可以先设置终端软件将日志记录下来，然后通过查找功能定位你希望获得的数据信息。从下面的摘录输出可以发现明文发送的密码很容易的被截获，而对于MD5密文，仅能截获到相关的Key-ID.

nigel@itaalab# run monitor traffic interface fxp1 extensive Listening on fxp1, capture size 96 bytes 06:47:16.290110 In 0:aa:0:0:1:74 0:aa:0:0:1:63 8100 82: VID [0: 135] (tos 0xc0, ttl 255, id 44498, offset 0, flags [none], proto: OSPF (89), length: 64) 10.0.2.1 > 10.0.2.2: OSPFv2, Hello (1), length: 44 Router-ID: 10.0.3.5, Backbone Area, Authentication Type: unknown (1)juniper^@" Options: [External] Hello Timer: 10s, Dead Timer 40s, Mask: 0.0.0.0 , Priority: 0 ………… 06:47:20.636209 Out 0:aa:0:0:1:63 0:aa:0:0:1:74 8100 98: VID [0: 135] (tos 0xc0, ttl 255, id 44509, offset 0, flags [none], proto: OSPF (89), length: 80) 10.0.2.2 > 10.0.2.1: OSPFv2, Hello (1), length: 44 Router-ID: 10.0.3.3, Backbone Area, Authentication Type: MD5 (2) Key-ID: 10, Auth-Length: 16, Crypto Sequence Number: 0x0001b8b7 Options: [External] Hello Timer: 10s, Dead Timer 40s, Mask: 0.0.0.0 , Priority: 0 [|ospf]

显然，尽管monitor traffic能够提供一种快速调试，定位问题所在的方法；然而显然是一种体力活，在监控OSPF路由协议信息的同时，有可能被同时通讯的其他协议的信息干扰；而且不方便将输出信息组织并形成文档。JUNOS同时提供了类似于IOS的debug ip ospf命令的工具：traceoptions,来专门对某种特定协议信息进行监控（不局限于OSPF单一协议），另一方面，traceoptions的记录是一种持续的过程，它将所有的调试信息归档到日志文件中，即便在终端上停止了对该协议的监控，相关的日志信息依然会不断在后台被添加进入日志文件当中。日志文件的位置被存放在/var/log目录(M/T系列路由器)或者/cf/var/log目录下(J系列路由器),在使用逻辑路由器进行练习的环境当中，同一个逻辑路由器上面的所有traceoptions日志文件都会被汇总到与逻辑路由器的同名目录当中。针对上面的情况，我们设置OSPF的traceoptions监控其Hello/error数据包：

nigel@itaalab# run monitor start r3/ospf-log *** r3/ospf-log *** Jul 26 07:42:36 OSPF packet ignored: authentication type mismatch (1) from 10.0.2.1 Jul 26 07:42:36 OSPF sent Hello 10.0.2.2 -> 10.0.2.1 (vl-10.0.3.5, IFL 0x0) Jul 26 07:42:36 Version 2, length 44, ID 10.0.3.3, area 0.0.0.0 Jul 26 07:42:36 checksum 0x0, authtype 0 Jul 26 07:42:36 mask 0.0.0.0, hello_ivl 10, opts 0x2, prio 0 Jul 26 07:42:36 dead_ivl 40, DR 0.0.0.0, BDR 0.0.0.0

确定认证失效信息后，我们恢复R5上的认证配置，继续下面的实验。

提升JUNOS OSPF收敛时间: hello/dead-interval vs. bfd

通过之前的实验不难发现，R4与R5之间的链路，包括R3与R4之间的链路，两条骨干网链路是整个实验网络的关键部分。通过预先在非骨干区域内创建虚链路，是一个不错的保持骨干区域连续性的备份方案。在R3与R5之间建立虚链路，更能够同时使在R4/R3/R5之间任一骨干区域链路失效后仍然能保障骨干区域的连续性。除此以外，另一个需要考虑的便是对链路失效检测的延时性能，争取在更短的时间内完成路由收敛。其中，降低OSPF Hello包的发送周期以及邻居失效周期是最常见的方式。我们可以在R3/R4/R5的骨干网接口上进行设置，需要注意的是链路两端的路由器必须设置相同的计时器值，计时器同步是形成OSPF邻接关系的必要前提。我们将三台路由器的所有骨干网接口计时器值减少为默认的50%，注意不要忘记对R3/R5之间的虚链路接口一起设置：

[edit logical-routers] nigel@itaalab# set r4 protocols ospf area 0 interface fxp2.34 hello-interval 5 dead-interval 20 [edit logical-routers] nigel@itaalab# set r4 protocols ospf area 0 interface fxp1.45 hello-interval 5 dead-interval 20 [edit logical-routers] nigel@itaalab# set r3 protocols ospf area 0 interface fxp1.34 hello-interval 5 dead-interval 20 [edit logical-routers] nigel@itaalab# set r5 protocols ospf area 0 interface fxp2.45 hello-interval 5 dead-interval 20 [edit logical-routers r3 protocols ospf area 0.0.0.0] nigel@itaalab# set virtual-link neighbor-id 10.0.3.5 transit-area 3 hello-interval 5 dead-interval 20 [edit logical-routers r5 protocols ospf area 0.0.0.0] nigel@itaalab# set virtual-link neighbor-id 10.0.3.3 transit-area 3 hello-interval 5 dead-interval 20

尽管默认情况下OSPF的dead-interval自动被调节为Hello-interval的4倍，然而还是建议（OK，这只是一个“建议”，如果非要问为什么提出这样的建议同时给予解释的话请无视 ── 你有权决定是否采纳建议，而我同样有权决定是否提供建议 ── 就那么简单的逻辑关系搞不懂怎么就有人偏搞不懂？）同时手动定义两个参数，查看R3的OSPF接口状态，可以看到全部区域0.0.0.0内全部接口的计时器值全部被修改为5/20sec，值得注意的是R3与R5之间的链路只有属于区域0.0.0.0的虚链路被修改为新的计时值，而物理接口仍然属于区域3，因此被保留为默认10/40sec不变：

nigel@itaalab# run show ospf interface logical-router r3 detail Interface State Area DR ID BDR ID Nbrs fxp1.34 BDR 0.0.0.0 10.0.3.4 10.0.3.3 1 Type: LAN, Address: 10.0.2.5, Mask: 255.255.255.252, MTU: 1496, Cost: 1 DR addr: 10.0.2.6, BDR addr: 10.0.2.5, Adj count: 1, Priority: 128 Hello: 5, Dead: 20, ReXmit: 5, Not Stub Auth type: None lo0.3 DRother 0.0.0.0 0.0.0.0 0.0.0.0 0 Type: LAN, Address: 10.0.3.3, Mask: 255.255.255.255, MTU: 65535, Cost: 0 Adj count: 0, Priority: 128, , Passive Hello: 10, Dead: 40, ReXmit: 5, Not Stub Auth type: None vl-10.0.3.5 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1 Type: Virtual, Address: 10.0.2.2, Mask: 0.0.0.0, MTU: 0, Cost: 1 Adj count: 1 Hello: 5, Dead: 20, ReXmit: 5, Not Stub Auth type: MD5, Active key ID: 10, Start time: 2008 Jan 1 07:00:00 LONT fxp1.35 BDR 0.0.0.3 10.0.3.5 10.0.3.3 1 Type: LAN, Address: 10.0.2.2, Mask: 255.255.255.252, MTU: 1496, Cost: 1 DR addr: 10.0.2.1, BDR addr: 10.0.2.2, Adj count: 1, Priority: 128 Hello: 10, Dead: 40, ReXmit: 5, Not Stub Auth type: None fxp2.13 BDR 0.0.0.10 10.0.6.1 10.0.3.3 1 Type: LAN, Address: 10.0.4.13, Mask: 255.255.255.252, MTU: 1496, Cost: 2 DR addr: 10.0.4.14, BDR addr: 10.0.4.13, Adj count: 1, Priority: 128 Hello: 10, Dead: 40, ReXmit: 5, Stub NSSA Auth type: None

尽管缩短Hello周期能在一定程度上提升OSPF的收敛速度，然而，OSPF Hello数据包可设置的最短周期为1秒，那么邻居失效周期最短也只能为4秒钟，对于那些承载着对延时极为敏感的业务的网络而言，这样的失效检测周期依然需要提升效率。JUNOS从6.1版本开始便支持能够更快的，达到微妙级别的双向转发检测，BFD（Bidirectional Forwarding Detection)，BFD是一种简单的Hello协议，然而BFD通过基于转发层面对下一跳邻居的监测 ─ 传统的IGP Hello机制是基于控制层面邻居维护，却能够有效的提升那些在传统上不存在硬件失效监测的链路，而只能依赖于IGP的Hello机制作为检测手段，如以太网络，它们对于链路失效检测的性能。同时BFD独立于各种IGP协议，不单纯能够为OSPF，并且能够为ISIS，BGP甚至MPLS提供在二层链路上的保障服务。目前，在JUNOS 8.5版本上面，我们可以测试在逻辑路由器上建立BFD会话。

[edit logical-routers] nigel@itaalab# show r3 protocols ospf area 0 virtual-link neighbor-id 10.0.3.5 transit-area 0.0.0.3 {     hello-interval 5;     dead-interval 20;     authentication {         md5 10 key "$9$vMg8xd24Zk.54a39"; ## SECRET-DATA     } } interface fxp1.34 {     hello-interval 5;     dead-interval 20;     bfd-liveness-detection {    minimum-interval 500;    } }
[edit logical-routers] nigel@itaalab# show r4 protocols ospf area 0 interface fxp2.34 {     hello-interval 5;     dead-interval 20;     bfd-liveness-detection {
    minimum-interval 500;
    }
} interface fxp1.45 {     hello-interval 5;     dead-interval 20;     bfd-liveness-detection {
    minimum-interval 500;
    }
}
[edit logical-routers]
nigel@itaalab# show r5 protocols ospf area 0 virtual-link neighbor-id 10.0.3.3 transit-area 0.0.0.3 {     hello-interval 5;     dead-interval 20;     authentication {
        md5 10 key "$9$ck.rK8-VYZUHVwPQ"; ## SECRET-DATA
    }
} interface fxp2.45 {     hello-interval 5;
    dead-interval 20;     bfd-liveness-detection {
        minimum-interval 500;     } }

BFD默认的失效时间是传输周期的3倍，在上面的配置中，我们将传输周期设置为500毫秒(ms)，链路失效时间将被自动设置为1.5秒，当然，你还可以使用multiplier来定义失效时间相对于传输周期的倍数来进一步缩短或者延长链路失效时间。BFD能够为OSPF服务，但却不像OSPF计时器需要在所有接口下面打开，我们可以按照需求在某几条特定链路的两端路由器接口上设置BFD，以下的输入确认R4上BFD的两个连接，并且确认BDF目前的为OSPF协议服务：

nigel@itaalab# run show bfd session detail logical-router r4 Transmit Address State Interface Detect Time Interval Multiplier 10.0.2.9 Up fxp1.45 1.500 0.500 3 Client OSPF, TX interval 0.500, RX interval 0.500 Session up time 00:13:15 Local diagnostic None, remote diagnostic None Remote state Up, version 1 Logical router 1, routing table index 5 Transmit Address State Interface Detect Time Interval Multiplier 10.0.2.5 Up fxp2.34 1.500 0.500 3 Client OSPF, TX interval 0.500, RX interval 0.500 Session up time 00:13:15 Local diagnostic None, remote diagnostic None Remote state Up, version 1 Logical router 1, routing table index 5 2 sessions, 2 clients Cumulative transmit rate 4.0 pps, cumulative receive rate 4.0 pps

本文转自：http://jncie.wordpress.com/2009/10/06/jncip-junos-ospf-virtual-link-configuration-1/

继续阅读《JNCIP: JUNOS OSPF虚链路配置》的全文内容...

分类: Juniper | Tags: OSPF | 添加评论(0)

还没有相关文章，您来说两句？

JNCIP案例分析 – Juniper/Cisco OSPF互操作

godupgod@163.com (godupgod) — Sat, 31 Oct 2009 21:00:46 +0800

在本案例学习的实验中，我们将模拟真实的JNCIP考试场景。并且，通过把上述的核心知识点整合在Juniper和Cisco设备的混合网络环境当中，应用你已经掌握的JUNOS和IOS的知识，能够在多厂家互联的网络环境中游刃有余的控制OPSF路由协议及各种策略。对于JNCIx备考人员来说，除了考试的难度以及陷阱以外，对配置的熟练性同时也是一大挑战之一。我们会把在前面的实验当中除接口配置以外所有的协议，策略以及跟踪调试配置删除，从头开始对案例需求的配置。完成本案例分析后，你应该进行计时训练，本实验计划达到的目标为在一个小时内完成全部配置。

实验目标

所有OSPF路由器使用环回接口地址作为RID，并且均能通过OSPF被其他路由器访问；
骨干区域内的环回接口地址应当以LSA-3的形式出现在非骨干区域内；
R1/R2之间的10.0.5/24网段路由以外部路由的形式在区域0出现；
将10.0.5/24路由的初始Metric设置为10，贴上420标签。
同时所有OSPF会根据内部开销自动调节该路由在本地的Metric值；
保证R1不会产生Network LSA（LSA-2）；
区域0.0.0.1内不会出现LSA-3或者LSA-5；
区域0使用MD5加密认证，密码为“jnx”；
汇总所有的非骨干区域路由进入骨干区域，包括内部路由以及外部路由；
汇总来自RIP路由器的192.168.x/24路由，但不能修改该路由器上的配置；
R6/R7必须将10.0.5/24路由通告给RIP路由器，同时R7上通告的RIP路由Metric应大于R6上的通告；
172.16.40/24网段以OSPF内部路由形式出现，该子网上不存在OSPF邻接；
除R5外，保证RIP路由器与10.0.5/24网段间通讯不会因为单点失效而中断；
基于带宽优化路由选择：保证所有快速以太网接口被自动分配Metric值为10，另外你需要手动调节Metric使R5到区域1的内部网段实现负载均衡；
不允许使用静态路由；
RIP路由器能使用最优路径到达10.0.5/24网段；

后台JUNOS设备RIP路由器配置

与真实考试相同，后台设备RIP路由器预配置用于配合你的实验效果，因此，案例中你根据下面配置设置好后台设备以后，不应该再登录到RIP路由器上修改相关配置。

[edit logical-routers rip] nigel@junos7.2# show protocols rip group rip { export rip; neighbor fxp2.60; neighbor fxp2.70; } [edit logical-routers rip] nigel@junos7.2# show policy-options policy-statement rip term 1 { from protocol [ rip static ]; then accept; } [edit logical-routers rip] nigel@junos7.2# show interfaces lo0 unit 8 { family inet { address 192.168.0.1/32; address 192.168.1.1/32; address 192.168.2.1/32; address 192.168.3.1/32; address 192.168.4.1/32; } } [edit logical-routers rip] nigel@junos7.2# show routing-options static { route 192.168.0.0/24 receive; route 192.168.1.0/24 receive; route 192.168.2.0/24 receive; route 192.168.3.0/24 receive; route 192.168.4.0/24 receive; }

JNCIP OSPF综合实验案例分析

我们将根据实验目标步骤，分成各部分并逐步实现与检测相关需求，对于明显需要在多个路由器上应用的类似配置，我们会使用高亮字体标出，同时应当被实现在全部关联路由器上。假如你在实验的过程中发现网络现象与我们的验证结果不符，可参照末尾附录的全部路由器的案例相关配置，核查是否在某些路由器上忽略了必要的配置。另外，为了得到更好的验证效果，在开始前我们先按照拓扑上的区域划分将路由器的接口在OSPF内发布。需要注意的是在JUNOS与IOS互联的时候由于百兆fxp接口默认MTU为1496 bytes，与IOS上快速以太网接口默认的1500 bytes不匹配，在建立OSPF邻居的时候会停留在Exchange/ExStart的状态，因此我们需要在IOS路由器上将与JUNOS相连的接口MUT值修改为与其匹配的1496 bytes。

1. JUNOS与IOS OSPF路由协议互联

所有OSPF路由器使用环回接口地址作为RID，并且均能通过OSPF被其他路由器访问；
骨干区域内的环回接口地址应当以LSA-3的形式出现在非骨干区域内；

通过手动设置骨干区域ABR – R3/R4/R5的RID，并且明确将其在OSPF区域0内通告满足以上需求。

[edit logical-routers r5] nigel@junos7.2# show routing-options router-id 10.0.3.5; [edit logical-routers r5] nigel@junos7.2# show protocols ospf area 0.0.0.0 { interface lo0.5 { passive; } interface fxp2.45; interface fxp2.35; } area 0.0.0.20 { interface fxp1.56; interface fxp1.57; }
r4#wr t ! interface Loopback0 ip address 10.0.3.4 255.255.255.255 ! interface FastEthernet0/0 no ip address duplex auto speed auto ! interface FastEthernet0/0.24 encapsulation dot1Q 24 ip address 10.0.4.9 255.255.255.252 ip mtu 1496 ! interface FastEthernet0/0.34 encapsulation dot1Q 34 ip address 10.0.2.6 255.255.255.252 ip mtu 1496 ! interface FastEthernet0/0.45 encapsulation dot1Q 45 ip address 10.0.2.10 255.255.255.252 ip mtu 1496 ! ! router ospf 64 router-id 10.0.3.4 log-adjacency-changes network 10.0.2.4 0.0.0.3 area 0 network 10.0.2.8 0.0.0.3 area 0 network 10.0.3.4 0.0.0.0 area 0 network 10.0.4.8 0.0.0.3 area 1 !

分别在JUNOS与IOS上确认OSPF邻居达到FULL状态，可以注意到JUNOS默认选举DR的优先级为128,而IOS为1；

nigel@junos7.2# run show ospf neighbor logical-router r5 Address Interface State ID Pri Dead 10.0.2.2 fxp2.35 Full 10.0.3.3 128 38 10.0.2.10 fxp2.45 Full 10.0.3.4 1 35 10.0.8.5 fxp1.56 Full 10.0.9.6 128 36 10.0.8.10 fxp1.57 Full 10.0.9.7 1 32
r4#show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 10.0.3.3 128 FULL/BDR 00:00:34 10.0.2.5 Fa0/0.34 10.0.3.5 128 FULL/DR 00:00:36 10.0.2.9 Fa0/0.45 10.0.6.2 128 FULL/BDR 00:00:39 10.0.4.10 Fa0/0.24
*注：由于篇幅所限，我将FastEthernet缩写为Fa

并且查看R6/R7数据库，确认全部骨干区域的环回接口地址均以LSA-3的形式被注入区域20，并且确认数据库内LSA-3完全同步。

nigel@junos7.2# run show ospf database logical-router r6 netsummary | match summary Summary 10.0.2.0 10.0.3.5 0x8000000d 571 0x2 0x2510 28 Summary 10.0.2.4 10.0.3.5 0x8000000b 529 0x2 0xb27 28 Summary 10.0.2.8 10.0.3.5 0x80000011 399 0x2 0xcc5c 28 Summary 10.0.3.3 10.0.3.5 0x80000007 271 0x2 0x1a1a 28 Summary 10.0.3.4 10.0.3.5 0x80000009 229 0x2 0x161a 28 Summary 10.0.3.5 10.0.3.5 0x8000000a 99 0x2 0xf53a 28 Summary 10.0.4.0 10.0.3.5 0x80000006 2329 0x2 0x2712 28 Summary 10.0.4.4 10.0.3.5 0x80000006 2199 0x2 0x92b 28 Summary 10.0.4.8 10.0.3.5 0x80000008 1429 0x2 0xdc51 28 Summary 10.0.4.12 10.0.3.5 0x80000006 2071 0x2 0xae7e 28 Summary 10.0.6.1 10.0.3.5 0x80000006 2029 0x2 0x191a 28 Summary 10.0.6.2 10.0.3.5 0x80000006 1299 0x2 0xf23 28r7
#show ip ospf database summary | include summary Link State ID: 10.0.2.0 (summary Network Number) Link State ID: 10.0.2.4 (summary Network Number) Link State ID: 10.0.2.8 (summary Network Number) Link State ID: 10.0.3.3 (summary Network Number) Link State ID: 10.0.3.4 (summary Network Number) Link State ID: 10.0.3.5 (summary Network Number) Link State ID: 10.0.4.0 (summary Network Number) Link State ID: 10.0.4.4 (summary Network Number) Link State ID: 10.0.4.8 (summary Network Number) Link State ID: 10.0.4.12 (summary Network Number) Link State ID: 10.0.6.1 (summary Network Number) Link State ID: 10.0.6.2 (summary Network Number)

2. JUNOS与IOS OSPF路由策略及数据库信息交互

R1/R2之间的10.0.5/24网段路由以外部路由的形式在区域0出现；
将10.0.5/24路由的初始Metric设置为10，贴上420标签，同时所有OSPF会根据内部开销自动调节该路由在本地的Metric值；
保证R1不会产生Network LSA（LSA-2）；

通过在R1/R2上设置OSPF导出策略，指定初始化Metric，标签，并且将其外部路由类型设置为类型1，以便在路由转发的过程中通过累链路开销而自动调节Metric值。我们很容易的使他们的直连网段10.0.5/24以外部路由的形式进入骨干区域。因为该网段直接从直连路由注入OSPF，我们没有必要将该接口在区域1内通告。另外，将R1上所有OSPF接口的优先级设置为0，强迫其退出DR/BDR选举，因此R1将不会产生只能由DR/BDR通告的LSA-2。

nigel@junos7.2# show r1 protocols ospf export external; area 0.0.0.1 { interface lo0.1; interface fxp1.13 { priority 0; } interface fxp1.12 { priority 0; } } [edit logical-routers] nigel@junos7.2# show r1 policy-options policy-statement external { term 1 { from { protocol direct; route-filter 10.0.5.0/24 exact; } then { metric 10; tag 420; external { type 1; } accept; } } term 2 { then reject; } }

查看R1接口状态，我们可以确认R1退出OSPF的DR/BDR选举，而其状态显示为DRother。

nigel@junos7.2# run show ospf interface logical-router r1 Interface State Area DR ID BDR ID Nbrs fxp1.12 DRother 0.0.0.1 10.0.6.2 0.0.0.0 1 fxp1.13 DRother 0.0.0.1 10.0.3.3 0.0.0.0 1 lo0.1 DR 0.0.0.1 10.0.6.1 0.0.0.0 0

继续查看R4/R5的OSPF数据库，验证通过external策略设置的10.0.5/24外部路由的各项属性，包括LSA类型，外部路由类型，初始化Metric以及Tag，均能够被JUNOS以及IOS的OSPF数据库识别。并查看路由表进一步确认该路由的Metric值在初始为10的基础上被不断累加。留意在JUNOS的OSPF数据库中Tag使用IP分段格式显示，0.0.1.164 = 256+164，得出结果同样为420。

nigel@junos7.2# run show ospf database logical-router r5 extern advertising-router 10.0.6.1 detail     OSPF AS SCOPE link state database Type       ID      Adv Rtr Seq       Age Opt Cksum Len Extern   10.0.5.0 10.0.6.1 0x80000002 2565 0x2 0x2260 36 mask 255.255.255.0 Type 1, TOS 0x0, metric 10, fwd addr 0.0.0.0, tag 0.0.1.164
r4#show ip ospf database external 10.0.5.0 adv-router 10.0.6.1 OSPF Router with ID (10.0.3.4) (Process ID 64) Type-5 AS External Link States LS age: 2230 Options: (No TOS-capability, No DC) LS Type: AS External Link Link State ID: 10.0.5.0 (External Network Number ) Advertising Router: 10.0.6.1 LS Seq Number: 80000002 Checksum: 0x2260 Length: 36 Network Mask: /24 Metric Type: 1 (Comparable directly to link state metric) TOS: 0 Metric: 10 Forward Address: 0.0.0.0 External Route Tag: 420
nigel@junos7.2# run show route logical-router r5 10.0.5/24 inet.0: 23 destinations, 23 routes (23 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.5.0/24     *[OSPF/150] 00:15:30, metric 12, tag 420                  > to 10.0.2.2 via fxp2.35                    to 10.0.2.10 via fxp2.45
r4#sh ip route ospf      10.0.0.0/8 is variably subnetted, 18 subnets, 3 masks O E1    10.0.5.0/24 [110/20] via 10.0.4.10, 00:00:01,      FastEthernet0/0.24

查看两者的路由表可以确认Metric在初始为10的基础上被不断累加。有趣的地方在于IOS对于OSPF的外部路由与内部路由在管理距离上并没有区分，均为110；而JUNOS则对OSPF的内部路由与外部路由分别设置了不同的Preference 10与150。尽管如此，IOS的路由表内通过“O E1”标识出该路由为类型1的外部路由，同时虽然采用相同的管理距离，IOS内部的选路机制也存在针对域内、域间、域外路由的优先区分。对于不习惯看Preference的工程师来说这种标识更为明确。而其实JUNOS也提供类似的输出命令，个人觉得还是IOS更为直观，习惯问题。人必有痴，而后有成。

nigel@junos7.2# run show ospf route extern logical-router r5 Prefix Path Route NH Metric NextHop Nexthop Type Type Type Interface addr/label 10.0.5.0/24 Ext1 Network IP 12 fxp2.35 10.0.2.2 area 0.0.0.0, origin 10.0.6.2

相应的，对于上面在R1/R2将直连网段注入OSPF并且设置相关路由属性信息的策略，在IOS上也能够得到反映。我们在R4上新增测试接口fa0/0.47，将该测试接口的IP网段172.16.47.0/30使用相同的属性注入OSPF。

r4#wr t ! router ospf 64 router-id 10.0.3.4 log-adjacency-changes redistribute connected subnets route-map external network 10.0.2.4 0.0.0.3 area 0 network 10.0.2.8 0.0.0.3 area 0 network 10.0.3.4 0.0.0.0 area 0 network 10.0.4.8 0.0.0.3 area 1 ! access-list 1 permit 172.16.47.0 0.0.0.3 ! route-map external permit 10 match ip address 1 set metric 10 set metric-type type-1 set tag 420 !

LSA进入JUNOS的OSPF数据库中，同样的属性也能够被显示出来。相比较而言，似乎JUNOS的Policy设置更为简便，无需先制定access-list后再绑定到route-map里面去。而实际上是JUNOS的route-filter机制带来简便的体验，假如无需对特定的路由进行过滤，IOS可以直接使用redistribute命令捆绑相关注入路由属性：Metric值，Metric类型，tag等而无需引用route-map。

nigel@junos7.2# run show ospf database logical-router r5 lsa-id 172.16.47.0 detail OSPF AS SCOPE link state database Type ID Adv Rtr Seq Age Opt Cksum Len Extern 172.16.47.0 10.0.3.4 0x80000001 31 0x2 0x7e0d 36 mask 255.255.255.252 Type 1, TOS 0x0, metric 10, fwd addr 0.0.0.0, tag 0.0.1.164

3. JUNOS与IOS OSPF NSSA设置及区域认证：

区域0.0.0.1内不会出现LSA-3或者LSA-5；
区域0.0.0.0使用MD5加密认证，密码为“jnx”；

根据区域1对LSA类型的过滤要求，我们需要将区域1设置为TNSSA，在ABR R3/R4上除了要在设置NSSA的同时加入no-summary参数并向NSSA注入默认路由以外；还需要保证被注入的默认路由以LSA-7的形式出现。在R3上JUNOS配置我们在之前的实验中已经演示过。

nigel@junos7.2# show r3 protocols ospf area 1 nssa { default-lsa { default-metric 1; type-7; } no-summaries; }

在R3上采用正确的策略，不难将LSA3/4/5全部过滤掉。应用策略后，查看R1/R2的OSPF数据库，均确认在NSSA 1内没有通过R3接收到以上三类LSA。

nigel@junos7.2# run show ospf database logical-router r1 advertising-router 10.0.3.3 OSPF link state database, area 0.0.0.1 Type ID Adv Rtr Seq Age Opt Cksum Len Router 10.0.3.3 10.0.3.3 0x80000009 749 0x0 0x14b0 48 Network 10.0.4.13 10.0.3.3 0x80000004 444 0x0 0x1ff0 32 NSSA 0.0.0.0 10.0.3.3 0x80000004 660 0x0 0xe35b 36 nigel@junos7.2# run show ospf database logical-router r2 netsummary advertising-router 10.0.3.3 | count Count: 0 lines

然而另一挑战则来自于从IOS将LSA3/4/5从区域1内完全过滤掉。在IOS中，为保障NSSA内部路由器到域间及域外网段的连通性，ABR会在不同的情况下产生两种类型的缺省路由LSA。当我们需要过滤域间LSA-3的时候，ABR将以LSA-3的形式向NSSA注入默认路由。此时，尽管其他域间LSA-3被全部过滤掉，却依然留下默认路由为LSA-3的痕迹。无论通过查看R2的OSPF数据库，还是路由表中OSPF的Preference值均能确认这一点。

r4(config-router)#area 1 nssa no-summary nigel@junos7.2# run show ospf database logical-router r2 netsummary advertising-router 10.0.3.3 OSPF link state database, area 0.0.0.1 Type ID Adv Rtr Seq Age Opt Cksum Len Summary 0.0.0.0 10.0.3.4 0x80000001 235 0x2 0xb173 28 nigel@junos.2# run show route logical-router r2 0.0.0.0 inet.0: 13 destinations, 14 routes (13 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[OSPF/10] 00:09:36, metric 2 > to 10.0.4.9 via fxp2.24

而假如我们希望接收LSA-7形式的默认路由，则可以将no-summary参数改为no-redistribution，该参数主要用于避免同时充当ASBR的NSSA ABR路由器将其本地重分布进入OSPF域内的外部路由以LSA-5注入骨干区域的同时，以LSA-7的方式注入NSSA内部。JUNOS在更新的版本上使用no-nssa-abr命令达到类似的目的。此时IOS将把默认路由以LSA-7的形式注入NSSA内部。不幸的是，当我们成功避免了默认路由以LSA-3出现的时候，却无法过滤源自于OSPF的域间路由LSA-3。结果更多的LSA-3被引入区域1。

r4(config-router)#no area 47 nssa r4(config-router)#area 1 nssa no-redistribution default-information-originate nigel@junos7.2# run show route logical-router r2 0.0.0.0 inet.0: 23 destinations, 24 routes (23 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[OSPF/150] 00:45:37, metric 2, tag 0 > to 10.0.4.1 via fxp2.23 nigel@junos7.2# run show ospf database logical-router r2 netsummary | count Count: 13 lines

由于IOS本身并没有提供如JUNOS那样转换缺省路由LSA类型的设置，即便我们将两个参数结合在一起使用，ABR将同时产生两条0.0.0.0默认路由，分别以LSA-3与LSA-7同时注入NSSA。由于两者在JUNOS上Preference的差异以及IOS优选域间LSA甚于外部LSA，Juniper与Cisco两者均无法在数据库内摒除LSA-3并且路由表优选其成为活跃的默认路由。

r4(config-router)#area 1 nssa no-summary no-redistribution default-information-originate nigel@junos7.2# run show ospf database logical-router r2 lsa-id 0.0.0.0 OSPF link state database, area 0.0.0.1 Type ID Adv Rtr Seq Age Opt Cksum Len Summary 0.0.0.0 10.0.3.4 0x80000002 660 0x2 0xaf74 28 NSSA 0.0.0.0 10.0.3.3 0x8000000b 1263 0x0 0xd562 36 NSSA 0.0.0.0 10.0.3.4 0x80000001 660 0x2 0xa6e2 36

单纯依靠IOS的NSSA功能无法达成实验目标，我们需要考虑新的思路。由于NSSA内一旦使用no-summary对LSA-3进行过滤，产生的默认路由必然是LSA-3。因此我们只能抛弃采用no-summary参数过滤域间LSA-3，而选择no-redistribution保证NSSA域内的默认路由LSA类型为LSA-7。然后再通过另外的途径过滤其余的域间路由。我们引用IOS域间基于prefix-list的路由过滤特征来达到这个目的，通过定义prefix-list，仅允许默认路由进入区域1，从而将其他域间路由全部过滤掉，因此在设置前缀列表的时候应该将它设置在区域1的in方向。结合这NSSA和前缀列表两种过滤功能，分别实现对LSA-5以及LSA-3的过滤，而由于R4上并没有域外路由被重分布进入OSPF，no-redistribution在这里仅仅充当产生LSA-7默认路由的功能。完成配置后，我们终于可以看到区域1内已经不存在任何LSA-3及LSA-5，并且默认路由以LSA-7的形式被安装进入OSPF数据库内。

r4(config-router)#area 1 nssa no-redistribution default-information-originate r4(config-router)#area 1 filter-list prefix only-default-route in nigel@junos7.2# run show ospf database logical-router r2 netsummary | count Count: 0 lines nigel@junos7.2# run show ospf database logical-router r2 extern | count Count: 0 lines nigel@junos7.2# run show ospf database logical-router r2 lsa-id 0.0.0.0 OSPF link state database, area 0.0.0.1 Type ID Adv Rtr Seq Age Opt Cksum Len NSSA 0.0.0.0 10.0.3.3 0x80000010 228 0x0 0xcb67 36 NSSA 0.0.0.0 10.0.3.4 0x80000001 427 0x2 0xa6e2 36

接下来的认证比较简单，只需要在骨干区域路由器上启用区域认证并且在骨干区域接口内输入相同的Key ID以及密码即可完成认证配置，我们仅把关键配置摘录下来。

[edit logical-routers] nigel@junos7.2# show r5 protocols ospf area 0 authentication-type md5; interface lo0.5; interface fxp2.45 { authentication { md5 10 key "$9$IBIhyKsYoaUH"; ## SECRET-DATA } } interface fxp2.35 { authentication { md5 10 key "$9$j8kmTOBEhrv"; ## SECRET-DATA } }
r4#wr t ! interface FastEthernet0/0.34 encapsulation dot1Q 134 ip address 10.0.2.6 255.255.255.252 ip mtu 1496 ip ospf message-digest-key 10 md5 jnx ! interface FastEthernet0/0.45 encapsulation dot1Q 145 ip address 10.0.2.10 255.255.255.252 ip mtu 1496 ip ospf message-digest-key 10 md5 jnx ! router ospf 64 router-id 10.0.3.4 log-adjacency-changes area 0 authentication message-digest area 1 nssa no-redistribution default-information-originate area 1 filter-list prefix only-default-route in !

验证骨干区域认证配置正常的最快方式可以在R5上查看区域0内的两给邻居R3/R4是否已经达到FULL状态，并且任选在R3/R4上使用环回接口互相traceroute，确认彼此环回接口之间使用最短路径访问及回访即可。

r4#traceroute 10.0.3.3 source 10.0.3.4 Type escape sequence to abort. Tracing the route to 10.0.3.3 1 10.0.3.3 20 msec 24 msec 8 msec

4. JUNOS与IOS OSPF域间及域外地址汇总

汇总所有的非骨干区域路由进入骨干区域，包括内部路由以及外部路由；
汇总来自RIP路由器的192.168.x/24路由，但你不能修改RIP路由器上的配置；

到目前为止，我们需要汇总进入OSPF骨干区域的内部路由包括区域1与区域20内的网段，而外部路由仅包括从R1/R2重分布进OSPF的直连网段10.0.5/24网段路由。来自NSSA的外部路由仅有10.0.5/24一条，因此对于这条路由我们不需要对该网段进行汇总。我们可以将汇总的焦点放在两边非骨干区的OSPF内部地址汇总上，在之前的OSPF地址汇总实验中我们已经计算出两边网段的汇总地址分别是10.0.4/22及10.0.8/23；我们在3台ABR上分别应用汇总配置。值得借鉴的是，我们可以在JUNOS上通过应用area-range命令的restrict参数批量过滤OSPF域间路由，相应的在IOS上同样可以在该命令后应用not-advertise达到相同的效果。而在IOS中，对于域间汇总路由的Metric计算直接采用ABR所在汇总区域接口的开销值，另外我们也能通过cost参数进行定义。

[edit logical-routers] nigel@itaa7.2# show r5 protocols ospf area 20 area-range 10.0.8.0/23; [edit logical-routers] nigel@itaa7.2# show r3 protocols ospf area 1 nssa { default-lsa { default-metric 1; type-7; } no-summaries; } area-range 10.0.4.0/22;
r4#conf t Enter configuration commands, one per line. End with CNTL/Z. r4(config-router)#area 1 range 10.0.4.0 255.255.252.0 r4(config-router)#area 1 range 10.0.4.0 255.255.252.0 ? advertise Advertise this range (default) cost User specified metric for this range not-advertise DoNotAdvertise this range

同样，可以在骨干区域路由器上查看两边非骨干区域的明细网段是否仅匹配路由表内的汇总路由，从而确认地址汇总被成功配置。我们将查询两边区域内的直连网段路由及各路由器的环回接口网段：在R4上分别查询10.0.8.0与10.0.9.0两个网段，均匹配10.0.8/23路由；另一方面，我们在R5上分别查询10.0.4.0及10.0.6.0两个网段，均匹配10.0.4/22路由。

r4#show ip route 10.0.8.0 Routing entry for 10.0.8.0/23 Known via "ospf 64", distance 110, metric 12, type inter area Last update from 10.0.2.9 on FastEthernet0/0.45, 00:27:09 ago Routing Descriptor Blocks: * 10.0.2.9, from 10.0.3.5, 00:27:09 ago, via FastEthernet0/0.45 Route metric is 12, traffic share count is 1 r4#show ip route 10.0.9.0 Routing entry for 0.0.8.0/23 Known via "ospf 64", distance 110, metric 12, type inter area Last update from 10.0.2.9 on FastEthernet0/0.45, 00:27:16 ago Routing Descriptor Blocks: * 10.0.2.9, from 10.0.3.5, 00:27:16 ago, via FastEthernet0/0.45 Route metric is 12, traffic share count is 1
nigel@itaa7.2# run show route logical-router r5 10.0.6.0 inet.0: 19 destinations, 19 routes (19 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.4.0/22 *[OSPF/10] 00:17:42, metric 3 > to 10.0.2.2 via fxp2.35 nigel@itaa7.2# run show route logical-router r5 10.0.4.0 inet.0: 19 destinations, 19 routes (19 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.4.0/22 *[OSPF/10] 00:17:44, metric 3 > to 10.0.2.2 via fxp2.35

需要注意的是尽管对于区域1的地址汇总，尽管10.0.4/22包含10.0.5/24网段，然而由于10.0.5/24网段采用域外路由的形式注入OSPF，作为域间路由汇总的area-range并不会将域外及域间路由混合在同一条汇总路由内通告，因此在R5上我们仍然能够接收到10.0.5/24网段路由，而且其依然保留域外路由的Preference。

nigel@itaa7.2# run show route logical-router r5 10.0.5.0 inet.0: 19 destinations, 19 routes (19 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.5.0/24 *[OSPF/150] 00:19:40, metric 13, tag 420 > to 10.0.2.2 via fxp2.35

下一步我们开始对来自RIP的192.168.x/24域外路由进行汇总，在实验目标中明确提出不允许通过修改RIP路由器的配置来实现路由汇总，我们需要在R6与R7上通过RIP接收全部明细路由后再汇总重分布进入OSPF域内。先在JUNOS路由器R6和IOS路由器R7上完成RIP的基本配置，并确认两者RIP路由表同步。

[edit logical-routers r6] nigel@itaa7.2# show protocols rip group rip { neighbor fxp1.60; }
r7#wr t ! router rip version 2 network 172.16.0.0 !
nigel@itaa7.2# run show route logical-router r6 protocol rip inet.0: 24 destinations, 24 routes (24 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.0.0/24 *[RIP/100] 00:22:22, metric 2, tag 0 > to 172.16.40.1 via fxp1.60 192.168.1.0/24 *[RIP/100] 00:22:22, metric 2, tag 0 > to 172.16.40.1 via fxp1.60 192.168.2.0/24 *[RIP/100] 00:22:22, metric 2, tag 0 > to 172.16.40.1 via fxp1.60 192.168.3.0/24 *[RIP/100] 00:22:22, metric 2, tag 0 > to 172.16.40.1 via fxp1.60 192.168.4.0/24 *[RIP/100] 00:22:22, metric 2, tag 0 > to 172.16.40.1 via fxp1.60 224.0.0.9/32 *[RIP/100] 00:22:32, metric 1 MultiRecv r7# show ip route rip R 192.168.4.0/24 [120/1] via 172.16.40.5,0:34,Fa0/0.70 R 192.168.0.0/24 [120/1] via 172.16.40.5,0:34,Fa0/0.70 R 192.168.1.0/24 [120/1] via 172.16.40.5,0:34,Fa0/0.70 R 192.168.2.0/24 [120/1] via 172.16.40.5,0:34,Fa0/0.70 R 192.168.3.0/24 [120/1] via 172.16.40.5,0:34,Fa0/0.70

此时我们有机会比较JUNOS与IOS在对OSPF域外路由汇总上采取的不同的路径，JUNOS先将RIP明细路由通过Aggregate进行汇总，在把汇总后的Aggregate路由通过策略重分布进入OSPF；而IOS则直接将RIP明细路由重发布进入OSPF内，下一步使用summary-address将域外路由在OSPF协议内部进行汇总。相比之下，JUNOS的配置量似乎大得多，其实情况不一定正如看上去那么完美。

[edit logical-routers r6] nigel@itaa7.2# show routing-options aggregate { route 192.168.0.0/21; } [edit logical-routers r6] nigel@itaa7.2# show policy-options policy-statement rip-ospf { term 1 { from { protocol aggregate; route-filter 192.168.0.0/21 exact; } then accept; } } r7(config-router)#router ospf 64 r7(config-router)#redistribute rip subnets r7(config-router)#summary-address 192.168.0.0 255.255.248.0

查看R5上的OSPF数据库，同时从R6/R7上均收到汇总后的192.168/21域外LSA-5，似乎与我们设想中的结果吻合。而当我们进一步查看R5上的全部域外LSA的时候，却发现从R7上注入了172.16.40.4/30这条额外的LSA，在下一个实验目标中明确规定该网段应当以域内路由的形式出现在OSPF内。由于我们在IOS上进行RIP到OSPF重分布的时候并没有做任何地址限制，因此172.16.40.4/30作为R7上RIP数据库内的路由随同192.168.x/24路由被重分布进OSPF内。

nigel@itaa7.2# run show ospf database logical-router r5 lsa-id 192.168.0.0 OSPF AS SCOPE link state database Type ID Adv Rtr Seq Age Opt Cksum Len Extern 192.168.0.0 10.0.9.6 0x80000001 50 0x2 0x5007 36 Extern 192.168.0.0 10.0.9.7 0x80000005 109 0x2 0x47d8 36 nigel@itaa7.2# run show ospf database logical-router r5 extern OSPF AS SCOPE link state database Type ID Adv Rtr Seq Age Opt Cksum Len Extern 10.0.5.0 10.0.3.4 0x80000005 887 0x2 0x341b 36 Extern 172.16.40.4 10.0.9.7 0x80000001 366 0x2 0xaaf5 36 Extern 192.168.0.0 10.0.9.6 0x80000001 147 0x2 0x5007 36 Extern 192.168.0.0 10.0.9.7 0x80000005 206 0x2 0x47d8 36 r7#show ip rip database 172.16.0.0/16 auto-summary 172.16.40.4/30 directly connected, Fa0/0.70

显然我们还需要对IOS追加地址过滤的配置，其目的不单纯为了满足实验目标的需求，更重要的是防止在多点双向重分布的网络中形成路由倒灌而产生环路的潜在危险，详见前面的章节。而最简单快速的方式便是access-list与route-map组合在一起，然后将route-map绑定到redistribute命令中。下面的route-map写得不太直观，然而只要你对IOS策略路由的逻辑是否关系有清晰的了解，应该不会感到疑惑。重新应用redistribut，R5上已经不存在172.16.40.4/30的外部LSA-5。

! access-list 1 permit 172.16.40.4 0.0.0.3 ! route-map rip-import deny 10 match ip address 1 ! route-map rip-import permit 20 ! r7(config-router)#redistribute rip subnets route-map rip-import nigel@itaa7.2# run show ospf database logical-router r5 extern OSPF AS SCOPE link state database Type ID Adv Rtr Seq Age Opt Cksum Len Extern 10.0.5.0 10.0.3.4 0x80000006 960 0x2 0x321c 36 Extern 192.168.0.0 10.0.9.6 0x80000002 372 0x2 0x4e08 36 Extern 192.168.0.0 10.0.9.7 0x80000006 368 0x2 0x45d9 36

5. JUNOS与IOS OSPF/RIP重分布及路由策略协调

R6/R7必须将10.0.5/24路由通告给RIP路由器，同时R7上通告的RIP路由Metric应大于R6上的通告；
172.16.40/24网段以OSPF内部路由的形式出现，该子网上不应存在OSPF邻接；

默认情况下，JUNOS会将直接重分布进入RIP的路由Metric值设置为1，而IOS则将来自任何协议重分布进RIP的Metric统一设置为16跳不可达Metric，在IOS上进行入向RIP重分布的时候总需要手动指定Metric值。由于之前的分解实验中已经讨论过JUNOS上从OSPF到RIP的重分布方式，这里仅快速列出R6上的相关配置。

[edit logical-routers] nigel@itaa7.2# show r6 policy-options policy-statement ospf-rip term 1 { from { protocol ospf; route-filter 10.0.5.0/24 exact; } then accept; } [edit logical-routers] nigel@itaa7.2# show r6 protocols rip group rip { export ospf-rip; neighbor fxp1.60; } nigel@itaa7.2# run show route advertising-protocol rip 172.16.40.2 logical-router r6 inet.0: 25 destinations, 26 routes (25 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.5.0/24 *[OSPF/150] 00:22:02, metric 14, tag 420 > to 10.0.8.6 via fxp2.56

从R6通告给RIP的路由中顺带可以看到，作为转换LSA-7到LSA-5的NSSA ABR R4，IOS并没有将其本地外部路由的Metric带入骨干区域，而是保留了其初始的Metric值10，与JUNOS 8.5版本的行为相似。由于该外部路由的ASBR地址10.0.6.2经过域间汇总至10.0.4/22内，R3通告10.0.4/22汇总路由的Metric为2，因此在R6上的Metric值为10+2+2=14。同时，从IOS路由器R7将10.0.5/24网段重分布进入RIP的流程稍显复杂，为了验证RIP路由器同时从R6/R7上同时收到该段路由，我们要求R7向RIP注入Metric值同样为1的路由。

! router rip version 2 redistribute ospf 64 route-map ospf-rip network 172.16.0.0 ! access-list 2 permit 10.0.5.0 0.0.0.255 ! route-map ospf-rip permit 10 match ip address 2 set metric 1 !

而我们查看RIP路由器上的路由表的时候，却并没有发现同时出现两条10.0.5/24的条目，仅存在由R6通告过来的信息。而且我们在R1上采用默认的traceroute访问192.168.x/24网段能够返回成功的信息。由于我们并没有将除10.0.5/24以外的其他OSPF路由重分布到RIP里面，R1应当使用10.0.5.1作为traceroute源地址方能正常访问192.168.x/24网段。

nigel@itaa7.2# run show route logical-router rip 10.0.5/24 inet.0: 17 destinations, 17 routes (17 active,0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.5.0/24 *[RIP/100] 00:03:04, metric 2, tag 420 > to 172.16.40.2 via fxp2.60 nigel@itaa7.2# run traceroute 192.168.2.1 logical-router r1 traceroute to 192.168.2.1 (192.168.2.1), 30 hops max, 40 byte packets 1 10.0.4.13 (10.0.4.13) 1.168 ms 0.844 ms 1.150 ms 2 10.0.2.1 (10.0.2.1) 1.094 ms 1.182 ms 1.160 ms 3 10.0.8.5 (10.0.8.5) 1.314 ms 1.867 ms 1.747 ms 4 192.168.2.1 (192.168.2.1) 5.232 ms 3.682 ms 3.841 ms

在不存在其他后门链路的情况下，唯一能够解析的原因在于RIP路由器上存在10.0.5/24子网的汇总路由，R1发送到RIP路由器上的traceroute正是匹配了该汇总路由才能被返回。在172.16/16与10/8网络边缘，IOS路由器R7执行了自动汇总，10.0.5/24路由于是被自动汇总成为10.0.0.0/8主网路由，然后被通告到RIP路由器上面。我们通过查看RIP路由表能确认这点。

nigel@itaa7.2# run show route logical-router rip 10/8 inet.0: 17 destinations, 17 routes (17 active,0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.0.0/8 *[RIP/100] 00:08:31, metric 2, tag 0 > to 172.16.40.6 via fxp2.70 10.0.5.0/24 *[RIP/100] 00:09:21, metric 2, tag 420 > to 172.16.40.2 via fxp2.60

正是由于需要RIP支持无类路由，因此我们开始设置R7上RIP的时候便直接启用Version 2的RIP。关闭R7上的自动汇总，同时由于实验目标要求R7注入RIP的路由应该包含更大的Metric值，在route-map中我们将其调节为2。

! router rip version 2 redistribute ospf 64 route-map ospf-rip network 172.16.0.0 no auto-summary ! access-list 2 permit 10.0.5.0 0.0.0.255 ! route-map ospf-rip permit 10 match ip address 2 set metric 2 !

重新启动RIP路由器的路由进程，而问题却依然没有得到彻底解决，当RIP路由器收到来自R7的10.0.5/24明细路由后，原本从R6接收到的路由却消失掉。

nigel@itaa7.2# run restart routing logical-router rip rip started, pid 4830

可能你已经能猜到，我们又回到了在R6上OSPF外部路由150与RIP 100的Preference冲突上。继续修正R6上的RIP导入策略。完成后为了尽快实现路由收敛，你可能需要清空R7的路由表以及重启R6/RIP的路由进程。制定策略的时候由于我们需要过滤从RIP路由更新注入同样为RIP路由协议的信息，此时默认策略为accept，因此我们需要增加term 2，将除192.168.x/24以外的其他路由明确拒绝掉。而对于IOS路由器R7，由于OSPF内部及外部路由的管理距离均为110，小于RIP的120，暂时不需要应用distribut-list in进行入向RIP路由过滤。

[edit logical-routers r6] nigel@itaa7.2# show policy-options policy-statement rip-ospf term 1 { from { protocol rip; route-filter 192.168.0.0/21 orlonger; } then accept; } policy-statement rip-import { term 1 { from { protocol rip; route-filter 192.168.0.0/21 orlonger; } then accept; } term 2 { then reject; } }

最后我们确定仅有10.0.5/24网段路由被注入RIP内部，在R1上分别使用10.0.5.1以及默认接口作为源地址对192.168.x/24网段进行traceroute，仅有当10.0.5.1作为源地址的时候traceroute才能成功。

nigel@itaa7.2# run traceroute 192.168.1.1 logical-router r1 traceroute to 192.168.1.1 (192.168.1.1), 30 hops max, 40 byte packets 1 10.0.4.13 (10.0.4.13) 5.114 ms 1.243 ms 1.498 ms 2 10.0.2.1 (10.0.2.1) 1.839 ms 2.311 ms 1.471 ms 3 10.0.8.5 (10.0.8.5) 1.972 ms 2.019 ms 1.756 ms 4 * * * 8 *^C nigel@itaa7.2# run traceroute 192.168.1.1 logical-router r1 source 10.0.5.1 traceroute to 192.168.1.1 (192.168.1.1) from 10.0.5.1, 30 hops max, 40 byte packets 1 10.0.4.13 (10.0.4.13) 1.414 ms 0.955 ms 1.458 ms 2 10.0.2.1 (10.0.2.1) 1.378 ms 1.740 ms 1.786 ms 3 10.0.8.5 (10.0.8.5) 1.916 ms 1.834 ms 1.877 ms 4 192.168.1.1 (192.168.1.1) 2.527 ms 2.221 ms 2.048 ms

相对而言，对于172.16.40.x网段的通告配置比较简单，利用JUNOS对OSPF内外路由的区分，最后在R5上通过检查两条路由的Preference确认为域内路由。

[edit logical-routers r6] nigel@itaa7.2# set protocols ospf area 20 interface fxp1.60 passive ! router ospf 64 passive-interface FastEthernet0/0.70 network 172.16.40.4 0.0.0.3 area 20 ! nigel@itaa7.2# run show route logical-router r5 172.16/16 inet.0: 22 destinations, 22 routes (22 active,0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 172.16.40.0/30 *[OSPF/10] 00:01:50, metric 2 > to 10.0.8.5 via fxp1.56 172.16.40.4/30 *[OSPF/10] 00:01:50, metric 11 > to 10.0.8.10 via fxp1.57
r7# show ip ospf interface fa0/0.70 FastEthernet0/0.70 is up, line protocol is up Internet Address 172.16.40.6/30, Area 20 Process ID 64, Router ID 10.0.9.7, Network Type BROADCAST, Cost: 10 Transmit Delay is 1 sec, State DR, Priority 1 Designated Router (ID) 10.0.9.7, Interface address 172.16.40.6 No backup designated router on this network Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 oob-resync timeout 40 No Hellos (Passive interface

JUNOS与IOS OSPF接口开销调节

基于带宽优化路由选择：保证所有快速以太网接口被自动分配Metric值为10，另外你需要手动调节Metric使R5到区域1的内部网段实现负载均衡；

我们先把第13个实验目标提前分析，JUNOS与IOS的OSPF参考带宽同为100Mbps，在之前的实验过程中IOS对于快速以太网接口开销值定义为10仅仅因为fa0/0接口与实验台交换机自动协商带宽为10Mbps，可以在接口下修复该配置，以下以R4为例，包含环回接口在内的4个OSPF接口当前开销值均被修改为1。

! interface FastEthernet0/0.34 bandwidth 100000 encapsulation dot1Q 134 ip address 10.0.2.6 255.255.255.252 ip mtu 1496 ip ospf message-digest-key 10 md5 jnx ! r4#show ip ospf interface | include Cost Process ID 64, Router ID 10.0.3.4, Network Type LOOPBACK, Cost: 1 Process ID 64, Router ID 10.0.3.4, Network Type BROADCAST, Cost: 1 Process ID 64, Router ID 10.0.3.4, Network Type BROADCAST, Cost: 1 Process ID 64, Router ID 10.0.3.4, Network Type BROADCAST, Cost: 1

通过在所有OSPF路由器上修改参考带宽能够在全局修改链路开销值，除环回接口保持默认开销值，JUNOS环回接口默认开销为0；而IOS环回接口默认开销为1。所有快速以太网接口的开销值均设置为10，假如你使用输出导出符精确定位信息，注意JUNOS与IOS对大小写的区分行为。

[edit logical-routers] nigel@itaa7.2# set r1 protocols ospf reference-bandwidth 1g nigel@itaa7.2#run show ospf interface logical-router r5 detail | match cost Type: LAN, Address: 10.0.2.1, Mask: 255.255.255.252, MTU: 1496, Cost: 10 Type: LAN, Address: 10.0.2.9, Mask: 255.255.255.252, MTU: 1496, Cost: 10 Type: LAN, Address: 10.0.3.5, Mask: 255.255.255.255, MTU: 65535, Cost: 0 Type: LAN, Address: 10.0.8.6, Mask: 255.255.255.252, MTU: 1496, Cost: 10 Type: LAN, Address: 10.0.8.9, Mask: 255.255.255.252, MTU: 1496, Cost: 10 r4(config)#router ospf 64 r4(config-router)#auto-cost reference-bandwidth 1000 % OSPF: Reference bandwidth is changed. Please ensure reference bandwidth is consistent across all routers. r4#show ip ospf interface | include Cost Process ID 64, Router ID 10.0.3.4, Network Type LOOPBACK, Cost: 1 Process ID 64, Router ID 10.0.3.4, Network Type BROADCAST, Cost: 10 Process ID 64, Router ID 10.0.3.4, Network Type BROADCAST, Cost: 10 Process ID 64, Router ID 10.0.3.4, Network Type BROADCAST, Cost: 10

为了使R5能通过R3/R4实现进入区域1流量的负载均衡，我们需要手动调整R3/R4通告的10.0.4/22汇总LSA-3的Metric值。在R5的OSPF数据库内对比两者的LSA，由于JUNOS与IOS默认对汇总路由的Metric计算方式的差异，使得R5当前优选R4作为流量进入区域1的ABR。

nigel@itaa7.2# run show ospf database logical-router r5 lsa-id 10.0.4.0 detail OSPF link state database, area 0.0.0.0 Type ID Adv Rtr Seq Age Opt Cksum Len Summary 10.0.4.0 10.0.3.3 0x80000019 493 0x2 0xc451 28 mask 255.255.252.0 TOS 0x0, metric 20 Summary 10.0.4.0 10.0.3.4 0x8000001d 444 0x22 0x708a 28 mask 255.255.252.0 TOS 0x0, metric 10

有多种方式能够实现调整汇总路由Metric以达到负载均衡的目的，给出JUNOS与IOS各自最直接覆盖默认汇总路由开销值的解决方案。

[edit logical-routers] nigel@itaa7.2# show r3 protocols ospf area 0.0.0.1 { area-range 10.0.4.0/22 override-metric 30; } r4(config-router)#area 1 range 10.0.4.0 255.255.252.0 cost 30 nigel@itaa7.2# run show route logical-router r5 10.0.4/22 exact inet.0: 22 destinations, 22 routes (22 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.4.0/22 *[OSPF/10] 00:00:27, metric 40 > to 10.0.2.2 via fxp2.35 to 10.0.2.10 via fxp2.45

本文转自：http://jncie.wordpress.com/2008/12/06/juniper-junos-cisco-ios-ospf-interoperability-case-study-part1/

继续阅读《JNCIP案例分析 – Juniper/Cisco OSPF互操作》的全文内容...

分类: Juniper | Tags: OSPF JUNOS IOS | 添加评论(0)

tcpdump

version 2.0 (1 page)

Wireshark Display Filters

version 2.0 (2 pages)

Reference

Common Ports

VLANs

version 2.0 (1 page)

Miscellaneous

Cisco IOS Versions

version 2.0 (1 page)

Physical Terminations

version 1.1 (1 page)

继续阅读《学习笔记: Internet cheat sheets on PacketLif》的全文内容...

分类: 分享 | Tags: | 添加评论(0)

还没有相关文章，您来说两句？

在Wireshark中创建ACL条目

godupgod@163.com (godupgod) — Sat, 31 Oct 2009 19:25:59 +0800

Wireshark is an awesome tool, and it seems like every time I use it I discover another little nugget of awesomeness. In this case, it was Wireshark's ability to generate ACL and firewall entries on the fly from a captured packet.

Let's assume we've captured some unauthorized traffic traversing the firewall: an IRC sesion. We can examine the capture with Wireshark to confirm that the traffic should be denied by the security policy, and automatically generate an ACL entry (ACE) to match the appropriate packets. First, select one of the packets from the suspect session:

Then, navigate to Tools > Firewall ACL Rules.

Wireshark supports several types of syntax, including Cisco IOS standard and extended ACLs, IP Filter, IPFirewall, Net Filter, Packet Filter, and Windows Firewall. Selecting Cisco IOS (extended) offers several levels of granularity: we can filter the source or destination host, TCP port, or both. Additionally, we can toggle the Inbound switch to swap source and destination addresses, and the Deny switch to toggle between permit and deny actions.

The generated syntax can then be copied and pasted directly into an ACL.

While veteran engineers may find this little more than a convenience feature, it can be an excellent learning tool for students to experiment with creating ACEs to match real-world traffic.

继续阅读《在Wireshark中创建ACL条目》的全文内容...

分类: 分享 | Tags: | 添加评论(0)

还没有相关文章，您来说两句？

路由策略的定义

godupgod@163.com (godupgod) — Tue, 06 Oct 2009 15:21:35 +0800

路由策略的定义:

[edit policy-options policy-statement policy-name]
        term firstterm
                from

                then

        term secondterm
                from

                then

        from

        then

from:

match 主要分为4类:

prefix (route-filter or prefix-list)
protocol (ospf, static, BGP, etc.)
routing protocol attributes (OSPF area ID, AS path, community)
next hop

注意：其中prefix-list要在policy-option中预先定义，可以同时匹配多个prefix条目，并且可以反复使用，而route-filter不用预先定义，但是不能反复使用

then:

then actions主要分为三类：

Terminating actions （policy chain直接结束，用来指定路由被接受还是被拒绝）
- accept
- reject

Flow control （执行完当前term中的action后，跳到下一个term或者policy）
- next term
- next policy

modifying attributes
- as-path-prepend
- community(add, delete, set)
- load-balance
- metric
- preference

如果只是修改属性，而不配置termination actions或者flow control，默认行为应该是next term

继续阅读《路由策略的定义》的全文内容...

分类: Juniper | Tags: Juniper policy | 添加评论(1)

还没有相关文章，您来说两句？

转篇文章：经验分享：我的Juniper认证成长之路

godupgod@163.com (godupgod) — Sat, 19 Sep 2009 09:45:17 +0800

　与学习思科认证到最终通过CCIE有所不同，学习Juniper认证的时候我已经离开大学校园，进入社会的大熔炉为自己的事业去奋斗，学习的时间和精力都没有在学校那么充足。

　与电影《我为玛丽狂》中主人公特德与赫利为玛丽疯狂相比，我敢自豪的说，那段对JNCIE执着追求，不断努力，时忧时喜的疯狂过程，是我今生永远值得回味的体验。从安装olive模拟器到最终得到认证JNCIE，共历时近2年时间，那段岁月是疲惫的，充满激情的，无法忘却的，值得自己慢慢品味的，更是值得与朋友们分享的。

　　前言：

　　与学习思科认证到最终通过CCIE有所不同，学习Juniper认证的时候我已经离开大学校园，进入社会的大熔炉为自己的事业去奋斗，学习的时间和精力都没有在学校那么充足。但相同的是我对网络技术的兴趣和激情，以及JNCIE认证在业界的权威性。我是2009年5月5日通过JNCIE认证，全球认证编号为430号，也就是说目前全球通过JNCIE认证的总数也不超过450人，仅占全球超过20000人的CCIE的2%，相当于10多年前的CCIE人数，这里并不是想说明通过JNCIE认证的人数少，对网络工程师就有更高的含金量，但毕竟是“物以稀为贵”。

　　从一些侧面也可以了解JNCIE认证的专业程度和对技术的严谨。其实很多朋友也了解思科认证从2000年左右，伴随着思科网络学院在国内高等院校的普及，全球几千人的CCIE互联网专家的榜样，成为高校学生、网络工程师，以及众多希望在网络技术殿堂有所建树朋友们所孜孜追求的目标。不可否认当时思科认证的价值是厚重的，但随着认证机构、培训机构如雨后春笋般涌出，题库(TK)，代考也伴随着互联网的热潮在网络泛滥，我们似乎感觉到所追求的认证变了味道，不再是对技术的追求和向往，而是对一纸证书含金量的盲目崇拜，思科的认证体系没有变，变的是我们的心态。

　　而Juniper认证体系对认证学习和考试一直都十分严谨，即使是在“人肉搜索”大行其道的今天，我们也无法在各大技术论坛找到Juniper考试题库的过多资料，即便是对在认证学习过程中不可或缺的实验模拟环境Olive，Juniper也没有官方的许可。与其说Juniper认证学习和考试对考生是严苛的，倒不如说对考生是负责的，对网络技术是严谨的。

　　对于如何学习思科认证和通过CCIE，这里不想多说，如果朋友们愿意听我唠叨，以后会抽时间专门写来与大家分享，毕竟学习思科认证和执着于CCIE认证的朋友还有很多，我们的经历有很多相似之处，在网上能找到的分享心得也不少。

　　我与JNCIE的缘分开始于2007年6月，但相识在2005年。在2005年通过CCIE认证之后，因为之前我为了准备CCIE考试已经休学一年，为了本专业的学位和英语四级，我重新回到学校继续我的本专业。而通过CCIE认证的兴奋也让我沾沾自喜，满足于在思科网络技术论坛，帮助网友回答技术、认证问题给我带来的自我满足感，以及作为思科认证讲师的成就感，逐渐代替了我对网络技术的初衷，直到一位网友不经意间提到JNCIE，而他拥有JNCIE和CCIE双认证的实力，也又一次激发了我的斗志。

　　而当我看到类似于C++一段段被括号包裹的代码行，没有任何实验环境，相关书籍和资料欠缺之后，开始对这个认证望而却步。直到2007年6月，在网上发现了Juniper的模拟器，也就是大家所说的olive，虽然对类似于C++的编程代码行一直有抵触情绪，但由于对网络技术的兴趣，以及2年时间内也渐渐听说了许多关于Juniper设备在电信运营商网络的影响力，不同于思科IOS的网络操作系统，稳定性和可靠性的口碑等，决定安装模拟器进行尝试，于是我的JNCIE认证之路就此开始。

　　JNCIE认证心路

　　在真正开始JNCIS、JNCIP、JNCIE每一次认证历程之前，首先想把自己走过的心路历程与大家分享。因为我不想在下面的章节中，更多的涉及到自己当时的心情和感觉，因为有的感受只能自己在心里品味。

　　首先可能是因为在参加CCIE认证过程中，走了一条捷径的缘故，我没有通过CCNA-CCNP-CCIE的认证这个流程，而是通过自学直接参加的CCIE认证考试，因为CCNA认证和CCNP认证学习中遇到的技术不解和问题，最终都可以再CCIE认证学习过程中得到解答，我不喜欢在某个认证环节中遇到的问题，在通过考试后才能寻找答案。但并不是说这个流程不好，但每次认证学习和考试费用是我不得不考虑的，于是在我学习CCNA和CCNP课程的过程中，有意识的从CCIE课程中寻找答案，求知欲能进一步满足我对技术理解的深度。

　　其次，不同厂商的设备都是基于RFC标准，IEEE标准来做的，它们是网络设备的纲，在这个基础之上，各家有各家的思路和方法，所以RFC标准文档是我的常备工具。

　　最后，许多朋友问过我，说自己的英文水平不好，希望所有的教程都是中文的。如果有翻译的很到位的中文教材，当然可以选择。本人在开始接触网络认证的时候也首选了中文教材，但随着自身对网络技术理解的深入，经常会发现中文教材的翻译似乎与自己理解的含义有出入，通过与老师的交流也确实如此，于是渐渐放弃了中文教材的选择。记忆最深刻是第一次完整啃完纯英文教材，被誉为BGP路由协议圣经的《internet路由结构》一书的畅快淋漓。在这之后，我选择的认证教程都是英文的，也为自己每次一回合通过笔试认证考试逐渐打下了良好的基础。

　 认识JNCIE认证

　　其实更准确的应该是认识Juniper认证，其他认证虽然都有单独颁发的证书，但就个人而言感觉都是过程。与思科认证流程相似，通向JNCIE的过程中，同样有许多低级别的认证可以选择JNCIA-JNCIS-JNCIP-JNCIE，其中JNCIA和JNCIS是低、中级别的认证，但通过JNCIS是参加JNCIP和JNCIE的资格考试，只有通过了JNCIS笔试，才能参加实验考试，类似于CCIE的笔试部分。而且JNCIA和JNCIS都是独立的认证考试，而且JNCIS考试在全国的很多城市都能考，通过Prometric的考试中心来进行考试，一般在能考CCNA认证或者MCSE认证的地方，也能考JNCIA、JNCIS。以前没有JNCIP考试，JNCIE实验室考试为2天，后来Juniper为了增强配置和实际操作环节的考核，将2天的JNCIE考试分拆为独立的JNCIP认证和JNCIE认证。

　　JNCIA考试是笔试，初级的技术认证，主要测试考生对BGP/OSPF/ISIS/等技术的理解，考试费用为125美元，考试时间60分钟，60道不定项选择题目，70%及格;

　　JNCIS考试是笔试，中级的技术认证，主要测试考生对BGP/IGP/MPLS/IPV6/Multicast/IPv6/CoS等技术的理解，考题比JNCIA难度要大，考试费用是125美元，考试时间90分钟，75道不定项选择题目，70%及格;

　　JNCIP考试是实验室操作考试，高级的技术认证，需要配置7台路由器，主要测试考生对IGP/BGP配置还有设备本身操作的能力，考试费用是1250美元，考试时间8小时，80%及格;

　　JNCIE考试是实验室操作考试，顶级的技术认证，需要排除10台路由器的故障并按照求新增配置，主要测试考生的故障排除能力和专家级别的配置能力，考试费用是1250美元，考试时间8小时，80%及格;

　　总之，JNCIE考的就是Juniper路由器M/T系列在骨干网络上的操作、排障和对主流技术的理解。也因为Juniper以高端路由产品起家，所以认证考试也面向高端，平心而论JNCIE考试的难度与CCIE相比有过之而无不及。

　　先厉器 JNCIE认证准备

　　由于求知欲和CCIE的基础，让我在选择学习juniper认证的时候，决定自己啃书本。教材和实验工具的准备，实验工具在上文已经提过，我安装了olive。

　　首先了解下什么是olive，JUNOS是由FreeBSD操作系统代码经过修改后发展而来，FreeBSD可以在PC机进行安装，而Juniper M系列路由器的路由引擎是基于Intel的PC机架构，实际上可以看作是一台PC机，JUNOS就是安装在M系列的路由引擎上，所以JUNOS同样可以安装在一台普通的PC机上，安装了JUNOS的PC就如同一台M系列的路由器，可以在其上实现Juniper路由器的大部分功能，这就是olive。简而言之，olive就是安装了JUNOS的PC。2000年Juniper宣布在PC机上安装JUNOS的行为为非法，并要求全球范围内的代理商、客户全部销毁拥有的单独的以各种存储媒介为载体的低版本JUNOS，来推广更多级别的JUNOS版本，而这些高版本无法正常的安装在PC机上，从而限制了olive的进一步扩散。而在中国，也由于Juniper对于olive版权的强硬政策，也让众多的olive爱好者不得不有所顾忌。关于在qemu等虚拟机上如何安装JUNOS，大家可以去“杜松之家”或“Netemu论坛”的Juniper专版去学习，olive只谈这么多。

　　关于学习教程，我推荐以下培训教材和RFC：

　　1.《TCP/IP路由技术(第一卷)(第二版)》即《Routing TCP/IP V1 V2》(IGP知识点经典) (作者 Jeff Doyle);

　　2.《internet路由结构》即Internet Routing Architectures 2nd Edition(BGP圣经) (作者 Basam Halabi);

　　3.JNCIA，JNCIS，JNCIP，JNCIE(M/T)学习指南4本，Sybex出版。即JNCIA，JNCIS，JNCIP，JNCIE(M/T)Study Guide。Juniper公司在官方网站上已经提供JNCIA和JNCIS的电子版下载，JNCIP和JNCIE需要自己购买了;

　　4.Juniper路由器参考大全(英文版)入门，国内有出版;

　　5.JUNOS Document，JUNOS文档http://www.juniper.net/customers/support/，去下载吧!

　　6.RFC 4271 BGP-4;RFC 2328 OSPF Version 2;RFC 1195 Use of OSI IS-IS for Routing in TCP/IP and Dual Environments;RFC 3031到3037，是有关MPLS的等;RFC文档能准备的都准备好，挑你需要的，当然以后也不可或缺。

　　对于培训教材有几点拙见，供大家参考：第一对于初学者，还是建议首先阅读一些中文的书籍(如果你的英文的确很好，阅读英文教材会是更好的选择，这样做的目的是为了能够在大家的脑子里搭建出一个正确的，初始的网络模型，这将会在你之后的学习中产生至关重要的影响)。第二说说RFC文档，众所周知RFC标准文档是一些标准最准确和完整的诠释。RFC文档数目众多，内容繁杂，从简单的IP地址定义到复杂的路由协议实现机制，这些不是我们能全部掌握的，所以我的建议是除非你已经到达了一定的高度，否则RFC文档还是作为大家在遇到问题时查找的一个工具。其实RFC文档创立的目的也就是如此。第三，做好寂寞的学习，啃书本的心理准备吧，网络技术皇冠上的明珠JNCIE等待有准备的朋友。

　　JNCIS并非偶然

　　其实直到安装了模拟器，准备了学习Juniper认证的培训教材。但出于费用的考虑，还是没有想过考JNCIE认证的想法，只是抱着接触Juniper设备、认识JUNOS操作系统的心态。而JNCIS考试也是挺富有戏剧性，在一次去原有培训机构玩的时候，偶然听到现在这里也可以进行juniper的认证考试了，而且JNCIS的认证费用不高，才125美元，比起Cisco笔试的2700RMB简直就是小巫见大巫，加之已经工作和稳定的收入，于是抱着多一张证多一点竞争力的想法，我参加了JNCIS考试。在我个人看来通过JNCIS认证并非偶然，因为CCIE的基础，加上之前的准备工作充分，更重要的是方法。

　　JNCIA和JNCIS两本学习指南的学习，我并没有死抠，而是找出Juniper比较特殊的地方，比如Cisco的AD表和juniper的preference表的不同等(juniper RE,PFE的作用，数据包从进入接口到最终转发出去的过程，JUNOS模块化的结构，特有的policy设置等等)。很多细节在朋友们学习的过程中自然会找到，这里不再详述。当然许多朋友可能有对JNCIS认证考试更多的心得，也可回复我一起探讨，给予更多的朋友帮助，共同进步!

继续阅读《转篇文章：经验分享：我的Juniper认证成长之路》的全文内容...

分类: 其他 | Tags: | 添加评论(0)

还没有相关文章，您来说两句？

前几天去考了安全，挂了

godupgod@163.com (godupgod) — Fri, 21 Aug 2009 15:34:09 +0800

前几天去考了安全，挂了，趁我还记得，随便说一下

core knowledge：考了4题

第一：asa multi context，两个context使用同一个端口，回来的流量是如何区分进入那个context的接口的

第二：GDOI VPN （也就是GETVPN）是通过什么交换密钥等信息的

第三：uRPF一般用来对付什么攻击的

第四：忘记了，什么时候我想起来了，再不上

反正最后我这部分是pass了

接下去是lab题目，就说下考了点什么东西：

第一部分是ASA初始化，包括NAT，两个虚拟防火墙，分别通过IDS inline模式的vs0和vs1，这里IDM是6.0版本的，这里有个题目是说ASA有个接口做backup，只有到某个网段的网关不可达，切换到backup接口代替outside接口

第二部分是VPN配置，首先是用一个router做CA服务器，接着是路由器和asa之间L2L连接的拍错，第三题是anyconnect VPN客户端使用CA认证，最后一个是用路由器做remote-access VPN，对了这里还有一题直接就是做GETVPN

第三部分是IDS部分，主要做2000，2004为high，然后系统默认策略对于high的进行block，这里要做的就是Event filter过滤这两个high从而不对他们block，第二题是做一个http AIM好像是这个

第四部分是3A，第一题是router命令授权，第二题是switch dot1x，不过这里要自动获得两个vlan，一个走正常数据，另一个走voice流量，第三题是LDAP的定义什么的

第五部分是做路由器 zone特性，进行inspect流量

第六部分是做copp，这里还有检测cpu使用率的

第七部分是做攻击检测，一个dhcp snooping，一个port security，一个IPSG，等等

第八部分是高级安全，主要是nbar进行mark，然后设置dscp，其他忘了

继续阅读《前几天去考了安全，挂了》的全文内容...

分类: Cisco | Tags: | 添加评论(7)

还没有相关文章，您来说两句？

John Winning's Blog

随便一个idea

好久没来了，谈谈最近情况

购买Godaddy主机问题

用自建FTP代替xmarks服务器

最近想做网站推广？

究竟为什么内网不能用外网地址访问内部服务器

也可以是用ASA的alias命令

相关文章:

最近在研究VOIP，贴篇文章，使用STUN穿越NAT

junos generate 与 aggregate 汇总

IS-IS 路由协议

1. 前言

2. OSI与CLNS概述

3. OSI路由选择

4. IS-IS路由选择

5. IS-IS与OSPF对比

6. IS-IS寻址

区域合并

区域分离

重编址

1. IS-IS报文结构

1. 区域地址TLV（TLV 1）

2. 中间系统邻居TLV（LSP）（TLV 2）

3. 终端系统邻居TLV（TLV 3）

4. 中间系统邻居TLV（Hello）（TLV 6）

5. 填充TLV（TLV 8）

6. LSP条目TLV（TLV 9）

7. 验证信息TLV（TLV 10）

8. IP内部可达性信息TLV（TLV 128）

9. 支持的协议TLV（TLV 129）

10. IP外部可达性信息TLV（TLV 130）

11. 域间路由选择协议信息TLV（TLV 131）

12. IP接口地址TLV（TLV 132）

13. 扩展的IS可达性TLV（TLV 22）

14. 扩展的IP可达性TLV（TLV 135）

1. LSP剩余时间（Remaining Lifetime）

2. LSP标识符（LSP ID）

3. LSP序列号（Sequence Number）

4. LSP校验和（Checksum）

5. 区域修复（Partition）

6. 区域关联（Attached）

7. 超载（Overload）

8. 中间系统类型（IS Type）

junos软件包操作

安装JUNOS版本的顺序

正确的带冗余路由引擎的路由器的升级顺序（防止网络服务中断）：

JUNOS 路由表操作

VPLS（Virtual Private LAN Service）

报文传送过程：

PW的创建

LDP信令协议

BGP信令协议

MAC地址学习

相关文章:

城域网MPLS VPN的几种实现方法

相关文章:

JNCIP: JUNOS OSPF虚链路配置

更新配置：R3/R4/R5

1. JUNOS OSPF虚链路上的邻居认证

JUNOS实时流量嗅探与跟踪调试OSPF协议信息

提升JUNOS OSPF收敛时间: hello/dead-interval vs. bfd

JNCIP案例分析 – Juniper/Cisco OSPF互操作

实验目标

后台JUNOS设备RIP路由器配置

JNCIP OSPF综合实验案例分析

1. JUNOS与IOS OSPF路由协议互联

2. JUNOS与IOS OSPF路由策略及数据库信息交互

3. JUNOS与IOS OSPF NSSA设置及区域认证：

4. JUNOS与IOS OSPF域间及域外地址汇总

5. JUNOS与IOS OSPF/RIP重分布及路由策略协调

JUNOS与IOS OSPF接口开销调节

学习笔记: Internet cheat sheets on PacketLif

Cheat Sheets

Protocols

Applications

Reference

Syntax

Technologies

Miscellaneous