JNCIE/JNCIP实验室考试北京考场

juniper-lab
照片来源:Sun Qian’s 图片博客

其实很多人都知道,JNCIEJNCIP实验室考试在中国的考场实际上就是Juniper的培训室。如果对于Juniper实验室考试现场比较陌生的话,可以到源站浏览更多的图片。简单注明几点:

1. 考试的时候,考官与考生之间格局大概就是正常的讲师与学员这样面对面的格局,而CCIE在香港的考场,考官却会坐在你身后。2. 考试的时候,考官的信息,联系方式,每个考生的Rack号,以及登录IP等会写在白板上。3. 穿红衣服的学员前面那台笔记本如果没有看错的话应该就是Juniper提供的Dell;有的人说是“死亡笔记…本”,不过据我所知确实有人用它也通过JNCIE。4. 门口贴的是考试那段时间的考生出席日程表。5. 出门左拐,往前走几步,在你右手边就有个冰箱,可以在里面取可乐饮料之类的。6. 图中的讲师不是我考试时候碰到的几位考官之一。Good Luck.

JUNOS静态路由常见扩展参数

1. static route x/y reject

在我们的例子中,我们在远程路由器上配置的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

2. static route x/y discard

使用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  * * *

3. static route x/y receive

在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 ms

4. static route x/y perference/metric tag

Preference是JUNOS对各种路由协议优先级的定义,等于IOS的管理距离。默认情况下,静态路由在JUNOS底下的Preference5,我们可以通过Preference扩展参数,类似于在IOS里面设置浮动路由的时候使用的Distance参数。而Metric Tag扩展参数则是为静态路由重分布进入OSPF指定一个默认的Metric数值,以及标签。以上参数可以与刚才提及的三种扩展参数并用。我们修改了指向200.200/24网段静态路由的Preference10,我们可以在R7本地路由表中进行验证。另外使用Metric Tag,分别指定该静态路由的默认Metric10,并且打上标签“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

5. static route x/y no-readvertise

这是很重要的一个扩展参数,当我们的路由表当中存在多条静态路由,有的是网络的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 Route-filter ‘through’ 疑难解析

junos-route-filter
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
在开始前,我假定你已经掌握了Binary-Tree/Radix-Tree的算法在IP二进制编址上的应用: J-Tree,从0/0开始逐步向下进行由一而二的分裂,成为0/1和128/1,如此类推直到IP编址的/32层。真正的Binary-Tree实际上不单纯被应用在IP编址上,话说回来实际上也就是我们中国人老祖宗所说的“无级生太极,太极生两仪,两仪生四象,四象生八卦”的原理。先给出总结的结论:

  1. 使用route-filter /a through /b的时候,JUNOS仅沿着J-tree的垂直方向进行匹配;而不会向水平方向进行匹配。
  2. 掩码/a必须小于或等于掩码/b
  3. 掩码/b必须存在于/a的J-tree底下,即存在于以/a为根再次分裂出来的二进制树底下。
  4. JUNOS垂直匹配到掩码/b的层次时,则脱离原有的匹配轨迹拐弯到/b上面。
  5. 至此匹配结束。
  6. 使用“through”的结论:“through”实际上为一系列“Excat”匹配前缀的集合。

我们今天的例子:

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底下,则从垂直方向开始匹配的网段为:

  • 192.168.0.0/16
  • 192.168.0.0/17
  • 192.168.0.0/18
  • 192.168.0.0/19

这个时候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为JNCIA-EX认证者颁奖

jncia-exJuniper 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.

另外以下为几则值得关注的信息:

JUNOS OSPF常用验证命令及技巧

