JUNOS 10.0发布

JUNOS 10.0版增强了路由、安全和交换特性，包括：MX系列多机箱LAG；VOIP、无线支持、支持集成融合服务的SRX210和SRX240业务网关的新接口；以及EX系列产品的光收发器和热插拔上行链路模块等。

路由平台

多机箱链路汇聚组
MX系列路由器现在可以提供多机箱链路汇聚（MC-LAG）功能，支持一个客户设备与两个MX设备构成逻辑LAG接口。这两个MX设备分别作为主用和备用设备。

使用无环替代路由为OSPF提供IP快速重路由（IP FRR）支持
这一特性在M、MX和T系列路由器及TX Matrix中，添加了面向OSPF的快速重路由功能。JUNOS操作系统能够为所有的OSPF路由预先计算无环备份路由。这些备份路由预装在数据包转发引擎中。当面向特定路由的主用next hop链路发生故障时，该引擎能够执行本地修复任务并激活备用路径。

基于数据包的IPsec服务
对于配备服务PICS或DPC的JUNOS平台而言，这一特性为基于数据包的IPsec服务添加了可选支持。此特性可支持用户在服务集内混合使用无流IPsec和基于流的IPsec。

接口范围
JUNOS路由、交换和安全产品具备接口范围配置语句，可以让共享通用配置文件的同类型接口成为一组，从而减少配置接口所需的时间和工作。用户可将所有接口通用的配置包含在接口范围定义中。

面向NG MVPN的IPv6
基于多协议BGP的组播VPN（又称下一代L3 VPN组播），可采用RSVP-TE隧道，在IPv4核心网络中传输IPv6组播客户流量。这一特性无需核心网络支持IPv6。J、M、MX和T系列路由器及TX Matrix均提供了面向 NG MVPN的IPv6支持。

面向NG MVPN的共享树
对于基于多协议BGP的组播VPN（又称下一代L3 VPN组播）而言，这一特性可支持《BGP-MVPN草案》第13节中介绍（draft-ietf-l3vpn-2547bis-mcast-bgp- 00.txt）的所有RPT-SPT运行模式。M、MX和T系列路由器均具备此特性，可在C-PIM实例中提供共享树支持。

VoIP BGF（边界网关功能）容量增强技术
除了原有的RE选项外，在MS-PIC和MS-DPC上添加H.248控制处理选项，能够为BGF提供更多的灵活性和容量。例如，如果对一个 MX960使用多个BGF实例，并且开启MS-DPC提供的H.248控制功能，那么，每个机箱支持的并发语音会话的数量最多可达10万个。

面向VoIP BSG信令引擎的高可用性
当在MS-DPC和MS-PIC上运行SIP SBC服务时，这一特性能够添加1:1的高可用性。通过此特性，您将能够构建VoIP媒体和信令功能的高可用性配置。

面向PPPoE 会话的宽带网络网关（BNG）选择性
这一特性有助于在BNG群集之间实现PPPoE会话的负载均衡。此外，该特性还能根据备用BNG对PADI的延迟响应情况，为PPPoE会话提供 BNG冗余。您可在群集中选择一个BNG，根据配置好的服务名称表终止指定的PPPoE会话。该服务名称表中包含服务名称及可选的ACI和ARI字符串等项目。M120和M320路由器均支持此特性。

VLAN接口的动态验证
这一特性支持基于MX系列和M320路由器用户生成的控制或数据流量，对自感VLAN实施RADIUS验证。通过验证后，RADIUS服务器将提供一个LS:RI，自感VLAN在此进行创建。此特性支持动态L3 wholesale环境。在这一环境中，系统将在与零售ISP相对应的路由域中动态创建用户VLAN。

RADIUS服务器轮询
MX系列的这一特性支持在配置完备的一系列RADIUS服务器之间，采用轮询机制分发认证和记账消息，从而在多个RADIUS服务器之间均衡分配RADIUS交互负载。

Demux接口（DSI）上的组播功能
MX系列的这一特性支持BNG在demux用户接口（DSI）上执行组播复制任务，或者，BNG可基于通过demux用户接口接收的IGMP交易数据，对MC-VLAN执行“OIF-map”功能。IGMP在demux接口上采用被动模式运行，单个IGMP在底层主接口上采用主动模式运行。

