JUNOS 101更新: Juniper JUNOS EBooks on iPAD

现在,Juniper JUNOS Day One 系列的全套书籍都可以在iPAD上免费阅读。

For iPads and iPhones, use your device’s iBook app to download directly to your device. Search for “Juniper Networks” in the iBookstore.

The Day One book series are available for FREE download in PDF format using the book links below. Some books also feature a “Copy and Paste” edition for easy copying of Junos configurations.

除此以外,JUNOS 电子书还支持其它终端平台,包括:Kindles, Androids, Blackberry, iPhones/iPads, Macs and PCs. 目前已经出版的Day One 书籍包括:

Junos Fundamentals Series

Junos Automation Series

Junos Dynamic Services Series

Junos Fabric And Switching Technologies Series

Junos Networking Technologies Series

Advertisements

JUNOS 101更新: Day One – 部署MBGP组播VPN

The networking industry has been looking for the best way to offer Multicast VPN services while leveraging the strength and scalability of the existing unicast technology. The result of several year’s effort is Multi-Protocol BGP Multicast VPN, often referred to as MBGP MVPN. This technology has received a warm welcome in the market and is already deployed in many production networks, ranging from Tier-1 service providers to financial and trading companies.

This Week: Deploying MBGP Multicast VPNs assumes the reader has at least some experience with IP/MPLS architectures, including Multi-Protocol BGP and IGPs, but you need not be an expert in Multicast as the basic concepts are revisited in the book.
Whatever you bring to this book will only be amplified by the clear explanations, the explicit samples, and its attention to detail. Step-by-step the author walks you through a technology that can be explored and stood up in a week. Roll up your sleeves. It’s time to get down to work.

Deploying Multicast VPNs

JUNOS 101更新: Day One – 部署MPLS

While there are many books and papers available that cover network architecture, MPLS services, and MPLS cores, none put all these subjects together in a ‘beginning-to-end’ walk-through methodology using myriad configuration examples for Juniper routers, with explanations for each configuration. This Week: Deploying MPLS is a seminar-in-a- book on the process of designing and standing up a MPLS core, as well as provisioning MPLS services such as L3VPN, VPLS, and Layer 2 circuits.

This Week: Deploying MPLS

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

提升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

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

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

ospf virtual-link

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

实验目标:

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

关键点评

  1. JUNOS OSPF虚链路上的邻居认证;
  2. JUNOS实时流量嗅探与跟踪调试OSPF协议信息;
  3. 提升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

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.