到了这一节实验的尾声,我把之前的配置打包上传上来,你可能以后需要在本原始配置的基础上继续完成后面还有150页左右的OSPF操作手册。如果你自己安装了Olive或者ITAA-JUNOS虚拟机,那么你可以将配置文本在[edit logical-routers]层次底下使用load merge/override terminal将配置粘帖到JUNOS里面。如果有关于本实验的其它问题,欢迎你留言给我提出。由于众所周知的原因,我不能直接回应你关于Olive的问题。另外,假如Youtube上的连接速度对你来说太慢或者你还没有习惯在线视频点播的方式,你也可以到ITAA的Juniper技术论坛下载之前的三个视频录像离线收看。
downloads

点击下载: OSPF多区域实验配置

在验证配置的时候,大部分情况下,我们不需要在所有路由器上进行核查。特别在JNCIx那种时间紧迫的实验室考试环境中。对于OSPF,ISIS链路状态路由协议而言,找到一台核心的路由器进行验证往往能够节省大量的时间。

JUNOS OSPF Hacks 1

例如昨天的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邻接关系。

JUNOS OSPF Hacks 2

而在多区域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 OSPF Hacks 3

而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

JUNOS OSPF Hacks 4

对于链路状态路由协议的路由,我一直强调检查所有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考试中,核查路由是很重要的一环,这里没有其他捷径,为了保证你的配置成果,最好在所有路由器上确认路由。

JUNOS OSPF Hacks 5

而对于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

Labs: JUNOS OSPF多区域配置 – Part 3

junos_ospf_multiarea

实验演示: JNCIP Labs 1.1: JUNOS OSPF多区域配置 第三部分

点击上文↑链接至YouTube收看高清版本实验视频

4. JUNOS IGP被动通告(PASSIVE)特性

根据实验需求,我们还需要将T1与R3之间的链路以域内路由形式在区域0.0.0.0产生,同时,保证该链路上不会产生OSPF邻接关系。我们可以使用JUNOS对于IGP的被动通告特性,一方面将该接口的IP网段通告至路由协议当中,另一方面则在该接口上抑制Hello包发布,从而使得路由器不会在该链路上建立邻居/邻接关系。

R3 JUNOS 更新配置:

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

Labs: JUNOS OSPF多区域配置 – Part 2

junos_ospf_multiarea

实验演示: JNCIP Labs 1.1: JUNOS OSPF多区域配置 第二部分

点击上文↑链接至YouTube收看高清版本实验视频

3. OSPF ABR RID IP网段多区域自动泄露

注意,在上面的步骤中我们仅修改了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 0

ABR – R5 JUNOS 更新配置:

protocols {
    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;
}

Labs: JUNOS OSPF多区域配置 – Part 1

junos_ospf_multiarea

实验演示: JNCIP Labs 1.1: JUNOS OSPF多区域配置 第一部分

点击上文↑链接至YouTube收看高清版本实验视频

如果你正在阅读JUNOS101系列,不用担心,我会继续把这个项目完成。只是为了在Juniper101研讨会的实验演示前,预先把第一个OSPF实验的笔记放上来。在《互联自由之路》第一卷中的OSPF部分,我将几个之前一直在CCIE实验室考试中占据着重要比重的必备实验剔除了出去,而首当其冲的便是对于Routing and Switching CCIE考生而言,最为关键及挑战性的OSPF在NBMA网络环境中的几种解决方案。原因很简单,它们落伍了。假如你仍然为CCIE而努力的话,我建议你最好将这经典的一页全部读完 ─ 或许这已经不是最好的建议。回到实验上,我们从最简单的OSPF多区域配置开始,本实验包含的目标如下所示:

  1. 使用Loopback接口地址作为路由器ID(RID)
  2. 所有Loopback接口地址应该能够通过OSPF学习并访问
  3. 骨干区域内的路由器Loopback接口以LSA-3形式在区域0.0.0.1产生
  4. T1与R3之间的链路以域内路由形式在区域0.0.0.0产生;同时,保证该链路上不会产生OSPF邻接关系