安全平台

支持集成融合服务的SRX210和SRX240业务网关
我们增强了支持集成融合服务的SRX210和SRX240业务网关的现有功能，包括提供IP语音（VoIP）功能及支持WAN和LAN连接的多个接口。除支持会话初始协议（SIP）/模拟语音信号之外，SRX210和SRX240业务网关还支持其它许多特性，包括3G无线、数字用户线路接入复用器（DSLAM）、以太网供电（PoE）等。此产品只在北美洲销售。

集成融合服务
集成融合服务能够优化并保护VoIP通信和应用。这些特性支持开放融合架构，并允许用户灵活选择SIP呼叫服务器、IP电话和电信运营商。JUNOS 10.0可帮助SRX210和SRX240设备支持广泛的VoIP功能和特性，包括：

• MGW——基于标准的SIP媒体网关（MGW），可将VoIP网络与PSTN相连接，以便用户通过本地模拟电话、传真机或SIP IP电话建立或接收呼叫。当SRX系列MGW处于活动状态时，数据中心或其它位置的SIP对等呼叫服务器，可以为分支办事处提供呼叫处理和呼叫路由服务。
• SCS——survivable call server（SCS），可在用户无法连接ISP对等呼叫服务器时，为分支办事处提供本地呼叫处理服务和基本的呼叫路由服务。
• 呼叫等待音乐——支持在呼叫等待时播放以前加载的音乐文件。
• 基于策略的路由——支持用户通过媒体网关路由呼叫，而不是在网关中发起或终止呼叫。

全新接口模块
这些全新的接口模块适用于支持集成融合服务的SRX210和SRX240业务网关，不能单独使用：

• 4端口FXO迷你物理接口模块
• 2端口FXS/2端口FXO迷你物理接口模块

此外，G.SHDSL迷你物理接口模块也可应用于SRX210和SRX240业务网关。

AX411接入点

AX411接入点可为配备Wi-Fi适配器和驱动器的无线客户端提供网络接入能力，并且支持IEEE 802.11n无线网络标准，能够向后兼容IEEE 802.11a/b/g标准。用户可使用SRX210、SRX240或SRX650设备来配置和管理AX411接入点。
通用分组无线服务（GPRS）

GPRS网络可连接多个外部网络，包括漫游合作伙伴、公司客户、GPRS漫游交换机（GRX）供应商的网络及公共互联网。GPRS网络运营商一方面需要支持和控制用户对外部网络的访问，另一方面还需要保护网络安全。SRX3400、SRX3600、SRX5600和SRX5800设备提供了大量的 GPRS特性，以确保其安全性。

全新的统一威胁管理（UTM）特性
Junos 10.0提供了全新的UTM特性：

• 瞻博网络本地Web过滤功能——支持防火墙拦截TCP连接中的每个HTTP请求，并且提取URL进行分类。SRX100、SRX210、SRX240、 SRX650和J系列设备均支持此特性。
• UTM WELF支持——支持采用WebTrends Enhanced Log file Format（WELF）格式发送日志文件信息。SRX100、SRX210、SRX240和SRX650设备均支持此特性。

IDP AppDDoS防护
SRX3400、SRX3600、SRX5600和SRX5800设备现均支持IDP AppDDoS防护功能。虽然从L3和L4的角度看，应用DDoS攻击似乎是合法交易，但此特性可使用应用级指标来区分有效和无效的应用请求，从而采取适当行动。

全新的应用层网关（ALG）
SRX3400、SRX3600、SRX5600和SRX5800均支持以下应用层网关（ALG）：

• PPTP ALG——点对点隧道协议（PPTP）是L2协议，能够在TCP/IP网络上使用隧道来传输PPP数据。
• RSH ALG——远程Shell（RSH）ALG，处理发往端口514的TCP数据包，以及RSH端口命令。
• RTSP ALG——实时流协议（RTSP）ALG是控制流媒体服务器的网络控制协议。
• TALK ALG——TALK协议使用UDP端口517和端口518来支持控制通道连接。Talk程序包含服务器和客户端。

