学习笔记: Internet cheat sheets on PacketLife

Stretch@packetlife一直在blog上发布一系列技术Cheat Sheets ── 浓缩式技术笔记,或者是考试前提前准备的小抄。:-D 这些Cheat Sheets涵盖了包括BGP、IS-IS、OSPF、802.11、QoS……甚至Physical Terminations等各方面的内容,每一份都是一到两页纸的PDF文件,是很好的一套个人复习笔记。我个人并没有仔细阅读其中的内容,同时希望对您有所帮助。当然,Stretch所做的远远不止单纯发布学习笔记和Cheat Sheets,相对而言应当说这他的兴趣更为准确。详细的信息请参考Site Transition and Other Stuff.

另外,这些Cheat Sheets的国际版目前也正在寻找志愿协作人员,这里有一个BGP Cheat Sheet的法语版本。目前还没有找到中文简体版本的协作者,Stretch编辑的Cheat Sheets无论从界面,还是实用性上面取决于各人观念差异,相信仍然会吸引很大一部分网络工作人员的眼球。如果您有兴趣,可以联系Stretch,相信他会欢迎您的协助。PS: 考虑到版权原因,请到PacketLife上下载相关的资料,下面是相关资料截图 ──

Protocols – BGP

tn_BGP.pdf

Protocols – IS-IS

tn_IS-IS.pdf

Protocols – OSPF

tn_OSPF.pdf

Protocols – EIGRP / First Hop Redundancy

tn_EIGRP.pdftn_First_Hop_Redundancy.pdf

Protocols – IEEE 802.11 WLAN

tn_IEEE_802.11_WLAN.pdf

Protocols – IEEE 802.1x / IPsec

tn_IEEE_802.1X.pdftn_IPsec.pdf

Protocols – IPv4 Multicast / IPv6

tn_IPv4_Multicast.pdftn_IPv6.pdf

Protocols – Spanning Tree

tn_Spanning_Tree.pdf

Applications – Wireshark Display Filters

tn_Wireshark_Display_Filters.pdf

Reference – tcpdump / IOS IPv4 Access Lists

tn_tcpdump.pdftn_IOS_IPv4_Access_Lists.pdf

Reference – IPv4 Subnetting / Common Ports

tn_IPv4_Subnetting.pdftn_common-ports.pdf

Technologies – QoS

tn_QoS.pdf

Technologies – Frame Mode MPLS / VLANs

tn_Frame_Mode_MPLS.pdftn_VLANs.pdf

Miscellaneous – Cisco IOS Versions / Physical Terminations

tn_Cisco_IOS_Versions.pdftn_physical-terminations.pdf

Miscellaneous – Markdown / MediaWiki

tn_Markdown.pdftn_MediaWiki.pdf

Advertisements

JNCIP: JUNOS OSPF虚链路配置 – Part 2

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上的认证配置,继续下面的实验。

Juniper/Cisco Interoperability Simulator – iJunOS

juniper-your-net1ITAA is offering the Juniper JUNOS and Cisco IOS interoperability simulating lab gear – iJunOS torrent for bt downloading now. iJunOS software subscriptions appliances deliver advanced routing and security in an affordable, flexible package that scales from the personal internetworking technology studying, lab practise to the multiple OS interoperability research.

NOTES: Related document is available in Simplified Chinese, and it runs on the VMware Player infrastructure as a plug-and-play packaged file.

And we DO NOT offer any system level installation and configuration supports. Bugs reporting will be acceptable by leaving comments under this post, yet adjusting recommendations is NOT guaranteed.

downloadsClick to Download:
ITAA iJunOS Version 3.0 Torrent

– Registration may be required.

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

JUNOS与IOS OSPF接口开销调节

kangaroo

  1. 基于带宽优化路由选择:保证所有快速以太网接口被自动分配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

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

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

kangaroo

  1. R6/R7必须将10.0.5/24路由通告给RIP路由器,同时R7上通告的RIP路由Metric应大于R6上的通告;
  2. 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

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

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

kangaroo

  1. 汇总所有的非骨干区域路由进入骨干区域,包括内部路由以及外部路由;
  2. 汇总来自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
  <cr>

同样,可以在骨干区域路由器上查看两边非骨干区域的明细网段是否仅匹配路由表内的汇总路由,从而确认地址汇总被成功配置。我们将查询两边区域内的直连网段路由及各路由器的环回接口网段:在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 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: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-listroute-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

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

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

kangaroo

  1. 区域0.0.0.1内不会出现LSA-3或者LSA-5;
  2. 区域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)#are 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