先完成初步配置,这对于大部分接触过JUNOS的人来说应该不难,略去相关叙述,仅把5台路由器的OSPF部分相关配置列出。根据拓扑所示,我们只需要直观的将相关接口放置在对应区域通告即可,并没有什么挑战性;唯一需要注意的一点是:区别于IOS通过通告IP网段至某个区域,JUNOS采用组织架构将接口归纳入各个区域里面通告,即便日后需要修改IP网段地址,也无需重新更改OSPF路由协议的通告设置。

R3 JUNOS初步配置:

protocols {
    ospf {
        area 0.0.0.0 {
            interface fxp1.34;
            interface fxp1.35;
        }
    }
}

R4 JUNOS初步配置:

protocols {
    ospf {
        area 0.0.0.0 {
            interface fxp2.34;
            interface fxp1.45;
        }
    }
}

R5 JUNOS初步配置:

protocols {
    ospf {
        area 0.0.0.0 {
            interface fxp2.35;
            interface fxp2.45;
        }
        area 0.0.0.1 {
            interface fxp1.56;
            interface fxp1.57;
        }
    }
}

R6 JUNOS初步配置:

protocols {
    ospf {
        area 0.0.0.1 {
            interface fxp2.56;
            interface fxp2.67;
        }
    }
}

R7 JUNOS初步配置:

protocols {
    ospf {
        area 0.0.0.1 {
            interface fxp1.67;
            interface fxp2.57;
        }
    }
}

接着我们做初步的检查测试OSPF接口及邻居状态。

[edit logical-routers]
nigel@www.itaalab.com# run show ospf interface 
logical-router r5

Interface  State   Area       DR ID      BDR ID  Nbrs
fxp2.35    DR     0.0.0.0    10.0.3.5   10.0.3.3   1
fxp2.45    DR     0.0.0.0    10.0.3.5   10.0.3.4   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

输出结果显示:R5共有4个接口在OSPF里面通告,同时下划线标示部分显示在区域0.0.0.0和区域0.0.0.1当中,R5分别通告了两个接口。另外每个接口均建立起一个邻居关系,我们可以通过下面的命令进一步确认。

[edit logical-routers]
nigel@www.itaalab.com# 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   37
10.0.2.10  fxp2.45        Full    10.0.3.4   128   35
10.0.8.5   fxp1.56        Full    10.0.9.6   128   35
10.0.8.10  fxp1.57        Full    10.0.9.7   128   38

1. JUNOS OSPF路由器ID(RID)特性

[edit]
nigel@www.itaalab.com# run show route protocol ospf
logical-router r5 | match /32
10.0.3.3/32        *[OSPF/10] 04:23:47, metric 10
10.0.3.4/32        *[OSPF/10] 04:23:47, metric 10
10.0.9.6/32        *[OSPF/10] 04:23:41, metric 10
10.0.9.7/32        *[OSPF/10] 04:23:42, metric 10
224.0.0.5/32       *[OSPF/10] 04:49:45, metric 1

查看R5路由表,我们发现,在之前的配置当中,虽然我们并没有将各台路由器的环回接口通过OSPF发布,然而除R5本地环回接口地址以外,其他4台路由器环回接口地址均通过OSPF被R5学习并且安装至路由表当中。

[edit]
nigel@www.itaalab.com# run ping 10.0.3.3 logical-router 
r5 source 10.0.3.5 rapid
PING 10.0.3.3 (10.0.3.3): 56 data bytes
!!!!!
--- 10.0.3.3 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.400/0.448/0.477/0.027 ms

