照片来源：Sun Qian’s 图片博客
其实很多人都知道，JNCIE与JNCIP实验室考试在中国的考场实际上就是Juniper的培训室。如果对于Juniper实验室考试现场比较陌生的话，可以到源站浏览更多的图片。简单注明几点：
1. 考试的时候，考官与考生之间格局大概就是正常的讲师与学员这样面对面的格局，而CCIE在香港的考场，考官却会坐在你身后。2. 考试的时候，考官的信息，联系方式，每个考生的Rack号，以及登录IP等会写在白板上。3. 穿红衣服的学员前面那台笔记本如果没有看错的话应该就是Juniper提供的Dell；有的人说是“死亡笔记…本”，不过据我所知确实有人用它也通过JNCIE。4. 门口贴的是考试那段时间的考生出席日程表。5. 出门左拐，往前走几步，在你右手边就有个冰箱，可以在里面取可乐饮料之类的。6. 图中的讲师不是我考试时候碰到的几位考官之一。Good Luck.
在我们的例子中，我们在远程路由器上配置的200.200/24静态路由，并且引用了Reject扩展参数，然后重分布到OSPF当中。我们已经确认200.200/24这条OSPF域外路由已经被安装到本地路由器的路由表当中。当本地路由器向200.200/24网段发送traceroute的时候，Reject扩展参数将向发起traceroute的源地址返回“目标不可达”的信息，在JUNOS当中显示为“!H”，类似IOS的“U”。
static {
route 200.200.0.0/24 reject;
}
nigel@itaa7.2# run traceroute 200.200.0.1
traceroute to 200.200.0.1 (200.200.0.1), 30 hops max,
40 byte packets
1 10.0.4.13 (10.0.4.13) 0.445 ms 0.448 ms 0.358 ms
2 10.0.2.1 (10.0.2.1) 0.849 ms 0.657 ms 0.632 ms
3 10.0.8.10 (10.0.8.10) 0.974 ms 0.897 ms 0.852 ms
4 10.0.8.10 (10.0.8.10) 1.085 ms !H 0.921 ms !H
0.864 ms !H使用Discard扩展参数，路由同样能被成功安装到OSPF路由器的路由表当中，然而我们向200.200/24网段发送出去的traceroute包都被丢弃，同时并不会返回一个明确的“目标不可达”的信息，发出的traceroute将超时。类似于IOS的“.”。
static {
route 200.200.0.0/24 discard;
}
nigel@itaa7.2# run traceroute 200.200.0.1
traceroute to 200.200.0.1 (200.200.0.1), 30 hops max,
40 byte packets
1 10.0.4.13 (10.0.4.13) 0.453 ms 0.474 ms 0.410 ms
2 10.0.2.1 (10.0.2.1) 0.737 ms 0.659 ms 0.622 ms
3 * * *在JUNOS 7.2版本上面，即便我们加入Receive扩展参数，假如需要在接收到路由的同时再ping通静态路由网段的目标IP，仍然需要在发布静态路由的路由器上将该网段内的一个IP地址配置到物理接口上以便测试。然而，在JUNOS更新的版本中，我们只需要加入Receive参数，在不存在物理接口IP地址的前提下，我们便可以在R1上ping通200.200/24全网段的IP地址，这样以来更方便了我们的测试。我们在这里使用的JUNOS版本为8.5：
static {
route 200.200.0.0/24 receive;
}
nigel@itaa8.5# run ping 200.200.0.1 rapid
PING 200.200.0.1 (200.200.0.1): 56 data bytes
!!!!!
--- 200.200.0.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.501/1.001/2.252/0.674 ms
nigel@itaa8.5# run ping 200.200.0.254 rapid
PING 200.200.0.254 (200.200.0.254): 56 data bytes
!!!!!
--- 200.200.0.254 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.228/1.669/1.997/0.327 msPreference是JUNOS对各种路由协议优先级的定义，等于IOS的管理距离。默认情况下，静态路由在JUNOS底下的Preference为5，我们可以通过Preference扩展参数，类似于在IOS里面设置浮动路由的时候使用的Distance参数。而Metric Tag扩展参数则是为静态路由重分布进入OSPF指定一个默认的Metric数值，以及标签。以上参数可以与刚才提及的三种扩展参数并用。我们修改了指向200.200/24网段静态路由的Preference为10，我们可以在R7本地路由表中进行验证。另外使用Metric Tag，分别指定该静态路由的默认Metric为10，并且打上标签“30”，我们可以在R1的路由表中验证。
static {
route 200.200.0.0/24 {
receive;
metric 10;
tag 30;
preference 10;
}
}
nigel@r7# run show route 200.200/24 exact
inet.0: 25 destinations, 25 routes (25 active, 0 holddown,
0 hidden)
+ = Active Route, - = Last Active, * = Both
200.200.0.0/24 *[Static/10] 00:03:57, metric 10, tag 30
Receive
nigel@r1# run show route 200.200/24 exact
inet.0: 23 destinations, 23 routes (23 active, 0 holddown,
0 hidden)
+ = Active Route, - = Last Active, * = Both
200.200.0.0/24 *[OSPF/150] 00:04:02, metric 10, tag 30
> to 10.0.4.13 via fxp1.13这是很重要的一个扩展参数，当我们的路由表当中存在多条静态路由，有的是网络的IP连通性而被创建，有的则是为了实现带外管理OoB，如我们经常借助路由器的fxp0接口连接网管网关。一般而言，我们不希望通过fxp0指向网管网关的静态路由被重分布到IGP当中。no-readvertise扩展参数正是为了避免这些静态路由被错误的使用Policy重分布到IGP当中。当我们将no-readvertise扩展参数应用到指向200.200/24网段的静态路由的时候，这条路由将不会因为我们上面所做的策略被重分布到OSPF里面。自然，从R1的路由表中消失掉。
static {
route 200.200.0.0/24 {
receive;
no-readvertise;
}
}
nigel@itaa7.2# run show route 200.200/24 | count
Count: 0 lines
JUNOS使用Policy对IP前缀进行策略性操作，包括但不局限于IOS的route-map概念及功能当中，在以后的案例中你会逐步体验到JUNOS中Policy的强悍。当我们在Policy下使用route-filter定义IP前缀范围，从而对特定路由进行匹配并运用Policy下定义的操作时，我们可以使用包括”exact”, “orlonger”, “longer”, “prefix-length-range”, “upto”, “through”等六种匹配类型进行定义。之前的五种route-filter的匹配类型实际上都非常容易让人理解，而我们今天关注的主题则聚焦在 其中一直让人费解的匹配类型 – “through”上面，并且通过“upto”与“through”之间的差异进行进一步的解释。之所以将”upto”拿来与“through”进行对比，主要考虑到它们两者看起来非常相似。而实际上你在上图中可以看出其实两者完全匹配的是不同的IP前缀。我们将在下面的实验中举例说明，同时感谢teamCymru的Stephen Gill，当时我碰到同样问题的时候，他的JUNOS ‘upto’ v. ‘through’ Route-filter Match-type文档给我很大的帮助。
在开始前，我假定你已经掌握了Binary-Tree/Radix-Tree的算法在IP二进制编址上的应用: J-Tree，从0/0开始逐步向下进行由一而二的分裂，成为0/1和128/1，如此类推直到IP编址的/32层。真正的Binary-Tree实际上不单纯被应用在IP编址上，话说回来实际上也就是我们中国人老祖宗所说的“无级生太极，太极生两仪，两仪生四象，四象生八卦”的原理。先给出总结的结论：
我们今天的例子：
route-filter 192.168.0.0/16 through 192.168.16.0/20/16小于/20，而从192.168/16开始的J-tree为:
192.168/16 /*以下192.168以.代替*/
.0/17; .128/17
.0/18; .64/18; .128/18; .192/18
.0/19; .32/19; .64/19; .96/19; .128/19; .160/19; .192/19; .224/19
.0/20; .16/20; .32/20; .48/20; .64/20; .80/20; .96/20 /*…余下省略*/
可以确认16/20也存在于0/16的J-tree底下，则从垂直方向开始匹配的网段为:
这个时候JUNOS不会继续垂直匹配192.168.0.0/20；而是直接拐弯到192.168.16.0/20上面，最终共匹配网段为五个。我们使用r1与r2两台点到点路由器，并通过在r2上通过route-filter过滤从r2发送到r1的RIP路由反过来验证上述的结论。注意，在JUNOS上进行Policy测试不一定通过通告路由更新的形式来检查，运维模式下的test policy命令同样能够实现相关的功能，只是由于test policy暂时在JUNOS 7.2版本下并不支持测试逻辑路由器下的策略，因此我们在这里还是使用通告RIP路由更新的方式测试。可能这样对你来说也会更加直观。
第一步：在r2上通过静态路由创建由192.168/16开始的J-tree，从192.168/16一直到192.168.240/20。
nigel@itaa7.2# show logical-routers r2 routing-options
static {
route 192.168.0.0/16 receive;
route 192.168.0.0/17 receive;
route 192.168.128.0/17 receive;
route 192.168.0.0/18 receive;
route 192.168.64.0/18 receive;
route 192.168.128.0/18 receive;
route 192.168.192.0/18 receive;
route 192.168.0.0/19 receive;
route 192.168.32.0/19 receive;
route 192.168.64.0/19 receive;
route 192.168.96.0/19 receive;
route 192.168.128.0/19 receive;
route 192.168.160.0/19 receive;
route 192.168.192.0/19 receive;
route 192.168.224.0/19 receive;
route 192.168.0.0/20 receive;
route 192.168.16.0/20 receive;
route 192.168.32.0/20 receive;
route 192.168.48.0/20 receive;
route 192.168.64.0/20 receive;
route 192.168.80.0/20 receive;
route 192.168.96.0/20 receive;
route 192.168.128.0/20 receive;
route 192.168.144.0/20 receive;
route 192.168.160.0/20 receive;
route 192.168.176.0/20 receive;
route 192.168.192.0/20 receive;
route 192.168.208.0/20 receive;
route 192.168.224.0/20 receive;
route 192.168.240.0/20 receive;
} 第二步：在r2上按照我们的案例制定through策略。
nigel@itaa7.2# show logical-routers r2 policy-options
policy-statement through {
term 1 {
from {
protocol static;
route-filter 192.168.0.0/16 through
192.168.16.0/20;
}
then accept;
}
} 第三步：将策略export到r2的rip组上面。
nigel@itaa7.2# show logical-routers r2 protocols rip
group rip {
export through;
neighbor fxp2.12;
} 第四步：在r1上查看到底有多少条路由通过RIP发送过来：
nigel@itaa7.2# run show route logical-router r1
protocol rip
inet.0: 8 destinations, 8 routes (8 active, 0 holddown,
0 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.0.0/16 *[RIP/100] 00:00:25, metric 2, tag 0
> to 10.1.12.2 via fxp1.12
192.168.0.0/17 *[RIP/100] 00:00:25, metric 2, tag 0
> to 10.1.12.2 via fxp1.12
192.168.0.0/18 *[RIP/100] 00:00:25, metric 2, tag 0
> to 10.1.12.2 via fxp1.12
192.168.0.0/19 *[RIP/100] 00:00:25, metric 2, tag 0
> to 10.1.12.2 via fxp1.12
192.168.16.0/20 *[RIP/100] 00:00:25, metric 2, tag 0
> to 10.1.12.2 via fxp1.12
224.0.0.9/32 *[RIP/100] 00:00:29, metric 1
MultiRecv
[edit]第五步：验证效果为JUNOS从192.168/16开始，垂直匹配到192.168/19，然后顺便将192.168.16.0/20带上并完成匹配。
第六步：我们尝试在r2上使用另外一个策略代替through：
nigel@itaa7.2# show logical-routers r2 policy-options
policy-statement upto-exact {
term 1 {
from {
route-filter 192.168.0.0/16 upto /19;
}
then accept;
}
term 2 {
from {
route-filter 192.168.16.0/20 exact;
}
then accept;
}
} 第七步：重新将策略export到r2的rip组上面：
nigel@itaa7.2# show logical-routers r2 protocols
rip {
group rip {
export upto-exact;
neighbor fxp2.12;
}
} 第八步：我们在r1上重新查看这个时候有多少条路由通过RIP发送过来：
nigel@itaa7.2# run show route logical-router r1
protocol rip
inet.0: 19 destinations, 19 routes (19 active, 0 holddown,
0 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.0.0/16 *[RIP/100] 00:02:48, metric 2, tag 0
> to 10.1.12.2 via fxp1.12
192.168.0.0/17 *[RIP/100] 00:02:48, metric 2, tag 0
> to 10.1.12.2 via fxp1.12
192.168.0.0/18 *[RIP/100] 00:02:48, metric 2, tag 0
> to 10.1.12.2 via fxp1.12
192.168.0.0/19 *[RIP/100] 00:02:48, metric 2, tag 0
> to 10.1.12.2 via fxp1.12
192.168.16.0/20 *[RIP/100] 00:02:48, metric 2, tag 0
> to 10.1.12.2 via fxp1.12
192.168.32.0/19 *[RIP/100] 00:02:48, metric 2, tag 0
> to 10.1.12.2 via fxp1.12
192.168.64.0/18 *[RIP/100] 00:02:48, metric 2, tag 0
> to 10.1.12.2 via fxp1.12
192.168.64.0/19 *[RIP/100] 00:02:48, metric 2, tag 0
> to 10.1.12.2 via fxp1.12
192.168.96.0/19 *[RIP/100] 00:02:48, metric 2, tag 0
> to 10.1.12.2 via fxp1.12
192.168.128.0/17 *[RIP/100] 00:02:48, metric 2, tag 0
> to 10.1.12.2 via fxp1.12
192.168.128.0/18 *[RIP/100] 00:02:48, metric 2, tag 0
> to 10.1.12.2 via fxp1.12
192.168.128.0/19 *[RIP/100] 00:02:48, metric 2, tag 0
> to 10.1.12.2 via fxp1.12
192.168.160.0/19 *[RIP/100] 00:02:48, metric 2, tag 0
> to 10.1.12.2 via fxp1.12
192.168.192.0/18 *[RIP/100] 00:02:48, metric 2, tag 0
> to 10.1.12.2 via fxp1.12
192.168.192.0/19 *[RIP/100] 00:02:48, metric 2, tag 0
> to 10.1.12.2 via fxp1.12
192.168.224.0/19 *[RIP/100] 00:02:48, metric 2, tag 0
> to 10.1.12.2 via fxp1.12
224.0.0.9/32 *[RIP/100] 00:02:53, metric 1
MultiRecv
第九步：最终验证为使用upto +exact才会在同时使用垂直与水平匹配，最后连同192.168.16.0/20带过来并完成匹配。
Juniper Networks最近向APAC合作伙伴发布了向已通过JNCIA-EX考试号(JN0-400)以及JNCIS-ES考试号(JN0-330)认证考试的考生颁发奖品的信息。如果你在2008年11月1日之前通过JNCIA-EX认证考试，那么你可以将考试成绩单电子档连同下载的申请表格，在2008年11月28日前发送给Juniper公司获得相关奖品。另外，Juniper Networks强调前30名提交的认证人员有机会获得特别神秘礼品？
详情可以在JNCIA-EX_certificationreward网页查阅。
稍微有点遗憾的是信息中提及本活动仅对东盟各国及印度、斯里兰卡生效，对于中国的考生有可能无法享受本次活动的权利。
Valid only in ASEAN, India & Sri Lanka.
另外以下为几则值得关注的信息：
到了这一节实验的尾声，我把之前的配置打包上传上来，你可能以后需要在本原始配置的基础上继续完成后面还有150页左右的OSPF操作手册。如果你自己安装了Olive或者ITAA-JUNOS虚拟机，那么你可以将配置文本在[edit logical-routers]层次底下使用load merge/override terminal将配置粘帖到JUNOS里面。如果有关于本实验的其它问题，欢迎你留言给我提出。由于众所周知的原因，我不能直接回应你关于Olive的问题。另外，假如Youtube上的连接速度对你来说太慢或者你还没有习惯在线视频点播的方式，你也可以到ITAA的Juniper技术论坛下载之前的三个视频录像离线收看。
在验证配置的时候，大部分情况下，我们不需要在所有路由器上进行核查。特别在JNCIx那种时间紧迫的实验室考试环境中。对于OSPF，ISIS链路状态路由协议而言，找到一台核心的路由器进行验证往往能够节省大量的时间。
例如昨天的OSPF多区域实验中，当我们要验证OSPF邻接关系的时候，由于邻接关系必然是产生在两台路由器之间，我们只需要在其中一台路由器上面进行验证，便可确定邻接关系建立。而在多路访问网络上面，更理想的核心路由器选择则在于DR/BDR上面，一旦在DR/BDR上面确认邻接关系建立，那么我们便能确定所有连接在同一多路访问网络上的其他路由器都被正确建立起来。根据实验拓扑，我们选择在R3，R5，R7上面查看邻居关系状态。
[edit logical-routers]
nigel@itaalab# run show ospf neighbor logical-router r3
Address Interface State ID Pri Dead
10.0.2.6 fxp1.34 Full 10.0.3.4 128 34
10.0.2.1 fxp1.35 Full 10.0.3.5 128 32
nigel@itaalab# 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 36
10.0.2.10 fxp2.45 Full 10.0.3.4 128 36
10.0.8.5 fxp1.56 Full 10.0.9.6 128 39
10.0.8.10 fxp1.57 Full 10.0.9.7 128 36
[edit logical-routers]
nigel@itaalab# run show ospf neighbor logical-router r7
Address Interface State ID Pri Dead
10.0.8.1 fxp1.67 Full 10.0.9.6 128 35
10.0.8.9 fxp2.57 Full 10.0.3.5 128 35通过对比路由器ID，我们确认R3与R4；R5与R3/R4/R6/R7；R7与R6都符合实验需求建立FULL的OSPF邻接关系。
而在多区域OSPF路由环境当中，对于OSPF数据库的验证，选择区域边界路由器ABR往往是不错的一个选择。我们能够迅速的在ABR验证多个OSPF区域数据库。根据实验拓扑，我们认为R5上面应该有6条LSA-1，其中3条在区域0，另外3条在区域1当中；由于ABR R5同时向区域0和区域1各发送1条LSA-1，因此它的OSPF数据库LSA-1应该共有6条。
而JUNOS的管道输出符也能替我们计算LSA的数量。
nigel@itaalab# run show ospf database logical-router r5
router area 0
OSPF link state database, area 0.0.0.0
Type ID Adv Rtr Seq Age Opt Cksum Len
Router 10.0.3.3 10.0.3.3 0x80000003 200 0x2 0x6769 72
Router 10.0.3.4 10.0.3.4 0x80000004 191 0x2 0x3a61 60
Router *10.0.3.5 10.0.3.5 0x80000004 190 0x2 0x1191 60
[edit]
nigel@itaalab# run show ospf database logical-router r5
router area 1
OSPF link state database, area 0.0.0.1
Type ID Adv Rtr Seq Age Opt Cksum Len
Router *10.0.3.5 10.0.3.5 0x80000004 192 0x2 0x564c 48
Router 10.0.9.6 10.0.9.6 0x80000004 198 0x2 0x974 60
Router 10.0.9.7 10.0.9.7 0x80000004 198 0x2 0x6e01 60
[edit]
nigel@itaalab# run show ospf database logical-router r5
router | match router | count
Count: 6 lines对于链路状态路由协议的路由，我一直强调检查所有OSPF路由器环回接口路由是否到达的重要性。因为环回接口的IP路由依赖于直连网段路由，一旦确认环回接口路由被成功安装，那么在大部分情况下直连网段的路由不会出现太大的问题。而在JUNOS上所有环回接口均采用32位主机路由，我们同样可以使用管道输出符来检查IP路由表。
nigel@itaalab# run show route logical-router r5
protocol ospf | match /32
10.0.3.3/32 *[OSPF/10] 00:07:14, metric 10
10.0.3.4/32 *[OSPF/10] 00:07:04, metric 10
10.0.9.6/32 *[OSPF/10] 00:07:09, metric 10
10.0.9.7/32 *[OSPF/10] 00:07:09, metric 10
224.0.0.5/32 *[OSPF/10] 00:08:08, metric 1我们在R5上确认其余4台路由器的环回接口地址均通过OSPF路由被安装进入路由表，R5自身的环回接口地址没有出现是因为在R5上属于[Direct/0]路由，而224.0.0.5/32为OSPF路由器通用多播地址。在JNCIx考试中，核查路由是很重要的一环，这里没有其他捷径，为了保证你的配置成果，最好在所有路由器上确认路由。
而对于T1与R3之间172.16.0.12/30这段路由，我们不需要键入完整的IP网段地址来查看，JUNOS提供一个方便的查看路由表的方法，我们只需要查询172.16/16网段路由，所有存在于路由表当中的掩码长于16位，属于172.16这个IP子网的路由都会被显示出来。
nigel@itaalab# run show route logical-router r5
protocol ospf 172.16/16
inet.0: 17 destinations, 17 routes (17 active, 0 holddown,
0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.0.12/30 *[OSPF/10] 00:21:33, metric 20
> to 10.0.2.2 via fxp2.35
点击上文↑链接至YouTube收看高清版本实验视频
根据实验需求，我们还需要将T1与R3之间的链路以域内路由形式在区域0.0.0.0产生，同时，保证该链路上不会产生OSPF邻接关系。我们可以使用JUNOS对于IGP的被动通告特性，一方面将该接口的IP网段通告至路由协议当中，另一方面则在该接口上抑制Hello包发布，从而使得路由器不会在该链路上建立邻居/邻接关系。
protocols {
ospf {
area 0.0.0.0 {
interface fxp1.34;
interface fxp1.35;
interface fxp1.30 {
passive;
}
}
}
}查看R5的路由表，确认172.16.0.12/30这个网段已经通过OSPF进入路由表；需要注意的是与IOS不同，在JUNOS中，对于OSPF的域外及域内路由具有不同的优先级(Preference)，其中，域内的OSPF Preference为10，而域外的OSPF路由Preference则为150.
nigel@www.itaalab.com# run show route logical-router r5
protocol ospf 172.16/16
inet.0: 17 destinations, 17 routes (17 active, 0 holddown,
0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.0.12/30 *[OSPF/10] 00:01:34, metric 20
> to 10.0.2.2 via fxp2.35查看R3的OSPF邻居，确认R3只跟R2/R5建立两个OSPF邻接关系：
nigel@www.itaalab.com# run show ospf neighbor logical-router r3
Address Interface State ID Pri Dead
10.0.2.6 fxp1.34 Full 10.0.3.4 128 34
10.0.2.1 fxp1.35 Full 10.0.3.5 128 39
点击上文↑链接至YouTube收看高清版本实验视频
注意，在上面的步骤中我们仅修改了R3上的RID配置。对于大部分网络工程师工程师而言，尽管任由OSPF自动选择环回接口作为OSPF的RID是已一件理所当然的事情，然而我个人依然坚持建议手动配置每台路由器的RID ─ 即便配置的是相同的IP地址。这样做的好处无非一方面你能够肯定，而不是依靠路由协议动态确认RID究竟是哪个；另一方面，对于别的联调工程师而言，他们能够以最快的速度通过阅读你的配置来了解每台路由器的RID. 这样做的目的在于使得你的配置通过一致，统一的标准而更具备生命力以及扩展性 ─ 正如我不惜牺牲一些用户界面的技巧而仅仅为了使得Weblog上的XHTML源代码完全匹配W3C的标准。另外，将RID设置成为一个特别的IP字段也许是一个不错的选择，如0.0.0.13. 回到认证考试的主题上面，JNCIx考试除了是一个难度挑战型的考试以外更是一个陷阱排除技术考试。假如我们使用JUNOS的OSPF RID特性自动发布RID IP网段，区域边界路由器ABR将把这个IP网段作为OSPF的LSA-1在它所连接的所有区域当中发布。如果我们要满足实验目标3所提及的“骨干区域内的路由器Loopback接口以LSA-3形式在区域0.0.0.1产生”这个需求，我们便不能使用JUNOS的OSPF RID自动泄露特性。
nigel@www.itaalab.com# run show ospf database logical-router
r3 router lsa-id 10.0.3.5 detail
OSPF link state database, area 0.0.0.0
Type ID Adv Rtr Seq Age Opt Cksum Len
Router 10.0.3.5 10.0.3.5 0x80000011 186 0x2 0xf69e 60
bits 0x1, link count 3
id 10.0.2.1, data 10.0.2.1, Type Transit (2)
TOS count 0, TOS 0 metric 10
id 10.0.2.9, data 10.0.2.9, Type Transit (2)
TOS count 0, TOS 0 metric 10
id 10.0.3.5, data 255.255.255.255, Type Stub (3)
TOS count 0, TOS 0 metric 0
[edit]
nigel@www.itaalab.com# run show ospf database logical-router
r7 router lsa-id 10.0.3.5 detail
OSPF link state database, area 0.0.0.1
Type ID Adv Rtr Seq Age Opt Cksum Len
Router 10.0.3.5 10.0.3.5 0x8000000f 1394 0x2 0x195c 60
bits 0x1, link count 3
id 10.0.8.5, data 10.0.8.6, Type Transit (2)
TOS count 0, TOS 0 metric 10
id 10.0.8.10, data 10.0.8.9, Type Transit (2)
TOS count 0, TOS 0 metric 10
id 10.0.3.5, data 255.255.255.255, Type Stub (3)
TOS count 0, TOS 0 metric 0
除了手动指定R5的RID地址为环回接口地址，我们还需要手动将环回接口在区域0.0.0.0发布，以保证该网段以LSA-3的形式出现在区域0.0.0.1当中。
[edit logical-routers]
nigel@www.itaalab.com# set r5 routing-options
router-id 10.0.3.5
[edit logical-routers]
nigel@www.itaalab.com# set r5 protocols ospf
area 0.0.0.0 interface lo0.5 passive
[edit logical-routers]
nigel@www.itaalab.com# commit check
configuration check succeeds
[edit logical-routers]
nigel@www.itaalab.com# commit
commit complete修改配置以后再查看R7的OSPF数据库，可以发现骨干区域路由器R5的RID网段10.0.3.5/32已经从LSA-1（ROUTER）转变为LSA-3（SUMMARY）在区域0.0.0.1发布，满足实验目标3的需求。另外，由于在环回接口上面不需要建立OSPF邻居/邻接关系，我们在发布的时候加入PASSIVE参数，一边抑制多余的周期性OSPF HELLO包发送，从而进一步优化路由器性能。注意，仅仅为了满足实验目标我们不得不硬性将R5的RID网段在骨干区域发布，而当面对真实的JNCIx考试的时候，ABR RID IP网段多区域自动泄露这一特性可能会为你带来新的解答方案体验。
nigel@www.itaalab.com# run show ospf database
lsa-id 10.0.3.5 logical-router r7 detail
OSPF link state database, area 0.0.0.1
Type ID Adv Rtr Seq Age Opt Cksum Len
Router 10.0.3.5 10.0.3.5 0x80000011 134 0x2 0x3c59 48
bits 0x1, link count 2
id 10.0.8.5, data 10.0.8.6, Type Transit (2)
TOS count 0, TOS 0 metric 10
id 10.0.8.10, data 10.0.8.9, Type Transit (2)
TOS count 0, TOS 0 metric 10
Summary 10.0.3.5 10.0.3.5 0x80000001 134 0x2 0x831 28
mask 255.255.255.255
TOS 0x0, metric 0protocols {
ospf {
area 0.0.0.0 {
interface fxp2.35;
interface fxp2.45;
interface lo0.5 {
passive;
}
}
area 0.0.0.1 {
interface fxp1.56;
interface fxp1.57;
}
}
}
routing-options {
router-id 10.0.3.5;
}