rfc5889.IP Addressing Model in Ad Hoc Networks
计算机网络端口0-9090及作用
1tcpmux TCP Port Service Multiplexer传输控制协议端口服务多路开关选择器2compressnet Management Utility compressnet 管理实用程序3compressnet Compression Process压缩进程5rje Remote Job Entry远程作业登录7echo Echo回显9discard Discard丢弃11systat Active Users在线用户13daytime Daytime时间17qotd Quote of the Day每日引用18msp Message Send Protocol消息发送协议19chargen Character Generator字符发生器20ftp-data File Transfer[Default Data]文件传输协议(默认数据口)21ftp File Transfer[Control]文件传输协议(控制)22ssh SSH Remote Login Protocol SSH远程登录协议---SSH23telnet Telnet终端仿真协议---telnet24?any private mail system预留给个人用邮件系统25smtp Simple Mail Transfer简单邮件发送协议---smtp27nsw-fe NSW User System FE NSW 用户系统现场工程师29msg-icp MSG ICP MSG ICP31msg-auth MSG Authentication MSG验证33dsp Display Support Protocol显示支持协议35?any private printer server预留给个人打印机服务37time Time时间38rap Route Access Protocol路由访问协议---rap39rlp Resource Location Protocol资源定位协议41graphics Graphics图形42nameserver WINS Host Name Server WINS 主机名服务---wins43nicname Who Is"绰号" who is服务44mpm-flags MPM FLAGS Protocol MPM(消息处理模块)标志协议45mpm Message Processing Module [recv]消息处理模块46mpm-snd MPM [default send]消息处理模块(默认发送口)47ni-ftp NI FTP NI FTP48auditd Digital Audit Daemon数码音频后台服务49tacacs Login Host Protocol (TACACS)TACACS登录主机协议50re-mail-ck Remote Mail Checking Protocol远程邮件检查协议51la-maint IMP Logical Address Maintenance IMP(接口信息处理机)逻辑地址维护52xns-time XNS Time Protocol施乐网络服务系统时间协议53domain Domain Name Server域名服务器---dns54xns-ch XNS Clearinghouse施乐网络服务系统票据交换55isi-gl ISI Graphics Language ISI图形语言56xns-auth XNS Authentication施乐网络服务系统验证57?any private terminal access预留个人用终端访问58xns-mail XNS Mail施乐网络服务系统邮件59?any private file service预留个人文件服务60?Unassigned未定义61ni-mail NI MAIL NI邮件?62acas ACA Services异步通讯适配器服务63whois+ whois+WHOIS+64covia Communications Integrator (CI)通讯接口65tacacs-ds TACACS-Database Service TACACS数据库服务66sql*net Oracle SQL*NET Oracle SQL*NET67bootps Bootstrap Protocol Server引导程序协议服务端68bootpc Bootstrap Protocol Client引导程序协议客户端69tftp Trivial File Transfer小型文件传输协议70gopher Gopher信息检索协议71netrjs-1Remote Job Service远程作业服务72netrjs-2Remote Job Service远程作业服务73netrjs-3Remote Job Service远程作业服务74netrjs-4Remote Job Service远程作业服务75?any private dial out service预留给个人拨出服务76deos Distributed External Object Store 分布式外部对象存储77?any private RJE service预留给个人远程作业输入服务78vettcp vettcp修正TCP?79finger Finger查询远程主机在线用户等信息---finger 80http World Wide Web HTTP全球信息网超文本传输协议81hosts2-ns HOSTS2 Name Server HOST2名称服务82xfer XFER Utility传输实用程序83mit-ml-dev MIT ML Device模块化智能终端ML设备84ctf Common Trace Facility公用追踪设备85mit-ml-dev MIT ML Device模块化智能终端ML设备86mfcobol Micro Focus Cobol Micro Focus Cobol编程语言87?any private terminal link预留给个人终端连接88kerberos Kerberos Kerberros安全认证系统89su-mit-tg SU/MIT Telnet Gateway SU/MIT终端仿真网关90dnsix DNSIX Securit Attribute Token Map DNSIX 安全属性标记图91mit-dov MIT Dover Spooler MIT Dover假脱机92npp Network Printing Protocol网络打印协议93dcp Device Control Protocol设备控制协议94objcall Tivoli Object Dispatcher Tivoli对象调度95supdup SUPDUP96dixie DIXIE Protocol Specification DIXIE协议规范97ft-rvfft Remote Virtural File Protocol）快速远程虚拟文件协议98tacnews TAC News TAC新闻协议99metagram Metagram Relay100newacct[unauthorized use]101/tcp hostname NIC Host Name Server102/tcp iso-tsap ISO-TSAP Class 0103/tcp gppitnp Genesis Point-to-Point Trans Net104/tcp acr-nema ACR-NEMA Digital Imag. & Comm. 300105/tcp cso CCSO name server protocol105/tcp csnet-ns Mailbox Name Nameserver106/tcp 3com-tsmux 3COM-TSMUX107/tcp rtelnet Remote Telnet Service108/tcp snagas SNA Gateway Access Server109/tcp pop2 Post Office Protocol - Version 2110 pop3 默认端口111 端口：111 端口是SUN 公司的RPC（Remote Procedure Call，远程过程调用）服务所开放的端口，主要用于分布式系统中不同计算机的内部进程通信，RPC 在多种网络服务中都是很重要的组件112/tcp mcidas McIDAS Data Transmission Protocol113 端口：113 端口主要用于Windows 的“Authentication Service”（验证服务）114/tcp audionews Audio News Multicast115/tcp sftp Simple File Transfer Protocol116/tcp ansanotify ANSA REX Notify117/tcp uucp-path UUCP Path Service118/tcp sqlserv SQL Services119 端口：119 端口是为“Network News Transfer Protocol”（网络新闻组传输协议，简称NNTP）开放的120/tcp cfdptkt CFDPTKT121/tcp erpc Encore Expedited Remote Pro.Call122/tcp smakynet SMAKYNET123/tcp ntp Network Time Protocol124/tcp ansatrader ANSA REX Trader125/tcp locus-map Locus PC-Interface Net Map Ser126/tcp unitary Unisys Unitary Login127/tcp locus-con Locus PC-Interface Conn Server128/tcp gss-xlicen GSS X License Verification129/tcp pwdgen Password Generator Protocol130/tcp cisco-fna cisco FNATIVE131/tcp cisco-tna cisco TNATIVE132/tcp cisco-sys cisco SYSMAINT133/tcp statsrv Statistics Service134/tcp ingres-net INGRES-NET Service135 端口：135 端口主要用于使用RPC（Remote Procedure Call，远程过程调用）协议并提供DCOM （分布式组件对象模型）服务136/tcp profile PROFILE Naming System137 端口：137 端口主要用于“NetBIOS Name Service”（NetBIOS名称服务）138/tcp netbios-dgm NETBIOS Datagram Service139 端口：139 端口是为“NetBIOS Session Service”提供的，主要用于提供Windows 文件和打印机共享以及Unix 中的Samba 服务140/tcp emfis-data EMFIS Data Service141/tcp emfis-cntl EMFIS Control Service142/tcp bl-idm Britton-Lee IDM143 端口：143 端口主要是用于“Internet Message Access Protocol”v2（Internet 消息访问协议，简称IMAP）144/tcp uma Universal Management Architecture145/tcp uaac UAAC Protocol146/tcp iso-tp0 ISO-IP0161 端口：161 端口是用于“Simple Network Management Protocol”（简单网络管理协议，简称SNMP）443 端口：43 端口即网页浏览端口，主要是用于HTTPS 服务，是提供加密和通过安全端口传输的另一种HTTP554 端口：554 端口默认情况下用于“Real Time Streaming Protocol”（实时流协议，简称RTSP）1024 端口：1024 端口一般不固定分配给某个服务，在英文中的解释是“Reserved”（保留）1080 端口：1080 端口是Socks 代理服务使用的端口，大家平时上网使用的WWW 服务使用的是HTTP 协议的代理服务1433 端口：MS SQL*SERVER数据库server，默认的端口号为1433/tcp 1433/udp1434 端口：MS SQL*SERVER数据库monitor，默认的端口号为1434/tcp 1434/udp1755 端口：1755 端口默认情况下用于“Microsoft Media Server”（微软媒体服务器，简称MMS）3306 端口：mysql 的默认端口3389 端口：WIN2003远程登陆，默认的端口号为33894000 端口：4000 端口是用于大家经常使用的QQ 聊天工具的，再细说就是为QQ 客户端开放的端口，QQ 服务端使用的端口是8000。
dfsclient 临时端口范围
dfsclient 临时端口范围
DFSClient在Hadoop中是用于与NameNode和DataNode之间进行通信的客户端程序。
它使用RPC（Remote Procedure Call）协议与这些服务进行通信，并且可以在运行时通过设置参数来配置临时端口范围。
DFSClient使用两个主要的临时端口范围：1. NameNode端口范围：DFSClient用于与NameNode进行通信的RPC端口的范围。
可以通过设置hadoop.rpc.protection属性来更改默认端口范围。
这个属性有三个可选值：“authentication”（默认）、“integrity”和“privacy”。
每一种安全性级别都有不同的端口要求。
2. DataNode端口范围：DFSClient用于与DataNode进行通信的RPC端口的范围。
可以通过设置dfs.datanode.address属性来更改默认端口范围。
这个属性的默认值是
0.0.0.0:50010，其中50010是DataNode用于通信的默认端口。
这些临时端口范围的配置可以在Hadoop的配置文件中进行设置，例如hdfs-site.xml文件。
每个节点上的DFSClient都会使用这些配置来确定可用的端口范围。
软件水平考试中级网络工程师下午应用技术试题-试卷30_真题(含答案与解析)-交互
软件水平考试（中级）网络工程师下午（应用技术）试题-试卷30(总分48, 做题时间90分钟)1. 试题一试题一（）某公司设置VPN服务器允许外地的公司员工通过Internet连接到公司内部网络。
SSS_TEXT_QUSTI1.VPN使用的隧道协议可以有哪几类，分别有哪些协议?分值: 2答案:正确答案：分三层和二层隧道协议。
三层有IPsec协议，二层有L2TP和PPTP协议。
SSS_TEXT_QUSTI2.若采用L2TP协议，则该协议除IP外还支持哪几种协议?分值: 2答案:正确答案：IPX、NetBEUI。
SSS_TEXT_QUSTI3.VPN路由器配置如下，请解释画线部分含义； Vpdn-group 1 第(1)处 Accept-dialin protocol l2tp virtual-template 1 terminate-from hostname a801 第(2)处 Local name keith Lcp renegotiation always 第(3)处 No 12tp tunnel authentication分值: 2答案:正确答案：(1)创建VPDN组1。
(2)接受L2TP通道连接请求，并根据虚接口模板1创建虚拟访问，接收远程主机为a801的连接。
(3)LCP再次协商。
2. 试题二试题二（）阅读以下说明，回答问题1、问题2、问题3。
随着网络应用的日益广泛，接入网络和边缘网络的需求也更加复杂多样，企业为了开展电子商务，必须实现与Internet的互联，路由器是实现这一互联网的关键设备，路由器可以位企业提供越来越多的智能化服务，包括安全性、可用性和服务质量(QoS)等。
下面是CiscoVLSM子网设计与路由器的路由选择协议(其中路由器的路由选择协议未列出)。
下面以某公司，VLSM(Variable Length Subnet Mask，变长子网掩网)子网的方法。
假设该公司被分配了一个C类地址，该公司的网络拓扑结构如图1所示。
RFC2889——拥塞控制测试
·端口2 100%拥塞
选择测试参数
时间
·开始发送流量之前等待2秒
·停止发送流量之后等待10秒
结果保存路径
·默认路径
·可以自己指定
时延
·本项测试不关注
启用学习
·二层学习
·频率可自定义
配置拥塞控制参数
测试时长
·默认1次
·默认60秒
负载
·100%速率测试
·使用最大速率
帧长度
·默认取7个特殊字节来测试
·太过详细
·可以选择汇总模板
·只保存汇总信息
测试报告内容
打开测试报告
·查看列头拥塞(Head of Line Blocking)
·查看拥塞控制(Backpressure列)
·配置信息:包含当前的测试配置信息
错误结果1
错误结果2
·无列头阻塞:拥塞端口对非拥塞端口无影响,非拥塞端口不丢包
拥塞控制测试流程
添加机框→预约端口→选择向导→选择拥塞控制→配置接口→配置流量→配置测试参数→配置拥塞控制参数→运行测试→查看结果→导出报告
准备工作:添加机框
准备工作:预约端口
启用Flow Control
·选择所有端口
·右键,选择”配置端口”
·广播帧转发和时延（Broadcast Frame Forwarding and Latency）。
接下来将为您演示使用BigTao-V网络测试仪进行拥塞控制测试。
二、拥塞控制概述
1.拥塞控制
拥塞控制测试项包含两个测试内容
·拥塞控制:一个DUT是否执行拥塞控制(背压/反压)
·列头拥塞:一个拥塞的端口是否会影响到另一个没有拥塞的端口
·当DUT处理完报文以后,可以发送Pause帧,让测试仪恢复发送
简述is-is报文类型及其作用。
简述is-is报文类型及其作用。
IS-IS（Intermediate System to Intermediate System）是一种用于路由选择的协议，它使用IS-IS报文来交换路由信息。
IS-IS报文类型包括以下几种：1. Hello报文：用于建立和维护邻居关系，包括邻居的IP地址、路由器ID等信息。
2. Link State Request（LSR）报文：用于请求邻居发送某个LSA（Link State Advertisement）。
3. Link State Update（LSU）报文：用于发送LSA。
4. Link State Acknowledgment （LSAck）报文：用于确认收到LSU报文。
IS-IS报文的作用是在网络中传递路由信息，以便路由器可以选择最佳路径来转发数据包。
IS-IS协议使用链路状态路由算法（Link State Routing Algorithm），它将网络拓扑信息分发到所有路由器中，每个路由器都可以计算出到达目的地的最佳路径。
IS-IS报文的交换使得路由器可以动态地适应网络拓扑的变化，从而提高网络的可靠性和性能。
Aolynk-S1508LV100R004版本说明书
Aolynk S1508LV100R004版本说明书杭州华三通信技术有限公司Aolynk S1508LV100R004版本说明书关键词：Logo切换摘要：此版本系Logo切换版本缩略语：缩略语英文全名中文解释VLAN Virtual Local Area Network 虚拟局域网ServiceofQoS Quality服务质量目录1 版本信息 (4)1.1 版本号 (4)1.2 历史版本信息 (4)1.3 版本配套表 (4)2 版本使用限制及注意事项 (4)3 版本特性说明 (5)3.1 版本硬件特性 (5)3.2 版本软件特性 (5)4 版本变更说明 (5)4.1 特性变更说明 (5)4.2 命令行变更说明 (5)4.3 MIB变更说明 (5)4.4 操作方式变更说明 (5)5 存在问题与规避措施 (6)6 解决问题列表 (6)7 配套资料 (6)7.1 配套资料清单 (6)7.2 配套产品资料的获取方法 (6)8 版本升级操作指导 (6)表目录表1 历史版本信息表 (4)表2 版本配套表 (4)表3 特性变更说明 (5)表4 配套手册清单 (6)表5 从网站查询和下载资料的说明 (6)1 版本信息1.1 版本号版本号：S1508LV100R0041.2 历史版本信息表1历史版本信息表版本号基础版本号发布日期备注S1508LV100R004S1508LV100R0032007-05-16无S1508LV100R003S1508LV100R0012006-09-30无S1508LV100R001首次发布2006-04-29无1.3 版本配套表表2版本配套表系列以太网交换机产品系列 AolynkS1500型号S1508L内存需求无FLASH需求无BOOTROM版本号无目标文件名称S1508LV100R004.exeQUIDVIEW版本号无CAMS版本号无WEB版本号无备注无2 版本使用限制及注意事项无3 版本特性说明3.1 版本硬件特性无3.2 版本软件特性无4 版本变更说明4.1 特性变更说明表3特性变更说明版本号项目描述硬件特性更新无S1508LV新增特性：100R004软件特性更新显示配置：增加显示当前配置按钮。
SmartClass Ethernet测试仪 用户手册
第1章
开始..................................................................................................... 1
装箱清单.............................................................. 2
底部面板介绍.......................................................... 7
启动设备.............................................................. 7
关闭设备.............................................................. 7
不能将此产品作为市政污染废料进行处理，并且根据当地国家相关规则单独收集 处理。在欧盟地区，所有从 JDSU 公司 2005.8.13 日之后购买的设备可以在设 备使用寿命完毕时返回处理。JDSU 公司确保所有返回的废弃设备能够以环境友 好型方式进行重新使用、回收或处理，这些操作都要符合所有国家和国际废料处 理标准。
SmartClass Ethernet 测试仪用户手册
v
目录
第2章 第3章
vi
数据输入屏 ....................................................................................................10 结果屏............................................................................................................10 使用键盘 ............................................................ 11 选择菜单选项或配置设置............................................................................... 11 返回到上一级菜单.......................................................................................... 11 输入数字值 ....................................................................................................11 输入文本 ........................................................................................................11
rfc5881.Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)
Internet Engineering Task Force (IETF) D. Katz Request for Comments: 5881 D. Ward Category: Standards Track Juniper Networks ISSN: 2070-1721 June 2010 Bidirectional Forwarding Detection (BFD)for IPv4 and IPv6 (Single Hop)AbstractThis document describes the use of the Bidirectional ForwardingDetection (BFD) protocol over IPv4 and IPv6 for single IP hops.Status of This MemoThis is an Internet Standards Track document.This document is a product of the Internet Engineering Task Force(IETF). It represents the consensus of the IETF community. It hasreceived public review and has been approved for publication by theInternet Engineering Steering Group (IESG). Further information onInternet Standards is available in Section 2 of RFC 5741.Information about the current status of this document, any errata,and how to provide feedback on it may be obtained at/info/rfc5881.Copyright NoticeCopyright (c) 2010 IETF Trust and the persons identified as thedocument authors. All rights reserved.This document is subject to BCP 78 and the IETF Trust’s LegalProvisions Relating to IETF Documents(/license-info) in effect on the date ofpublication of this document. Please review these documentscarefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e ofthe Trust Legal Provisions and are provided without warranty asdescribed in the Simplified BSD License.Katz & Ward Standards Track [Page 1]1. IntroductionOne very desirable application for Bidirectional Forwarding Detection (BFD) [BFD] is to track IPv4 and IPv6 connectivity between directlyconnected systems. This could be used to supplement the detectionmechanisms in routing protocols or to monitor router-hostconnectivity, among other applications.This document describes the particulars necessary to use BFD in this environment. Interactions between BFD and other protocols and system functions are described in the BFD Generic Applications document[BFD-GENERIC].1.1. Conventions Used in This DocumentThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [KEYWORDS]. 2. Applications and LimitationsThis application of BFD can be used by any pair of systemscommunicating via IPv4 and/or IPv6 across a single IP hop that isassociated with an incoming interface. This includes, but is notlimited to, physical media, virtual circuits, and tunnels.Each BFD session between a pair of systems MUST traverse a separatenetwork-layer path in both directions. This is necessary fordemultiplexing to work properly, and also because (by definition)multiple sessions would otherwise be protecting the same path.If BFD is to be used in conjunction with both IPv4 and IPv6 on aparticular path, a separate BFD session MUST be established for each protocol (and thus encapsulated by that protocol) over that link.If the BFD Echo function is used, transmitted packets are immediately routed back towards the sender on the interface over which they were sent. This may interact with other mechanisms that are used on thetwo systems that employ BFD. In particular, ingress filtering[BCP38] is incompatible with the way Echo packets need to be sent.Implementations that support the Echo function MUST ensure thatingress filtering is not used on an interface that employs the Echofunction or make an exception for ingress filtering Echo packets.An implementation of the Echo function also requires ApplicationProgramming Interfaces (APIs) that may not exist on all systems. Asystem implementing the Echo function MUST be capable of sendingKatz & Ward Standards Track [Page 2]packets to its own address, which will typically require bypassingthe normal forwarding lookup. This typically requires access to APIs that bypass IP-layer functionality.Please note that BFD is intended as an Operations, Administration,and Maintenance (OAM) mechanism for connectivity check and connection verification. It is applicable for network-based services (e.g.router-to-router, subscriber-to-gateway, LSP/circuit endpoints, andservice appliance failure detection). In these scenarios it isrequired that the operator correctly provision the rates at which BFD is transmitted to avoid congestion (e.g link, I/O, CPU) and falsefailure detection. It is not applicable for application-to-application failure detection across the Internet because it does not have sufficient capability to do necessary congestion detection andavoidance and therefore cannot prevent congestion collapse. Host-to- host or application-to-application deployment across the Internetwill require the encapsulation of BFD within a transport thatprovides "TCP-friendly" [TFRC] behavior.3. Initialization and DemultiplexingIn this application, there will be only a single BFD session between two systems over a given interface (logical or physical) for aparticular protocol. The BFD session must be bound to thisinterface. As such, both sides of a session MUST take the "Active"role (sending initial BFD Control packets with a zero value of YourDiscriminator), and any BFD packet from the remote machine with azero value of Your Discriminator MUST be associated with the session bound to the remote system, interface, and protocol.4. EncapsulationBFD Control packets MUST be transmitted in UDP packets withdestination port 3784, within an IPv4 or IPv6 packet. The sourceport MUST be in the range 49152 through 65535. The same UDP sourceport number MUST be used for all BFD Control packets associated with a particular session. The source port number SHOULD be unique among all BFD sessions on the system. If more than 16384 BFD sessions are simultaneously active, UDP source port numbers MAY be reused onmultiple sessions, but the number of distinct uses of the same UDPsource port number SHOULD be minimized. An implementation MAY usethe UDP port source number to aid in demultiplexing incoming BFDControl packets, but ultimately the mechanisms in [BFD] MUST be used to demultiplex incoming packets to the proper session.BFD Echo packets MUST be transmitted in UDP packets with destination UDP port 3785 in an IPv4 or IPv6 packet. The setting of the UDPsource port is outside the scope of this specification. TheKatz & Ward Standards Track [Page 3]destination address MUST be chosen in such a way as to cause theremote system to forward the packet back to the local system. Thesource address MUST be chosen in such a way as to preclude the remote system from generating ICMP or Neighbor Discovery Redirect messages. In particular, the source address SHOULD NOT be part of the subnetbound to the interface over which the BFD Echo packet is beingtransmitted, and it SHOULD NOT be an IPv6 link-local address, unless it is known by other means that the remote system will not sendRedirects.BFD Echo packets MUST be transmitted in such a way as to ensure that they are received by the remote system. On multiaccess media, forexample, this requires that the destination datalink addresscorresponds to the remote system.The above requirements may require the bypassing of some common IPlayer functionality, particularly in host implementations.5. TTL/Hop Limit IssuesIf BFD authentication is not in use on a session, all BFD Controlpackets for the session MUST be sent with a Time to Live (TTL) or Hop Limit value of 255. All received BFD Control packets that aredemultiplexed to the session MUST be discarded if the received TTL or Hop Limit is not equal to 255. A discussion of this mechanism can be found in [GTSM].If BFD authentication is in use on a session, all BFD Control packets MUST be sent with a TTL or Hop Limit value of 255. All received BFD Control packets that are demultiplexed to the session MAY bediscarded if the received TTL or Hop Limit is not equal to 255. Ifthe TTL/Hop Limit check is made, it MAY be done before anycryptographic authentication takes place if this will avoidunnecessary calculation that would be detrimental to the receivingsystem.In the context of this section, "authentication in use" means thatthe system is sending BFD Control packets with the Authentication bit set and with the Authentication Section included and that allunauthenticated packets demultiplexed to the session are discarded,per the BFD base specification.Katz & Ward Standards Track [Page 4]6. Addressing IssuesImplementations MUST ensure that all BFD Control packets aretransmitted over the one-hop path being protected by BFD.On a multiaccess network, BFD Control packets MUST be transmittedwith source and destination addresses that are part of the subnet(addressed from and to interfaces on the subnet).On a point-to-point link, the source address of a BFD Control packet MUST NOT be used to identify the session. This means that theinitial BFD packet MUST be accepted with any source address, and that subsequent BFD packets MUST be demultiplexed solely by the YourDiscriminator field (as is always the case). This allows the source address to change if necessary. If the received source addresschanges, the local system MUST NOT use that address as thedestination in outgoing BFD Control packets; rather, it MUST continue to use the address configured at session creation. An implementation MAY notify the application that the neighbor’s source address haschanged, so that the application might choose to change thedestination address or take some other action. Note that the TTL/Hop Limit check described in section 5 (or the use of authentication)precludes the BFD packets from having come from any source other than the immediate neighbor.7. BFD for Use with TunnelsA number of mechanisms are available to tunnel IPv4 and IPv6 overarbitrary topologies. If the tunnel mechanism does not decrement the TTL or Hop Limit of the network protocol carried within, themechanism described in this document may be used to provide liveness detection for the tunnel. The BFD authentication mechanism SHOULD be used and is strongly encouraged.8. IANA ConsiderationsPorts 3784 and 3875 were assigned by IANA for use with the BFDControl and BFD Echo protocols, respectively.9. Security ConsiderationsIn this application, the use of TTL=255 on transmit and receive,coupled with an association to an incoming interface, is viewed assupplying equivalent security characteristics to other protocols used in the infrastructure, as it is not trivially spoofable. Thesecurity implications of this mechanism are further discussed in[GTSM].Katz & Ward Standards Track [Page 5]The security implications of the use of BFD authentication arediscussed in [BFD].The use of the TTL=255 check simultaneously with BFD authenticationprovides a low overhead mechanism for discarding a class ofunauthorized packets and may be useful in implementations in whichcryptographic checksum use is susceptible to denial-of-serviceattacks. The use or non-use of this mechanism does not impactinteroperability.10. References10.1. Normative References[BFD] Katz, D. and D. Ward, "Bidirectional ForwardingDetection", RFC 5880, June 2010.[BFD-GENERIC] Katz, D. and D. Ward, "Generic Application ofBidirectional Forwarding Detection (BFD)", RFC 5882,June 2010.[GTSM] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. Pignataro, "The Generalized TTL Security Mechanism(GTSM)", RFC 5082, October 2007.[KEYWORDS] Bradner, S., "Key words for use in RFCs to IndicateRequirement Levels", BCP 14, RFC 2119, March 1997.10.2. Informative References[BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IPSource Address Spoofing", BCP 38, RFC 2827, May 2000.[TFRC] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 5348, September 2008.Katz & Ward Standards Track [Page 6]Authors’ AddressesDave KatzJuniper Networks1194 N. Mathilda Ave.Sunnyvale, CA 94089-1206USAPhone: +1-408-745-2000EMail: dkatz@Dave WardJuniper Networks1194 N. Mathilda Ave.Sunnyvale, CA 94089-1206USAPhone: +1-408-745-2000EMail: dward@Katz & Ward Standards Track [Page 7]。
5G承载网专业试题-160题
判断 判断 判断 判断 判断 判断 判断 判断 判断 判断 判断 判断 判断 判断 单选
[5G承载网操作维护与故障处理]5G承载网面临的关键需求，不包括
单选
[5G承载网操作维护与故障处理]为了满足5G业务灵活调度要求，承载网需要实 现 [5G承载网操作维护与故障处理]5G承载网中采用了一些保护技术，目的是当网 络发生故障时，保护用户业务尽量不中断，以下技术不属于保护技术的是 [5G承载网操作维护与故障处理]5G承载网中，降低时延的方法不包括
单选 单选 单选 单选 单选 单选 单选 单选 单选 单选 单选 单选 单选 单选 单选 单选 单选 单选 单选 单选 单选 单选 单选 单选 单选 单选 单选 单选 多选 多选 多选 多选 多选 多选 多选
[5G承载网操作维护与故障处理]提升承载网同步精度的措施，包括下列哪些措 施 [5G承载网操作维护与故障处理]以下选项属于5G前传主流方案的是 [5G承载网操作维护与故障处理]5G承载网部署方案中，推荐使用的PTN设备是 以下哪些 [5G承载网操作维护与故障处理]5G应用场景中，uRLLC类业务的特点包括以下 哪些特点 [5G承载网操作维护与故障处理]以下哪些属于端到端FlexE硬管道应用的优势 [5G承载网操作维护与故障处理]同一张城域网，多种业务形态共承载，主要依 靠以下哪些标记区分 [5G承载网操作维护与故障处理]以下哪些功能单元属于5G核心网
[5G承载网操作维护与故障处理]ISIS的骨干区域可以由哪些角色路由器组成 [5G承载网操作维护与故障处理]根据ITU-T的建议，5G应用会朝三大场景发 展，主要包括哪几大场景 [5G承载网操作维护与故障处理]HVPN方案中，那些设备存在有黑洞路由 [5G承载网操作维护与故障处理]由于无线设备的拆分和拉远，5G承载网被分为 了哪几段
IPv6基本技术介绍
N
Cisco 3750 Cisco 3750
双栈 三层交换机
负载均衡器 (Alteon AD3) Cisco 2950 交换机
CDN (双栈业务平台)
…
门户 认证 接口 应用 湖南 江苏 门户 认证 接口 应用
…
VOD
…
VOD
业务实现：新建/升级VNET承载网络支持双栈。初期门户服务器双栈，其他服务器IPv4 单栈，VNET基本平台识别和处理双栈用户及ICP 属性，实现双栈接入流程。后期随着 业务发展逐步升级各类应用服务器。无锡升级 CDN业务平台支持双栈访问。 网络改造：长沙由于VNET承载网络不支持双栈升级，新增双栈汇聚交换机和接入交换 机。无锡升级汇聚交换机和负载均衡器支持双栈；CDN服务器群支持双栈，通过新增汇 22 聚交换机接入IPv4和IPv6网络。 xcf
IP地址：IPv6地址无格式限制
BR
2001:0:1:1::1
IPv4服务器 骨干网 (IPv4) 城域网 (双栈) BR
BRAS/SR
NAT64-GW
纯IPv6 接入
IPv6 /Port IPv6 流量 2001:0:0:1::1 /TCP 10000 IPv4 流量
DNS-ALG
IPv4/Port
IPV6地址架构标准（RFC1884，RFC2373，RFC3513，RFC4212） 协议转换标准（RFC1933，RFC2893，RFC4212）
3
xcf
核心技术
4
xcf
核心技术-技术特征
5
xcf
核心技术-地址格式
6
xcf
核心技术-地址格式
7
xcf
核心技术-地址格式
RFC2889MAC地址学习速率案例
RFC2889MAC地址学习速率案例一、RFC2889MAC地址学习速率解析1.1协议原理RFC2889为LAN交换设备的基准测试提供了方法学，它将RFC2544中为网络互联设备基准测试所定义的方法学扩展到了交换设备，提供了交换机转发性能（Forwarding Performance）、拥塞控制（Congestion Control）、延迟（Latency）、地址处理（Address Handling）和错误过滤（Error Filtering）等基准测试的方法说明。
1.2工作原理确定局域网交换设备的地址缓存容量。
以指定速率从客户端网口向DUT网口，发送源MAC地址不同而目的MAC地址相同的帧，然后测试帧被DU转发至服务端网口，监听端口监听泛洪帧或者转发错误帧，通过二分法的应可确定DUT在无泛洪和无错误转发情况下，正确学习并转发的最大地址数。
1.3协议用途MAC地址学习是针对交换机来说的，交换机在收到一个报文时，会将报文的源mac地址记录在mac地址表选项中。
二、RFC2889MAC地址学习速率测试仪中可应用的场景2.1直连模式测试仪同时模拟客户端和服务器，测试流量穿过获取局域网交换设备的MAC 地址学习最快速率三、RFC2889MAC地址学习速率用例功能介绍3.1.分配cpu核用例的运行需要分配cpu核数，RFC2889MAC地址学习速率的最高性能需要分配一定的核数。
3.2抓包设置可以设置需要抓的协议类型，指定IP地址、端口、文件大小或者包数。
可在运行前或运行中设置抓包。
四、RFC2889MAC地址学习速率测试案例4.1RFC2889MAC地址学习速率用例拓扑图说明：测试仪使用“直连模式”模拟RFC2889MAC地址学习速率的客户端和服务端，过一台交换机（直连模式），测试交换机性能。
4.2RFC2889MAC地址学习速率用例目的本次案例测试华为交换机的MAC地址学习速率的性能，测试仪模拟10000条MAC地址，在交换机上查看MAC地址条数。
rfc5288.AES Galois Counter Mode (GCM) Cipher Suites for TLS
Network Working Group J. Salowey Request for Comments: 5288 A. Choudhury Category: Standards Track D. McGrew Cisco Systems, Inc. August 2008 AES Galois Counter Mode (GCM) Cipher Suites for TLSStatus of This MemoThis document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions forimprovements. Please refer to the current edition of the "InternetOfficial Protocol Standards" (STD 1) for the standardization stateand status of this protocol. Distribution of this memo is unlimited.AbstractThis memo describes the use of the Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) as a Transport Layer Security (TLS)authenticated encryption operation. GCM provides bothconfidentiality and data origin authentication, can be efficientlyimplemented in hardware for speeds of 10 gigabits per second andabove, and is also well-suited to software implementations. Thismemo defines TLS cipher suites that use AES-GCM with RSA, DSA, andDiffie-Hellman-based key exchange mechanisms.Table of Contents1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 22. Conventions Used in This Document . . . . . . . . . . . . . . . 23. AES-GCM Cipher Suites . . . . . . . . . . . . . . . . . . . . . 24. TLS Versions . . . . . . . . . . . . . . . . . . . . . . . . . 35. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 46. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 6.1. Counter Reuse . . . . . . . . . . . . . . . . . . . . . . . 46.2. Recommendations for Multiple Encryption Processors . . . . 47. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 58. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 Salowey, et al. Standards Track [Page 1]1. IntroductionThis document describes the use of AES [AES] in Galois Counter Mode(GCM) [GCM] (AES-GCM) with various key exchange mechanisms as acipher suite for TLS. AES-GCM is an authenticated encryption withassociated data (AEAD) cipher (as defined in TLS 1.2 [RFC5246])providing both confidentiality and data origin authentication. Thefollowing sections define cipher suites based on RSA, DSA, andDiffie-Hellman key exchanges; ECC-based (Elliptic Curve Cryptography) cipher suites are defined in a separate document [RFC5289].AES-GCM is not only efficient and secure, but hardwareimplementations can achieve high speeds with low cost and lowlatency, because the mode can be pipelined. Applications thatrequire high data throughput can benefit from these high-speedimplementations. AES-GCM has been specified as a mode that can beused with IPsec ESP [RFC4106] and 802.1AE Media Access Control (MAC) Security [IEEE8021AE].2. Conventions Used in This DocumentThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].3. AES-GCM Cipher SuitesThe following cipher suites use the new authenticated encryptionmodes defined in TLS 1.2 with AES in Galois Counter Mode (GCM) [GCM]: CipherSuite TLS_RSA_WITH_AES_128_GCM_SHA256 = {0x00,0x9C}CipherSuite TLS_RSA_WITH_AES_256_GCM_SHA384 = {0x00,0x9D}CipherSuite TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 = {0x00,0x9E}CipherSuite TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 = {0x00,0x9F}CipherSuite TLS_DH_RSA_WITH_AES_128_GCM_SHA256 = {0x00,0xA0}CipherSuite TLS_DH_RSA_WITH_AES_256_GCM_SHA384 = {0x00,0xA1}CipherSuite TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 = {0x00,0xA2}CipherSuite TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 = {0x00,0xA3}CipherSuite TLS_DH_DSS_WITH_AES_128_GCM_SHA256 = {0x00,0xA4}CipherSuite TLS_DH_DSS_WITH_AES_256_GCM_SHA384 = {0x00,0xA5}CipherSuite TLS_DH_anon_WITH_AES_128_GCM_SHA256 = {0x00,0xA6}CipherSuite TLS_DH_anon_WITH_AES_256_GCM_SHA384 = {0x00,0xA7}These cipher suites use the AES-GCM authenticated encryption withassociated data (AEAD) algorithms AEAD_AES_128_GCM andAEAD_AES_256_GCM described in [RFC5116]. Note that each of theseAEAD algorithms uses a 128-bit authentication tag with GCM (inparticular, as described in Section 3.5 of [RFC4366], theSalowey, et al. Standards Track [Page 2]"truncated_hmac" extension does not have an effect on cipher suitesthat do not use HMAC). The "nonce" SHALL be 12 bytes long consisting of two parts as follows: (this is an example of a "partiallyexplicit" nonce; see Section 3.2.1 in [RFC5116]).struct {opaque salt[4];opaque nonce_explicit[8];} GCMNonce;The salt is the "implicit" part of the nonce and is not sent in thepacket. Instead, the salt is generated as part of the handshakeprocess: it is either the client_write_IV (when the client issending) or the server_write_IV (when the server is sending). Thesalt length (SecurityParameters.fixed_iv_length) is 4 octets.The nonce_explicit is the "explicit" part of the nonce. It is chosen by the sender and is carried in each TLS record in theGenericAEADCipher.nonce_explicit field. The nonce_explicit length(SecurityParameters.record_iv_length) is 8 octets.Each value of the nonce_explicit MUST be distinct for each distinctinvocation of the GCM encrypt function for any fixed key. Failure to meet this uniqueness requirement can significantly degrade security. The nonce_explicit MAY be the 64-bit sequence number.The RSA, DHE_RSA, DH_RSA, DHE_DSS, DH_DSS, and DH_anon key exchanges are performed as defined in [RFC5246].The Pseudo Random Function (PRF) algorithms SHALL be as follows:For cipher suites ending with _SHA256, the PRF is the TLS PRF[RFC5246] with SHA-256 as the hash function.For cipher suites ending with _SHA384, the PRF is the TLS PRF[RFC5246] with SHA-384 as the hash function.Implementations MUST send TLS Alert bad_record_mac for all types offailures encountered in processing the AES-GCM algorithm.4. TLS VersionsThese cipher suites make use of the authenticated encryption withadditional data defined in TLS 1.2 [RFC5246]. They MUST NOT benegotiated in older versions of TLS. Clients MUST NOT offer thesecipher suites if they do not offer TLS 1.2 or later. Servers thatselect an earlier version of TLS MUST NOT select one of these cipher suites. Because TLS has no way for the client to indicate that it Salowey, et al. Standards Track [Page 3]supports TLS 1.2 but not earlier, a non-compliant server mightpotentially negotiate TLS 1.1 or earlier and select one of the cipher suites in this document. Clients MUST check the TLS version andgenerate a fatal "illegal_parameter" alert if they detect anincorrect version.5. IANA ConsiderationsIANA has assigned the following values for the cipher suites defined in this document:CipherSuite TLS_RSA_WITH_AES_128_GCM_SHA256 = {0x00,0x9C}CipherSuite TLS_RSA_WITH_AES_256_GCM_SHA384 = {0x00,0x9D}CipherSuite TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 = {0x00,0x9E}CipherSuite TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 = {0x00,0x9F}CipherSuite TLS_DH_RSA_WITH_AES_128_GCM_SHA256 = {0x00,0xA0}CipherSuite TLS_DH_RSA_WITH_AES_256_GCM_SHA384 = {0x00,0xA1}CipherSuite TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 = {0x00,0xA2}CipherSuite TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 = {0x00,0xA3}CipherSuite TLS_DH_DSS_WITH_AES_128_GCM_SHA256 = {0x00,0xA4}CipherSuite TLS_DH_DSS_WITH_AES_256_GCM_SHA384 = {0x00,0xA5}CipherSuite TLS_DH_anon_WITH_AES_128_GCM_SHA256 = {0x00,0xA6}CipherSuite TLS_DH_anon_WITH_AES_256_GCM_SHA384 = {0x00,0xA7}6. Security ConsiderationsThe security considerations in [RFC5246] apply to this document aswell. The remainder of this section describes securityconsiderations specific to the cipher suites described in thisdocument.6.1. Counter ReuseAES-GCM security requires that the counter is never reused. The IVconstruction in Section 3 is designed to prevent counter reuse.Implementers should also understand the practical considerations ofIV handling outlined in Section 9 of [GCM].6.2. Recommendations for Multiple Encryption ProcessorsIf multiple cryptographic processors are in use by the sender, thenthe sender MUST ensure that, for a particular key, each value of the nonce_explicit used with that key is distinct. In this case, eachencryption processor SHOULD include, in the nonce_explicit, a fixedvalue that is distinct for each processor. The recommended format is nonce_explicit = FixedDistinct || VariableSalowey, et al. Standards Track [Page 4]where the FixedDistinct field is distinct for each encryptionprocessor, but is fixed for a given processor, and the Variable field is distinct for each distinct nonce used by a particular encryptionprocessor. When this method is used, the FixedDistinct fields usedby the different processors MUST have the same length.In the terms of Figure 2 in [RFC5116], the Salt is the Fixed-Commonpart of the nonce (it is fixed, and it is common across allencryption processors), the FixedDistinct field exactly correspondsto the Fixed-Distinct field, the Variable field corresponds to theCounter field, and the explicit part exactly corresponds to thenonce_explicit.For clarity, we provide an example for TLS in which there are twodistinct encryption processors, each of which uses a one-byteFixedDistinct field:Salt = eedc68dcFixedDistinct = 01 (for the first encryption processor) FixedDistinct = 02 (for the second encryption processor)The GCMnonces generated by the first encryption processor, and their corresponding nonce_explicit, are:GCMNonce nonce_explicit------------------------ ----------------------------eedc68dc0100000000000000 0100000000000000eedc68dc0100000000000001 0100000000000001eedc68dc0100000000000002 0100000000000002...The GCMnonces generated by the second encryption processor, and their corresponding nonce_explicit, areGCMNonce nonce_explicit------------------------ ----------------------------eedc68dc0200000000000000 0200000000000000eedc68dc0200000000000001 0200000000000001eedc68dc0200000000000002 0200000000000002...7. AcknowledgementsThis document borrows heavily from [RFC5289]. The authors would like to thank Alex Lam, Simon Josefsson, and Pasi Eronen for providinguseful comments during the review of this document.Salowey, et al. Standards Track [Page 5]8. References8.1. Normative References[AES] National Institute of Standards and Technology,"Advanced Encryption Standard (AES)", FIPS 197,November 2001.[GCM] Dworkin, M., "Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC",National Institute of Standards and Technology SP 800- 38D, November 2007.[RFC2119] Bradner, S., "Key words for use in RFCs to IndicateRequirement Levels", BCP 14, RFC 2119, March 1997.[RFC5116] McGrew, D., "An Interface and Algorithms forAuthenticated Encryption", RFC 5116, January 2008.[RFC5246] Dierks, T. and E. Rescorla, "The Transport LayerSecurity (TLS) Protocol Version 1.2", RFC 5246,August 2008.8.2. Informative References[IEEE8021AE] Institute of Electrical and Electronics Engineers,"Media Access Control Security", IEEE Standard 802.1AE, August 2006.[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/CounterMode (GCM) in IPsec Encapsulating Security Payload(ESP)", RFC 4106, June 2005.[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS)Extensions", RFC 4366, April 2006.[RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites withSHA-256/384 and AES Galois Counter Mode", RFC 5289,August 2008.Salowey, et al. Standards Track [Page 6]Authors’ AddressesJoseph SaloweyCisco Systems, Inc.2901 3rd. AveSeattle, WA 98121USAEMail: jsalowey@Abhijit ChoudhuryCisco Systems, Inc.3625 Cisco WaySan Jose, CA 95134USAEMail: abhijitc@David McGrewCisco Systems, Inc.170 W Tasman DriveSan Jose, CA 95134USAEMail: mcgrew@Salowey, et al. Standards Track [Page 7]Full Copyright StatementCopyright (C) The IETF Trust (2008).This document is subject to the rights, licenses and restrictionscontained in BCP 78, and except as set forth therein, the authorsretain all their rights.This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIEDWARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual PropertyThe IETF takes no position regarding the validity or scope of anyIntellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described inthis document or the extent to which any license under such rightsmight or might not be available; nor does it represent that it hasmade any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can befound in BCP 78 and BCP 79.Copies of IPR disclosures made to the IETF Secretariat and anyassurances of licenses to be made available, or the result of anattempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of thisspecification can be obtained from the IETF on-line IPR repository at /ipr.The IETF invites any interested party to bring to its attention anycopyrights, patents or patent applications, or other proprietaryrights that may cover technology that may be required to implementthis standard. Please address the information to the IETF atietf-ipr@.Salowey, et al. Standards Track [Page 8]。
中国移动IPv6终端技术要求V100--资料
中国移动I P v6终端技术要求V1.0.0目录1 范围 (1)2 规范性引用文件 (1)3 术语、定义和缩略语 (2)3.1 术语和定义 (2)3.1.1 接入点名称Access Point Name (2)3.1.2 网关GPRS支持节点Gateway GPRS Support Node (2)3.1.3 分组数据协议上下文Packet Data Protocol Context (2)3.1.4 双栈终端Dual stack terminal (2)3.1.5 终端形态 (2)3.2 缩略语 (3)4 总体技术要求 (4)5 终端技术要求 (4)5.1 协议栈 (4)5.1.1 概述 (4)5.1.2 RFC 2460 IPv6协议规范 (4)5.1.3 RFC 4291 IPv6地址结构 (5)5.2 DNS客户端 (5)5.3 DHCP客户端 (5)5.4 IPv4/IPv6协议翻译技术 (5)5.4.1 BIH (5)5.4.2 464XLAT (8)5.5 隧道过渡技术 (9)5.5.1 Teredo技术 (9)5.5.2 6rd (9)6 PDP/PDN连接激活及IPv6地址获取过程 (10)6.1 IPv6地址配置 (10)6.2 PDP/PDN连接的建立和IP地址的获取 (10)6.2.1 3GPP Release 8之前终端PDP上下文的激活和IPv6地址获取过程 (10)6.2.2 3GPP Release 8之后（含Release 8）终端PDP/PDN连接的建立和IPv6地址获取过程 (11)7 终端PDP/PDN连接激活策略 (12)7.1 概述 (12)7.2 双栈终端PDP/PDN连接激活策略一：同时获取IPv4和IPv6地址 (12)7.3 双栈终端PDP/PDN连接激活策略二：按需建立IPv4或IPv6连接 (14)7.4 两种PDP/PDN连接激活策略的选择和使用 (15)8 WLAN网络中的IPv6地址获得 (15)9 DNS解析 (15)9.1 概述 (15)9.2 终端DNS解析流程 (15)9.3 DNS服务器地址的获取 (15)9.4 DNS解析承载类型的选择 (15)9.5 DNS解析目的地址类型的选择 (15)10 终端应用软件系统 (16)11 IP头压缩技术要求 (16)12 安全 (16)13 APN设定 (17)14 不同终端类型要求 (17)14.1 手机/平板电脑类终端 (17)14.2 MiFi/移动CPE终端 (17)14.3 数据卡终端 (17)前言本文档是依据3GPP、IETF发布的IPv6相关标准制定，并结合现阶段IPv6升级改造及试点项目需求所定义的手机、平板电脑、MiFi、移动CPE、数据卡等移动终端IPv6部分技术要求。
RFC2889
口必须（MUST）怎样传送测试帧给测试中的其它所有端口。在这个例子中,有六个端口,每个
端口有一个地址:
源端口 目的端口 (按传输序)
端口#1 2 3 4 5 6 2...
“SHOULD”，“SHOULD NOT”，“RECOMMENDED”，“MAY”，及“OPTIONAL”的解释,和在RFC
2119文档中所描述的一样.
3. 测试设置
这个文档将RFC 2544[3]第6节所描述常规基准测试设置扩展到局域网交换设备的基准
测试中。 RFC 2544[3]主要描述了非网状通信（non-meshed traffic），其输入和输出接
August 2000
局域网（LAN）交换设备基准（测试）方法学
（RFC2889—Benchmarking Methodology for LAN Switching Devices）
帧间间隙（IFG）- 在突发帧群（burst）中两帧之间的帧间间隙必须（MUST）为被测试介质
标准中指定的最小值。( 10Mbps 以太网为9.6微秒，100Mbps 以太网为960 纳秒, 1Gbps以太网
为96纳秒 )
双工模式 – 半双工或者全双工。
计划负载（Iload）-每端口的计划负载以媒质的最大理论负载的百分比表示，不考虑通信方
5.3.5 报告格式 12
5.4 部分网状单向通信 12
5.4.1 目的 12
5.4.2 设置参数 12
5.4.3 过程 13
5.4.4 测量 13
5.4.4.1 吞吐量 14
OceanBase模拟题-单选
OceanBase模拟题-单选姓名：班级：________________________ ________________________1. OceanBase使用什么协议完成高可用和强一致性？（） [单选题]*A.多副本+Paxos协议(正确答案)B.单副本+高可用同步协议C.单副本+Paxos协议D.多副本+高可用同步协议2.以下哪个描述不是 OceanBase的架构特点：（） [单选题]*A.全对等节点B.多副本C.准内存数据库D.中心管控(正确答案)3.当集群发生故障时(服务器故障或者网络故障)，OceanBase故障切换的粒度是什么？（） [单选题]*A.集群B.表或者分区表的子分区(正确答案)C.数据库D.租户4. OceanBase是靠基那种础架构实现写入高性能的？（） [单选题]*A.LSM-TREE(正确答案)B.B TREEC.Key-ValueD.COLA5. OceanBase使用那种技术保证跨机事务的原子性？（） [单选题]*A.三阶段提交B.一阶段提交C.两阶段提交(正确答案)D.MVCC6. ConfigServer(config url)服务保存了集群的关键信息，是一个web api的服务，提供OB poxy访问，一般是由哪个组件提供的？（） [单选题]*A.OceanBase Migration Service(OMS)B.OceanBase Cloud Platform(OCP)(正确答案)C.OceanBase Develop Center(ODC)D.OceanBase Configure Manager(OCM)7. OceanBase集群可以同时支持MySQL和Oracle的租户，哪个黑屏工具可以连接到Oracle租户?（） [单选题]*A. OCP管理平台B. ODC开发者中心C. OceanBase客户端(正确答案)D.标准MySQL客户端8.通过配置Primay Zone，可以打破负载均衡，将主副本汇聚到一个Zone内。
华为HCNA-HNTD(H12-211)题库
1.参考以下DHCP流程图，以下说法正确的是（）。
（多选）A. 第一步发送的是组播报文B. 第二步发送的是单播报文C. 第三步发送的是广播报文D. 第四步发送的是单播报文E. 第四步发送的是广播报文答案: BCD2.在一台充当认证服务器上配置了两个认证域“Area1”和“Area2”，用户如果使用正确的用户名“huawei”和密码“hello”进行认证，则此用户会被分配到哪个认证域当中？A. 认证域“Area1”B. 认证域“Area2”C. 认证域“default domain”D. 认证域“default_admin domain”答案: C3.华为设备的RIP进程下，宣告网络10.1.1.1/30时，下列配置正确的是（）。
（多选）A. network 10.1.1.0B. undo summary network 10.1.1.0C. Version 2 summary network 10.0.0.0D. undo summary network 10.1.0.0E. network 10.0.0.0答案: CE4.VRP系统中的登陆超时时间需要在VTY接口下配置。
A. 正确B. 错误答案: B5.NAPT是通过TCP或者UDP或者IP报文中的协议号区分不同用户的IP地址。
A. 正确B. 错误答案: B6.从源设备到目的设备之间有两台路由器RTA和RTB，使用Tracert命令来检查路径。
检查第一跳RTA时，源设备对目的设备的某个较大的端口发送一个TTL为1的UDP报文，当该报文到达RTB时，TTL将变为0，于是RTA对源设备回应一个ICMP（）消息。
A. Time ExceededB. Echo RequestC. Echo ReplyD. Port Unreachable答案: A7.关于访问控制列表编号与类型的对应关系，下面描述正确的是（）。
A. 基本的访问控制列表编号范围是1000-2999B. 高级的访问控制列表编号范围是3000-9000C. 基本的访问控制列表编号范围是4000-4999D. 基本的访问控制列表编号范围是1000-2000答案: C8.以下两条配置命令可以实现路由器RTA去网同一目的地10.1.1.0的路由主备备份：[RTA]ip route-static 10.1.1.0 24 12.1.1.1 permanent[RTA]ip route-static 10.1.1.0 24 13.1.1.1A. 正确B. 错误答案: B9.ACL不会过滤设备自身产生的访问其他设备的流量，只过滤转发的流量，转发的流量中包括其他设备访问该设备的流量。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
Internet Engineering Task Force (IETF) E. Baccelli, Ed. Request for Comments: 5889 INRIA Category: Informational M. Townsley, Ed. ISSN: 2070-1721 Cisco Systems September 2010 IP Addressing Model in Ad Hoc NetworksAbstractThis document describes a model for configuring IP addresses andsubnet prefixes on the interfaces of routers which connect to linkswith undetermined connectivity properties.Status of This MemoThis document is not an Internet Standards Track specification; it is published for informational purposes.This document is a product of the Internet Engineering Task Force(IETF). It represents the consensus of the IETF community. It hasreceived public review and has been approved for publication by theInternet Engineering Steering Group (IESG). Not all documentsapproved by the IESG are a candidate for any level of InternetStandard; see Section 2 of RFC 5741.Information about the current status of this document, any errata,and how to provide feedback on it may be obtained at/info/rfc5889.Copyright NoticeCopyright (c) 2010 IETF Trust and the persons identified as thedocument authors. All rights reserved.This document is subject to BCP 78 and the IETF Trust’s LegalProvisions Relating to IETF Documents(/license-info) in effect on the date ofpublication of this document. Please review these documentscarefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e ofthe Trust Legal Provisions and are provided without warranty asdescribed in the Simplified BSD License.Baccelli & Townsley Informational [Page 1]Table of Contents1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 32. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 43. Applicability Statement . . . . . . . . . . . . . . . . . . . . 44. IP Subnet Prefix Configuration . . . . . . . . . . . . . . . . 45. IP Address Configuration . . . . . . . . . . . . . . . . . . . 46. Addressing Model . . . . . . . . . . . . . . . . . . . . . . . 5 6.1. IPv6 Model . . . . . . . . . . . . . . . . . . . . . . . . 56.2. IPv4 Model . . . . . . . . . . . . . . . . . . . . . . . . 67. Security Considerations . . . . . . . . . . . . . . . . . . . . 68. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . . 71. IntroductionThe appropriate configuration of IP addresses and subnet masks forrouter network interfaces is generally a prerequisite to the correct functioning of routing protocols. Consideration of various items,including underlying link capabilities and connectivity, geographical topology, available address blocks, assumed traffic patterns etc.,are used when determining the appropriate network topology and theassociated IP interface configuration.When the capabilities and connectivity of the links that connectrouters are well-known and stable, logical network topology designand corresponding IP interface configuration are straightforward.Absent any assumption about link-level connectivity, however, thereis no canonical method for determining a given IP interfaceconfiguration.Link-level connectivity is generally qualified as undetermined whenit is unplanned and/or time-varying in character. Ad hoc networksare typical examples of networks with undetermined link-levelconnectivity. Routing protocols for ad hoc networks are purposelydesigned to detect and maintain paths across the network, even whenfaced with links with undetermined connectivity, assuming thatrouters’ interfaces are configured with IP addresses. This document thus proposes a model for configuration of IP addresses and subnetprefixes on router interfaces to links with undetermined connectivity properties, to allow routing protocols and data packet forwarding to function.Note that routers may ultimately need additional IP prefixes for the diverse applications that could run directly on the routersthemselves, or for assignment to attached hosts or networks. For Baccelli & Townsley Informational [Page 2]IPv6, these addresses may be global [RFC3587], Unique-Local [RFC4193] or Link-Local [RFC4291]. For IPv4, the addresses may be global(i.e., public) or private [RFC1918]. In general, global scope isdesired over local scope, though it is understood that this may notalways be achievable via automatic configuration mechanisms. In this document however, automatic configuration of the prefixes used forgeneral applications is considered as a problem that is separablefrom that of automatic configuration of addresses and prefixesnecessary for routing protocols to function. This document thusfocuses on the latter: the type of IP address and subnet maskconfiguration necessary for routing protocols and data packetforwarding to function.2. TerminologyThis document uses the vocabulary and the concepts defined in[RFC1918] and [RFC4632] for IPv4, as well as [RFC4291] for IPv6.3. Applicability StatementThis model gives guidance about the configuration of IP addresses and the IP subnet prefixes on a router’s IP interfaces, which connect to links with undetermined connectivity properties.When more specific assumptions can be made regarding the connectivity between interfaces or the (persistent) reachability of someaddresses, these should be considered when configuring subnetprefixes.4. IP Subnet Prefix ConfigurationIf the link to which an interface connects enables no assumptions of connectivity to other interfaces, the only addresses that can beassumed "on link", are the address(es) of that interface itself.Note that while link-local addresses are assumed to be "on link", the utility of link-local addresses is limited as described in Section 6. Thus, subnet prefix configuration on such interfaces must not makeany promises in terms of direct (one hop) IP connectivity to IPaddresses other than that of the interface itself. This suggests the following principle:o no on-link subnet prefix should be configured on such aninterface.Note that if layer 2 communication is enabled between a pair ofinterfaces, IP packet exchange is also enabled, even if IP subnetconfiguration is absent or different on each of these interfaces. Baccelli & Townsley Informational [Page 3]Also note that if, on the contrary, assumptions can be made regarding the connectivity between interfaces, or regarding the persistentreachability of some addresses, these should be considered whenconfiguring IP subnet prefixes, and the corresponding interface(s)may in such case be configured with an on-link subnet prefix.5. IP Address ConfigurationRouting protocols running on a router may exhibit differentrequirements for uniqueness of interface addresses; some have no such requirements, others have requirements ranging from local uniqueness only, to uniqueness within, at least, the routing domain (as defined in [RFC1136]).Routing protocols that do not require unique IP addresses within the routing domain utilize a separate unique identifier within therouting protocol itself; such identifiers could be based on factoryassignment or configuration.Nevertheless, configuring an IP address that is unique within therouting domain satisfies the less stringent uniqueness requirements, while also enabling protocols that have the most stringentrequirements of uniqueness within the routing domain. As a result,the following principle allows for IP autoconfiguration to apply tothe widest array of routing protocols:o an IP address assigned to an interface that connects to a linkwith undetermined connectivity properties should be unique, atleast within the routing domain.6. Addressing ModelSections 4 and 5 describe principles for IP address and subnet prefix configuration on an interface of a router, when that interfaceconnects to a link with undetermined connectivity properties. Thefollowing describes guidelines that follow from these principles,respectively for IPv6 and IPv4.Note that the guidelines provided in this document slightly differfor IPv6 and IPv4, as IPv6 offers possibilities that IPv4 does not(i.e., the possibility to simply not configure any on-link subnetprefix on an IPv6 interface), which provide a "cleaner" model.Baccelli & Townsley Informational [Page 4]6.1. IPv6 ModelFor IPv6, the principles described in Sections 4 and 5 suggest thefollowing rules:o An IP address configured on this interface should be unique, atleast within the routing domain, ando No on-link subnet prefix is configured on this interface.Note that while an IPv6 link-local address is assigned to eachinterface as per [RFC4291], in general link-local addresses are oflimited utility on links with undetermined connectivity, asconnectivity to neighbors may be constantly changing. The knownlimitations are:o In general, there is no mechanism to ensure that IPv6 link-localaddresses are unique across multiple links, though link-localaddresses using an IID that are of the modified EUI-64 form should be globally unique.o Routers cannot forward any packets with link-local source ordestination addresses to other links (as per [RFC4291]), whilemost of the time, routers need to be able to forward packets to/from different links.Therefore, autoconfiguration solutions should be encouraged toprimarily focus on configuring IP addresses that are not IPv6 link-local.6.2. IPv4 ModelFor IPv4, the principles described in Sections 4 and 5 suggest rules similar to those mentioned for IPv6 in Section 6.1, that are:o An IP address configured on this interface should be unique, atleast within the routing domain, ando Any subnet prefix configured on this interface should be 32 bitslong.Note that the use of IPv4 link-local addresses [RFC3927] in thiscontext should be discouraged for most applications, as thelimitations outlined in Section 6.1 for IPv6 link-local addressesalso concern IPv4 link-local addresses. These limitations arefurther exacerbated by the smaller pool of IPv4 link-local addresses to choose from and thus increased reliance on Duplicate AddressDetection (DAD).Baccelli & Townsley Informational [Page 5]7. Security ConsiderationsThis document focuses on the IP address and subnet mask configuration necessary for routing protocols and data packet forwarding tofunction. [RFC4593] describes generic threats to routing protocols, whose applicability is not altered by the presence of interfaces with undetermined connectivity properties. As such, the addressing model described in this document does not introduce new security threats.However, the possible lack of pre-established infrastructure orauthority, as enabled by the use of interfaces with undeterminedconnectivity properties, may render some of the attacks described in [RFC4593] easier to undertake. In particular, detection ofmalevolent misconfiguration may be more difficult to detect and tolocate.8. References8.1. Normative References[RFC1136] Hares, S. and D. Katz, "Administrative Domains and Routing Domains: A model for routing in the Internet", RFC 1136,December 1989.[RFC4291] Hinden, R. and S. Deering, "IP Version 6 AddressingArchitecture", RFC 4291, February 2006.[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "DynamicConfiguration of IPv4 Link-Local Addresses", RFC 3927,May 2005.[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets",BCP 5, RFC 1918, February 1996.[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 UnicastAddresses", RFC 4193, October 2005.[RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 GlobalUnicast Address Format", RFC 3587, August 2003.[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing(CIDR): The Internet Address Assignment and AggregationPlan", BCP 122, RFC 4632, August 2006.Baccelli & Townsley Informational [Page 6]8.2. Informative References[RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats toRouting Protocols", RFC 4593, October 2006.Baccelli & Townsley Informational [Page 7]Appendix A. ContributorsThis document reflects discussions and contributions from severalindividuals including (in alphabetical order): Teco Boot, ThomasClausen, Ulrich Herberg, Thomas Narten, Erik Nordmark, CharlesPerkins, Zach Shelby, and Dave Thaler.Authors’ AddressesEmmanuel Baccelli (editor)INRIAEMail: Emmanuel.Baccelli@inria.frURI: /Mark Townsley (editor)Cisco SystemsEMail: mark@Baccelli & Townsley Informational [Page 8]。