同时,我们在R5上使用本地环回接口IP地址作为源地址发送PING包到R3上面,不难发现R3实际上也通过OSPF学习到R5的环回接口地址并且安装进入路由表当中。这里需要了解JUNOS在OSPF路由协议当中对于RID网段的特性。对于JUNOS路由守护进程(RPD)而言,它优先选择本地环回接口地址作为第一地址而被应用为OSPF路由器ID.因此,即便我们没有手动指定每台路由器的RID地址,JUNOS依然会自动为我们挑选每台路由器的环回接口地址作为OSPF的RID. 默认情况之下,JUNOS自动为被选举成为RID的IP网段产生一条末节路由,并通过OSPF通告。因此,尽管我们在之前的配置当中并没有明确通告每台路由的的环回接口地址到OSPF区域当中,所有OSPF路由器依然能够学习到其他路由器的环回接口地址。我们可以通过查看OSPF数据库,通过另外一个角度进行验证。

[edit]
nigel@www.itaalab.com# run show ospf database logical-router
r5 router lsa-id 10.0.3.3 detail 

    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  0x8000000f  1868  0x2  0xd6cd  60
  bits 0x0, link count 3
  id 10.0.2.6, data 10.0.2.5, Type Transit (2)
  TOS count 0, TOS 0 metric 10
  id 10.0.2.1, data 10.0.2.2, Type Transit (2)
  TOS count 0, TOS 0 metric 10
  id 10.0.3.3, data 255.255.255.255, Type Stub (3)
  TOS count 0, TOS 0 metric 0

2. OSPF手动指定RID

我们可以为R3手动指定另外一个物理接口,而不是环回接口作为OSPF路由器ID,此时JUNOS对于环回接口IP网段自动通告的特性将会失效。假如我们依然需要访问R3的环回接口,我们需要手工将环回接口在OSPF协议下进行通告。

[edit logical-routers r3]
nigel@www.itaalab.com# set routing-options router-id 10.0.2.5 

[edit logical-routers r3]
nigel@www.itaalab.com# commit
commit complete

nigel@www.itaalab.com# run restart routing logical-router r3
r3 started, pid 3223

nigel@www.itaalab.com# run show ospf neighbor logical-router r5
Address      Interface    State    ID            Pri  Dead
10.0.2.2   fxp2.35         Full    10.0.2.5      128   33
10.0.2.10  fxp2.45         Full    10.0.3.4      128   33
10.0.8.5   fxp1.56         Full    10.0.9.6      128   34
10.0.8.10  fxp1.57         Full    10.0.9.7      128   35

由于修改了OSPF路由器ID,我们需要重新启动R3路由进程,当R5与R3重新建立邻居关系以后,R3的路由器ID从10.0.3.3修改为我们手工指定的10.0.2.5,同时查看R5的路由表和OSPF数据库,原R3路由器ID的IP网段 ─ 10.0.3.3/32网段,也没有被自动通告。

nigel@www.itaalab.com# run show route logical-router r5
10.0.3.3/32  | count
Count: 0 lines

nigel@www.itaalab.com# run show ospf database logical-router
r5 router lsa-id 10.0.2.5 extensive 

    OSPF link state database, area 0.0.0.0
 Type    ID     Adv Rtr   Seq          Age  Opt  Cksum  Len
Router 10.0.2.5 10.0.2.5  0x8000000a   351  0x2  0x3e89  48
  bits 0x0, link count 2
  id 10.0.2.6, data 10.0.2.5, Type Transit (2)
  TOS count 0, TOS 0 metric 10
  id 10.0.2.1, data 10.0.2.2, Type Transit (2)
  TOS count 0, TOS 0 metric 10
  Aging timer 00:54:09
  Installed 00:05:48 ago, expires in 00:54:09, 
  sent 00:05:48 ago

JUNOS配置协助