SRX100、SRX210、SRX240和J系列设备均支持这些ALG。

双控制链路
SRX5600和SRX5800产品采用这一特性，在群集中的每个设备之间连接两条控制链路，从而有效降低了控制链路的故障几率。这项功能需要在群集中的每个设备上安装第二个路由引擎，并且安装第二个交换控制板（SCB）来托管SRX5000系列产品的路由引擎。通过采用两条控制链路，可帮助避免单点故障，大幅度降低因控制链路故障而引发的中断。

永久性NAT
除了原有的其他SRX系列产品外，现在，SRX3400、SRX3600、SRX5600和SRX5800产品也开始支持这一特性。（注：永久性 NAT有时也称为“Cone NAT”。 “Cone NAT”一词已被互联网工程任务组（IETF）替换为 “永久性NAT”）。

交换平台

热插拔上行链路模块
EX3200和EX4200交换机中的上行链路模块，可在不断电或者不中断交换机运行的情况下被移除或更换。交换机能够检测出新安装的上行链路模块或全新的收发器，并且能够创建所需的接口。

全新的光收发器
EX3200和EX4200交换机中的SFP上行链路模块可支持两个全新的光收发器：

• EX-SFP-1FE-LX40K（100Base-LX40K，40千米）
• EX-SFP-1FE-LH（100Base-LH/100Base-ZX，80千米）

EX8200现可通过SFP+直连式铜缆（DAC）连接10GbE：

• EX-SFP-10GE-DAC-1M
• EX-SFP-10GE-DAC-3M
• EX-SFP-10GE-DAC-7M

多VLAN注册协议（MVRP）
EX系列交换机可通过多VLAN注册协议（MVRP），管理局域网中的VLAN动态注册。MVRP是多注册协议（MRP）的应用协议，IEEE 802.1ak标准对其进行了定义。

VLAN ID转换
VLAN ID转换功能，可将具有不同VLAN ID标记的流量映射到EX系列交换机中的单一VLAN中。利用这一特性，交换机可将原有的VLAN标记转换为全新的VLAN标记。有些流量需要在多个网络中完成同样的处理，当此类流量穿越EX系列交换机上的接入接口时，VLAN ID转换功能将发挥作用。

L2协议隧道穿越
EX系列交换机支持L2协议隧道穿越（L2PT）功能。交换机可以通过电信运营商网络发送L2协议数据单元（PDU），并将它们传输给不属于本地广播域的交换机。

接口范围
接口范围配置语句，可让共享通用配置文件的同类型接口成为一组，从而减少在EX系列交换机上配置接口所需的时间和工作。用户可将所有接口通用的配置包含在接口范围定义中。

汇聚以太网接口上的防火墙过滤器
EX8200交换机现可在L2和L3汇聚以太网接口上支持防火墙过滤器。在汇聚以太网接口上，以下盲点可部署防火墙过滤器：

• 入口-端口和路由器接口
• 出口-端口和路由器接口

动态TCAM
在EX3200和EX4200交换机上，我们取消了针对特定类型防火墙过滤器（如应用于端口、VLAN或路由器接口的防火墙过滤器）而设置的TCAM内存使用限制。现在，TCAM内存可根据防火墙过滤器的配置动态地进行分配，与防火墙过滤器类型无关。

代理ARP
在EX系列交换机上，除了不受限制的默认模式外，用户还能在受限模式中配置代理ARP。当在受限的代理ARP模式中设置接口后，该接口不能代理同一个子网中的主机。同样，当您在接口上配置代理ARP后，该代理ARP仅适用于这个接口，而不适用于全局。

JUNOS 101更新: Juniper JUNOS – Day One系列(2)

Update some books since I issued JUNOS 101更新: Juniper JUNOS – Day One系列(1) in last year.

JUNOS Fundamentals Series

This Day One series introduces the JUNOS OS to new users, one day at a time. This handy set of booklets starts at the beginning with the practical steps and knowledge to set up and operate any device running JUNOS. The JUNOS Fundamental Series includes:

Exploring the JUNOS CLI

The command-line interface is the software interface to access your Junos device. Learn the essentials about its commands and mechanics, including how to navigate the interface and both the operational and configuration modes. After reading, you will be able to:

