
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 /a through /b的时候,JUNOS仅沿着J-tree的垂直方向进行匹配;而不会向水平方向进行匹配。
- 掩码/a必须小于或等于掩码/b。
- 掩码/b必须存在于/a的J-tree底下,即存在于以/a为根再次分裂出来的二进制树底下。
- JUNOS垂直匹配到掩码/b的层次时,则脱离原有的匹配轨迹拐弯到/b上面。
- 至此匹配结束。
- 使用“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带过来并完成匹配。