space-tab-key-in-junos-cli当你使用命令行界面(CLI)配置JUNOS的时候,假如你已经对IOS非常熟悉,那么在JUNOS上你同样能够获得类似的协助体验。包括命令的自动完成,使用问号查询命令以及命令后的参数等等功能。稍有不同的地方在于JUNOS使用空格键替你自动完成命令输入 ─ 终于让我的双手都能够实现自动补全命令的操作,这对我个人而言很重要,因为我在使用输入法输入中文的时候,总是习惯使用右手敲空格确认输入。假如你的工作环境要求你像我那样需要同时配置JUNOS与IOS,你也大可不必太过担心当转换回IOS的时候适应不了没有空格键时候的感觉。至少这段时间不会太长,因为在JUNOS下面,IOS的自动补全键制表符(tab)不但可以与空格键同时承担完成命令的工作。它还有更重要的作用 ─ 它能够帮你自动完成诸如JUNOS软件名称,加载配置名称,接口名称,策略名称,甚至路由协议底下不同组的名称……等用户定义名参数的输入。我不知道你已经有多少次因为错误输入IOS文件名而导致升级失败;多少次为了要逐字逐句输入ACL的名称而感到郁闷,或者是多少次为了避免错误删除IOS底下某个的route-map,而不得不使用SecureCRT上的“复制并粘帖”功能。从这个角度上而言,SecureCRT不愧是配置IOS时候的好帮手。而对于JUNOS而言意义并不大,因为tab键便能够为你自动完成这系列参数的输入。现在想回来,当时我迁移到mac上并没有经历多大的痛苦可能也跟这个原因有关。当然,当我要配置IOS的时候那就成另外一码事了。

另外一个重要的协助功能便是JUNOS的在线文档帮助,Juniper将与JUNOS软件版本相对应的文档也打包到JUNOS里面。

[edit]
nigel@itaa7.2# run show version
Hostname: itaa7.2
Model: olive
JUNOS Base OS boot [7.2R4.2]
JUNOS Base OS Software Suite [7.2R4.2]
JUNOS Kernel Software Suite [7.2R4.2]
JUNOS Packet Forwarding Engine Support (M20/M40) [7.2R4.2]
JUNOS Routing Software Suite [7.2R4.2]
JUNOS Online Documentation [7.2R4.2]
JUNOS Crypto Software Suite [7.2R4.2]

因此,你完全没有必要在配置JUNOS的时候在旁边放置一本配置手册或者Document CD。你可以随时要求JUNOS分别向你提供技术主题与配置细节的帮助。譬如你在配置MPLS网络的时候需要了解关于OSPF sham-link的信息,你首先可以使用help topic从JUNOS得到关于sham-link的介绍。这是我经常使用的命令之一,因为它能帮助我在短时间内得到包括如何实现在内的浓缩的技术信息。

[edit]
nigel@itaa7.2# help topic ospf sham-link
Configuring a Sham Link

   You can create an intra-area link or sham link between
   two provider edge (PE) routers so that the VPN backbone
   is preferred over the back-door link. Each sham link is
   identified by the combination of a local endpoint address
   and a remote endpoint address.

   To configure a sham link, include the sham-link statement:
     [edit protocols ospf area area-id]
     sham-link {
         local-endpoint address;
         remote-endpoint address {
             metric metric;
         }
     }

   For a list of hierarchy levels at which you can configure
   this statement, see the statement summary section for
   this statement.

   To configure the local endpoint address, specify the
   local-address statement. To configure the remote endpoint
   address, specify the remote-address statement. To configure
   the remote endpoint metric value, specify the metric
   statement.

而当你需要进一步了解相关的语法,能够在JUNOS的哪些层次架构下配置,或者具体参数的用法时,help reference会给你进一步关于配置命令的信息。

[edit]
nigel@itaa7.2# help reference ospf sham-link
sham-link

      Syntax

   sham-link {
       local-endpoint address;
       remote-endpoint address {
           metric metric;
       }
   }

      Hierarchy Level

   [edit logical-routers logical-router-name protocols
ospf area area-id],
   [edit protocols ospf area area-id]

      Description

   Configure a sham link.

      Options

   local-endpoint address--Local endpoint address.

   remote-endpoint address--Remote endpoint address.

   metric--Metric value for the remote endpoint.

   The remaining statements are explained separately.

      Usage Guidelines

   See "Configuring a Sham Link".

      Required Privilege Level

   routing--To view this statement in the configuration.
   routing-control--To add this statement to the configuration.