• Understand the hierarchies within each mode.
• Get onboard help and use keyboard shortcuts to speed up your work.
• Show device status, alarms, and other helpful information in operational mode.
• Modify, save, and load configuration files with minimal risk to operations.
• Use basic configuration mode commands such as show, set, and delete.
• Capitalize on the safety features of the Junos commit model.
• Prepare system changes in advance.
• Use the shortcuts and tips of experienced users and avoid common problems.

Configuring JUNOS Basics

Configure the basic settings of your device and learn more about configuration mode in this booklet. You’ll learn the first steps to configuring a Junos device, whether you are setting up a router, switch, or security platform. After reading, you will be able to:

• Create a handy checklist of settings to use in configuring the system basics.
• Create login accounts and permissions.
• Set up SNMP to work with your existing systems.
• Monitor your device remotely and configure system logs.
• Install Web-based management.
• Make changes faster with configuration shortcuts.
• Streamline device setup with configuration groups and templates.
• Compare your resulting configuration to the booklet example.

JUNOS Automation Series

This Day One series helps you to begin using the powerful Junos OS tools for automating the methods and procedures of your network with step-by-step instructions and lots of examples. The Junos Automation Series includes:

Applying JUNOS Operations Automation

Junos automation is a set of tools to automate the operational methods and procedures of a network. Understand how Junos automation tools work, how to write and use op scripts that can optimize Junos commands to your environment, and where to find out more. After reading, you will be able to:

• Explain where to use the different Junos script types.
• Use reference scripts from this book and Juniper’s script library.
• Interpret the XML data structures used by Junos devices.
• Communicate with Junos through the Junos XML API.
• Ease how you write XML data structures using the SLAX XML abbreviated format.
• Read SLAX scripts and understand the operations they perform.
• Create your own customized operation scripts.

Applying JUNOS Event Automation

Event automation instructs Junos of actions to take in response to system events through event policies and event scripts. Use event automation to speed time-to-resolve, minimize the impact of events and automate time-of-day changes. After reading, you will be able to:

• Understand the difference between an op script and an event script.
• Identify potential events that could be automated.
• Build the needed event policy to match desired events and conditions.
• Correlate multiple events and determine the proper response to those events based on their relationship to each other.
• Create your own customized event scripts.

Applying JUNOS Configuration Automation

Configuration automation provides a way to add customized intelligence as part of the commit process used by Junos to validate configuration changes. Commit scripts can control the commit process in multiple ways ranging from simple warning messages to complex configuration changes based on the presence of configuration macros. This booklet shows you how to:

• Understand the role of and possible uses for commit scripts.
• Provide feedback as part of the commit process through warning or syslog messages.
• Halt the commit process with error messages.
• Alter the configuration through commit scripts.
• Use configuration macros to simplify your configuration or to store specialized data.
• Create your own customized commit scripts.

华讯网络 – 中标广东移动IP城域网一期项目

勇于创新，敢为人先！

凭籍这份精神，华讯广州办运营商团队携8台CRS-1成功中标广东移动IP城域网一期项目。这不仅标志着思科最高端的路由器CRS-1正式进入广东移动 —— 同时，华讯广州办运营商团队也将承担起为广东移动建立第一张IP城域网的重任。

然而，广州办运营商团队并未陶醉于胜利的喜悦中，相反我们清晰地意识到：更大的挑战即将到来！由于本次项目进度紧迫，加上广东移动对首次城域网建设的高度重视，华讯广州办运营商团队的工程师们、每天加班加点，甚至一日走三城，亲赴现场进行CRS-1硬件安装督导以及加电测试工作。短短的两周时间内，在广州思科、深圳、北京同事们的共同协助下，目前已完成全部8台CRS-1在广州、中山、佛山、江门等四个节点的设备和业务板卡安装以及加电测试。整个过程中，我们无不感受到客户对我们这支高效、专业、敬业、团结的工程技术队伍的认同与赞叹，为华讯赢得卓越的口碑。

本次广东移动IP城域网的全面铺设，无疑一举打破以往由一、两家固网运营商独大的局面。IP城域网作为CMNET和IP专用承载网在本地网的延伸，将直接接入企业用户，更好的树立中国移动优秀的服务品牌。另一方面，CMNET国家骨干跨域MPLS/VPN已成功实现其既定测试计划，中国移动数据网络将更好的适应企业用户，特别是在全国各地存在分支机构的大中型集团用户，未来对语音、数据及多媒体信息业务的需求，凸显中国移动作为综合信息业务供应商在3GPPIMS平台上的竞争优势。相对于传统的固网运营商，尽管移动IP城域网的建设起步较晚，而通过借鉴固网运营商的建设经验，广东移动完全可以选择在更高的起点、应用更先进的软/硬技术，建设以全业务运营为基础的IP融合网络，以鲜明的业务定位在全业务竞争环境下重新抢占先机。

随着广东移动IP城域网业务发展趋势的逐步明朗化，可以预见，广东移动对汇聚路由器、业务路由器进行大规模扩容的计划已是刻不容缓。作为新网络建筑师，华讯广 州办运营商团队将凭借与广东移动一样，对卓越服务的共同追求，成就广东移动与华讯网络持续紧密的合作。

华讯网络 – 力助广东移动打造稳健业务平台

为迎接广州2010年亚运会并满足承载3G数据业务的网络需求，自2009年4月，历经八个凌晨，华讯广州SP工程师团队与广东移动的网管维护中心人员共同成功对CMNET-GD广东省网的全网24个节点设备进行了冗余倒换演练，包括：——

4台Juniper M320核心路由器
48台Juniper M320/M40e/M20汇聚路由器
21台Juniper M20/M10专线接入路由器
76台Cisco 7609/7206/6509/4506/4506L3业务接入层路由器/交换机
43台Cisco 4506/3745/3660/3640/3560带外网管路由器/交换机

华讯工程师在存在320,000条国际路互联网由的数据应用业务平台上，完成了对全网设备彻底的健康检查；对全部542条上联及互联链路切换；对路由器整机掉电重启测试；设备引擎及电源模块切换等全套演练流程。华讯SP团队在对移动网络及其业务的深刻认知，过硬的现场实施技术，以及与网维人员之间的密切配合的基础下，整个演练项目最终取得完满的成功。并且达到了：倒换演练过程中，移动用户零投诉、客户零投诉，以及对数据业务零影响的高水平转换测试。充分显示了中国移动CMNET-GD省网的高度可靠与高度稳健的特点。同时，在整个演练过程中我们队CMNET-GD省网深入挖掘所发现的潜在隐患均一一上报网维人员，并提出改善建议，进一步将CMNET-GD省网打造为最为稳健的业务平台。

继之前在广东移动CMNET-GD省网设备维护及技术支持项目年度的服务打分中取得96.7分的佳绩，我们再次充分感受到客户对华讯广州SP团队在多厂商互联共通的业务网络中所提供技术顾问与咨询支持的专注、敬业与服务价值的认同。华讯广州SP团队将一如既往的为客户持续提供应有的，并超越客户期望质量的网络服务，持续为广东移动打造高性能的业务数据精品传输平台。

华讯网络 -《财富》2009年中国最适宜工作的公司

Source

2003年以来，华信惠悦和《财富》中文版合作，从事“卓越雇主”的研究。自那时起，华信惠悦已经收集了超过6,000名雇员和400家公司的意见。我们的WorkChinaTM调查反映了外资企业、国内企业及合资企业的情况，已经成为有关中国雇员态度的领先数据库和分析资料。通过该研究计划，我们不仅分析了“卓越雇主”，还分析了它们在中国成功培养雇员敬业度的秘诀。

出于这一目的——找出在中国培养雇员敬业度的关键，华信惠悦再度欣然与《财富》合作，提交我们的2009年WorkChinaTM调查结果，并公布“中国卓越雇主”。

更多内容请访问源站点。

附录：2009 年卓越顾主上榜公司名单