想象一下假如你在参加实验室考试的时候不再需要来回切换窗口查阅文档,该是多么舒服的事情。稍微有点遗憾的是Juniper仅将表格打包入在线文档里面,假如能将图片等信息一便打包进去的话,那将会是更让人愉快的事情。在字符转换技术如此普及的今天,这应该不是太难的问题。

.ossssssssssssssssssssssssssssssssssssssssssssssssssso.
+hhhhhyyyhyyyyhhhyyyhyyyhhhyyyhhhhyssyhhhhhhsssyhhyyyy+
+hhhhh:  yo  :hhh. +h-  -yh+ -hh/` `` .ohy: `.` .shs+++
+hhhhh:  yo  :hhh. +h- ` .y+ -h/  ohh:  so  :osooyhhhh+
+hhhhh:  yo  :hhh. +h- o: `: -h. `hhho  +h/.    .ohhhh+
+hhhhh:  hs  -hhh` +h- oh/   -h/  ohh/  so++hys. `hhhh+
+hhy``  :hh:` `.` -yh- ohh+  -hh/` .` .oho. `.` .ohhhh+
+hhhsssyhhhhhysssyhhhysyhhhysyhhhhyssyhhhhhysssyhhhhhh+
.ossssssssssssssssssssssssssssssssssssssssssssssssssso.

不是吗?

JUNOS配置管理

配置JUNOS,如同编辑WORD文档般方便、快捷、安全

Managing a JUNOS Configuration

记得我在2002年,刚开始接触JUNOS的时候,整个过程都让人感觉兴奋与激动;正如我在之前两篇讨论JUNOS commit的文档中所提及的,与IOS配置即时生效的特性相比,JUNOS的commit配置激活机制能更有效的降低人为失误所造成的网络故障。你所输入的所有配置对于JUNOS而言仅仅是一个待选配置(Candidate Configuration),仅当你确认全部配置无误而进行commit提交后,这份待选配置文件才被转变成为当前的活动配置文件(Active Configuration)生效,而你接着在它的副本基础上通过继续对路由器进行配置而创建新的一份待选配置。当然,虽然待选配置经过确认才会被commit激活,然而并不表示你的配置就一定会使得网络状态按照你设想的结果运行。你同样有可能会面临由于配置失误(不是输入失误)而造成的各种问题。此时你或者需要将配置回退到前一个活动配置的版本上面去。就好像我们在使用Office的时候经常需要使用undo功能一样,然而这种普遍的操作在IOS里面往往并不是那么简单。而JUNOS的rollback/save/load则允许你在某种程度上就像编辑MS Office Word文档一样编辑路由器的配置文件,比起VI,word要轻松很多。

JUNOS – rollback n

JUNOS自动为你保存之前50次commit后创建的活动配置副本,其中最后一次被commnit的副本也就是当前运行的配置编号为0,而被取代的上一个活动配置编号为1,以此类推。因此假如你发现commit以后网络出现问题而希望回退到上一个配置版本的话,那么你只需要使用rollback 1,然后重新commit一次即可,就像word的undo或者ctrl+z快捷键一样简单。而假如你在commit之前觉得当前的待选配置存在太多错误,而想直接撤销所有改动,回退到刚开始没有做任何修改的配置。正如直接不保存文档退出word,然后重新打开一样;JUNOS实现起来甚至比word要更快,你只需要执行rollback 0就可以了,连commit都不需要。

JUNOS – save / load override / load merge

更绝的还有word的另存为…(save as…)与全选(select all)/粘帖(paste),对于JUNOS同样不存在任何难度。JUNOS的save命令让用户将当前配置副本保存在该用户的主目录下面。在保存配置副本的时候需要注意如果你需要把整个配置文件保存下来,首先你需要使用top返回到配置层次的顶层[edit]上面。否则你所保存的仅仅是从[edit]到当前层次以下的配置,例如你在[edit protocols bgp]下使用save保存,你保存的仅仅是从[edit]到BGP协议层次下的配置信息。到你想使用前面保存下来的配置文件覆盖当前配置的时候,只需要load override然后指定源配置文件名即可。此时当前的配置会被清空而被加载的配置文件内容完全取代。覆盖行为相当于IOS的copy running startup。而另一种加载的方式为load merge,此时当前配置并不会被清空,而被加载的配置会合并到当前配置里面。合并行为相当于IOS的copy tftp running。注意我只是借用IOS用于对比的只是merge和override之间的区别;而JUNOS并不存在startup-config或者running-config。

JUNOS – load replace

那么在word底下编辑文档,更多的情况下可能仅仅是部分选定,然后复制(copy)或者剪切(cut)/粘帖(paste),来实现部分覆盖,而一般很少会使用全选覆盖的方式。同样JUNOS允许你对配置文件进行部分覆盖。上文提到,当你需要备份整个JUNOS配置文件的时候,你需要返回[edit]层次上进行save操作。而当我们在次级层次下进行save操作的时候,实际上JUNOS相当于使得我们将选定的层次以下部分的配置,复制到剪贴板(clip broad)中去一样。可以看到选定的部分被打上replace:的标识。我们进入逻辑路由器r1的OSPF协议层次下,此时等于用鼠标把该层次下配置内容的选定,然后在该层次下用save命令将其复制。

[edit logical-routers r1 protocols ospf]
nigel@itaa7.2# save nigelmeng-ospf
Wrote 23 lines of configuration to 'nigelmeng-ospf'

[edit logical-routers r1 protocols ospf]
nigel@itaa7.2# run file show nigelmeng-ospf
logical-routers {
    r1 {
        protocols {
replace:
            ospf {
                export 3/8;
                reference-bandwidth 10m;
                area 0.0.0.10 {
                    nssa;
                    interface lo0.1 {
                        passive;
                    }
                    interface fxp1.12;
                    interface fxp1.13;
                }
                area 0.0.0.5 {
                    interface fe-0/0/0.0;
                    interface fe-0/0/1.0;
                }
            }
        }
    }
}

之后我们把新的接口fe-0/0/2加入到OSPF区域5里面。

[edit logical-routers r1 protocols ospf]
nigel@itaa7.2# set area 5 interface fe-0/0/2    

[edit logical-routers r1 protocols ospf]
nigel@itaa7.2# show
export 3/8;
reference-bandwidth 10m;
area 0.0.0.10 {
    nssa;
    interface lo0.1 {
        passive;
    }
    interface fxp1.12;
    interface fxp1.13;
}
area 0.0.0.5 {
    interface fe-0/0/0.0;
    interface fe-0/0/1.0;
    interface fe-0/0/2.0;
}

之后,我又希望将原来的OSPF协议配置替换回来,那么我们只需要使用load replace将刚才复制的配置粘帖(paste)回去就可以了。JUNOS只会使用带replace:标识的内容覆盖当前配置文件中相对应的部分。

[edit logical-routers r1 protocols ospf]
nigel@itaa7.2# load replace nigelmeng-ospf
load complete

[edit logical-routers r1 protocols ospf]
nigel@itaa7.2# show
export 3/8;
reference-bandwidth 10m;
area 0.0.0.10 {
    nssa;
    interface lo0.1 {
        passive;
    }
    interface fxp1.12;
    interface fxp1.13;
}
area 0.0.0.5 {
    interface fe-0/0/0.0;
    interface fe-0/0/1.0;
}

噢,对了,在word里面还有搜索(search)/替换(replace)文本的功能呢。

对,把整个配置文件贴到word里面,替换以后再贴回去不就行了?我为什么能想到配置JUNOS与word之间的关系?很简单,因为我正用word来写这篇文档嘛。