• 安博教育集团
• 东方证券股份有限公司
• 福建福诺移动通信技术有限公司
• 福建网龙计算机网络信息技术有限公司
• 华讯网络系统股份有限公司
• 环球市场集团
• 李宁体育用品
• 玫琳凯（中国）化妆品股份有限公司
• 孟山都
• 宁波银行股份有限公司
• 瑞泰人寿保险有限公司
• 山东过桥缘餐饮连锁经营有限公司
• 深信服科技电子有限公司
• 思博伦通信
• 腾讯公司
• 瓦里安
• 优酷网
• 越秀企业（集团）有限公司
• 中国移动通信集团上海有限公司
• 中联绿盟信息技术（北京）有限公司

fw：华为海南“干扰门”事件?

本贴之全部内容均转帖自外部网站，不代表本人观点及立场，请审慎阅读。如对帖子内容存在异议，请与原帖作者联系，特此声明！

　　首先声明，本人首先是土生土长海南人，在电信系统工作，为生计考虑挂了马甲在这里爆料，请各位朋友理解在下难处。

　　事情原委是这样，6月份农业部和电信集团就近海CDMA覆盖签了个协议，要求几个沿海大省海洋厅和电信省公司进行合作。由于是国家级的项目，王大老板非常重视此事，并提出海洋覆盖建设的投资，由集团出专项资金来做。于是公司就赶紧找了两家设备公司对各自的覆盖能力做测试，为建网做准备。

　　8月29日，测试时间、方案、封网要求等事情都做了，一切按部就班，完全没想到，竟然有意想不到的情况发生！一点左右，测试区域开始有用户投诉手机信号问题严重，中午大概一点多，公司接到另一家测试公司的举报电话，说昌化测试区的一家酒店内发现强信号干扰源，并已报了警。

　　省公司这边立即通知昌江电信局派人去现场了解情况，在现场看到被武警控制的华为员工和大量设备，包括电脑，笔记本，1T2R的RRU一个、YBT250一台、天线2副等发射接收设备。（我没去到现场，事后看到同事传来的照片，后附）随后派出所的所长和干警赶到，取证和拍照后，华为的人就被带回派出所录口供了。

　　国家搞重大项目造福渔民，竟然也出了这么大的事，素闻华为的什么狼性文化，平时跟他们的员工接触也不少，没想到违法犯罪的事情都能干，总算是开了眼界！

　　第二天下午，省公司相关部门牵头紧急组织了协调会，目的是希望保障项目进度，继续测试。没想到华为代表赵彦君相当嚣张，在事实面前不仅不承认，还可笑地要求“继续调查”。据参会的同事说，看到华为这种贼喊捉贼的恶劣表演，在场的省公司领导都忍不现场发飙。这场会议最后以不了了之收场。

　　由于华为公司的行动不仅破坏了测试工作，还严重干扰了当地现网频段，让当地通讯中断数小时。此事件已经被公安机关以涉嫌“破坏通讯安全罪”立案。不过这最新的情况还不清楚。

　　真是没想到，一家在国内国外还海外都还赫赫有名的公司竟然做的是这样的勾当，强烈呼吁省公司和集团领导秉持正义，尊重法律，考虑广大渔民的长期权益，坚决不能选择华为这样为了抢夺订单不择手段、惟利是图的无良企业！

图1：事发现场：昌化镇金海轮旅馆

图2：报案后赶到现场的警察

图3：现场发现的华为干扰设备

图4：被查获的华为设备特写，标签清晰可鉴

图5：华为实施的干扰也严重影响了当地人民正常生产生活，附近手机频繁掉线，基本无法通话

图6：被现场逮捕的华为员工留在桌面的“工作笔记”，赫然写着“4个小时大搞”的惊人字样

学习笔记: 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

Protocols – IS-IS

Protocols – OSPF

Protocols – EIGRP / First Hop Redundancy

Protocols – IEEE 802.11 WLAN

Protocols – IEEE 802.1x / IPsec

Protocols – IPv4 Multicast / IPv6

Protocols – Spanning Tree

Applications – Wireshark Display Filters

Reference – tcpdump / IOS IPv4 Access Lists

Reference – IPv4 Subnetting / Common Ports

Technologies – QoS

Technologies – Frame Mode MPLS / VLANs

Miscellaneous – Cisco IOS Versions / Physical Terminations

Miscellaneous – Markdown / MediaWiki

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

注意：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