- A+
【NE探秘】一个报文的路由器之旅-(10)IP组播转发流程【原创】
嗨，亲爱的朋友们，NE探秘系列技术帖又与您相约了，有没有很期待？
前面我们跟大家一起学习了介绍了IP单播转发流程和L2桥接转发流程，相信大家都比较熟悉了吧。本帖我们将给大家详细介绍IP组播的转发流程，包括组播基础知识和转发流程两部分。
组播快速入门
单播、组播和广播
IP通信有三种典型的方式：
• 第一种是单播（unicast），是在一台源IP主机和一台目的IP主机之间进行。网络上绝大部分的数据都是以单播的形式传输的，例如，电子邮件收发、网页浏览、优酷/土豆等的视频点播，都是采用单播实现的。单播属于一对一（点对点）的通讯方式，同时只有一个发送者和一个接收者，中间的交换机和路由器对数据只进行转发不进行复制。
• 第二种是广播（broadcast），在一台源IP主机和网络中所有其它的IP主机之间进行。广播属于一对所有的通讯方式，无路由过程，中间的交换机和路由器对数据进行无条件的复制和转发，所有主机都可以接收到（不管是否需要）。广播不仅会将信息发送给不需要的主机而浪费带宽，也可能由于路由回环引起严重的广播风暴，所以广播数据被限制在二层交换的局域网范围内，禁止其穿过路由器，防止广播数据影响大面积的主机。但IP网络中，广播也是不可少的，如客户机通过DHCP自动获得IP地址的过程，通过ARP请求获得某IP地址对应的MAC地址的过程，都需要使用广播。
• 第三种是组播（Multicast），在一台源IP主机和网络中多台（一组）IP主机之间进行。组播是一对多（点对多点）的通讯方式，同时有一个发送者和多个接收者，中间的交换机和路由器根据接收者的需要，有选择性地对数据进行复制和转发。视频/音频会议、网络电视、股票行情发布等，便是采用组播形式。
可能有读者会有疑问，网页浏览和网络视频点播，虽然不是所有人都想看，但观看的人数不少，假设有1000个人想看同一个网页/视频，采用单播，服务器就得逐一传送，重复1000次相同工作，那为什么采用单播不是组播呢？
那是因为，不是所有客户都是同一时间想看同一内容，单播能够针对每个客户的及时响应；如果采用组播，用户便有“过了这个村就没那个点“的烦恼。视频/音频会议、股票行情发布，实时性很高，用户在同一时间看同一内容，就很适合采用组播。
组播对于网络而言还是很有魅力的，比如下图所示场景，一目了然，组播比单播更能节约网络资源，也极大减轻了服务器的负担。
组播分发树
上图右侧所示的网络流量转发路径，像不像一棵倒长的树？这棵树称为”组播分发树“，树根是服务器（称为组播源）；树叶是客户端（称为组播接收者）。只是，组播分发树有个特别之处，从根到叶子都是一样粗，也就是说，网络负载不会随着组播接收者（客户端）数量的增加而增加，这就是组播的魅力所在。
那么，IP网络是如何将报文从组播源沿着组播分发树发送给众多接收者呢？如下图中的Router-X收到组播数据后，该如何转发呢？
按照传统IP的寻址转发机制，首先Router-X要到转发表去匹配目的接收者的地址，找到对应的出接口。上图中，组播的目的地址是组播接收者1、接收者2、……，接收者7；出接口是接口A、接口B。那么，Router-X在转发组播数据时，是拿数据包去逐一匹配目的地址（组播接收者1、接收者2、……，接收者7）吗？这显然效率太低了。如果组播接收者的数量非常巨大，尤其是越靠近组播源的节点，其组播接收者越多。这么大量的组播接收者，如果都在组播转发表项中都列出来，转发时逐一去匹配，是不大现实的。为此，诞生了“组播组“这个词。
组播组
“组播组“用来表示一群组播接收者，即组播接收者的集合。组播组并不代表网络上的具体主机，仅仅代表相应的接收者组成的集合，只用于组播报文从组播源往接收者方向发送，是单向的。“组播组”如同电视频道，组播源如同电视台。电视台向某频道内发送数据；观众想看该频道的节目，就打开电视机切换到该频道即可。
组播组地址
为了让组播数据在网络中能被正确的寻址转发，需要给“组播组”分配地址。
组播报文在三层（IP）层转发时，使用的是D类IP地址，即224.0.0.0至239.255.255.255之间的IP地址。协议规定，其中的224.0.0.0至224.0.0.255为保留的组播地址，给本地网络协议使用，比如224.0.0.5和224.0.0.6这两个是OSPF协议使用的组播地址，路由器对收到的目的地址在此范围内的报文，不管报文的TTL值是多少，都不能进行转发。
当组播报文在以太二层网络转发时，需要用到组播MAC地址。组播MAC地址同单播MAC地址一样，都是48bit，一般用6字节的十六进制来表示，如XX-XX-XX-XX-XX。IEEE 802.3规定，MAC的第0字节的末位（The last bit of the first byte）用于表示这个地址是组播/广播地址还是单播地址，如果这一位是0，表示此MAC地址是单播地址，如果这位是1，表示此MAC地址是多播地址或广播地址。其中，广播地址只有一个，即FF-FF-FF-FF-FF-FF。到目前为止，大部分组播MAC地址都是以0x01-00-5E开头，即01-00-5E-XX-XX-XX。
组播转发表四要素
如下图，按照传统IP的寻址转发机制，Router-X收到组播数据，到转发表去匹配目的接收者的地址，找到对应的出接口。根据前面描述，组播转发表的目的接收者的地址是“组播组地址”，出接口列表为{出接口A、出接口B}。如果有匹配的组播组地址，则将组播数据从出接口A和出接口B发送。这样就完美了吗？
其实不然。组播报文是发送给一组接收者的，如果转发了不该转发的数据，造成的影响很大，比如下图中，正确的组播转发应该是蓝色箭头所示的方向。如果由于某种原因，Router-X把组播数据错发了一份给RouterY（入红色箭头标识的流量），那么就会多出好多流量，浪费大量网络资源。如果存在路由环路，影响则更大。
为了能确保正确发送组播数据，组播必须严格沿着组播分发树转发，即，沿着远离组播源的方向进行转发。为了做到这点，组播技术引入了RPF（Reverse Path Forwarding，逆向路径转发）检查机制，路由器转发组播数据时，执行RPF检查，确保组播数据流能够沿组播转发树正确的传输，同时可以避免转发路径上环路的产生。RPF检查的过程是：在接收到报文后，在单播转发表中，查找到组播源地址的路由，如果该路由的出接口就是报文的入接口，则检查通过，否则不通过。也就是说，组播转发时，不仅要关心数据要到哪里去，还要关心它从哪里来。
但在实际组播数据转发过程中，如果对每一份接收到的组播数据报文都通过查找单播路由表进行RPF检查，会给路由器带来很大负担。因此，URPF检查应该放在转发表项生成之前进行，也就是路由器在生成路由表的过程中进行URPF检查，得到“组播源”及“到组播源的接口”，并将这两个信息也放入转发表项。这样，在转发组播报文时，匹配组播报文的源地址是否为转发表的“组播源”，报文的目的地址是否为转发表的“组播组地址”，如果匹配上，则判断接收报文的入接口是否就是“到组播源的接口”，如果是，表面数据是安全无误的，可以转发，如果接收报文的入接口不是“到组播源的接口”，则丢弃报文。
所以，组播转发表有四要素：“组播源”、“组播组”、“到组播源的接口”、“出接口列表”，其中组播源和组播组作为匹配对象，是个组合，通常表示为（S,G）。其中，S是Source首字母，表示组播源；G是Group的首字母，表示组播组。如下图的Router-X的组播转发表项为：（10.1.1.1, 255.1.1.1）, GE1/0/0, {GE2/0/0, GE3/0/0}。
IP组播转发流程
IP组播转发流程如下图所示。需要关注的地方在于查表转发环节（其他环节在本系列的前1~7帖中已描述，不再赘述）。
查表转发流程：
步骤1 判断报文的目的MAC是否为组播MAC，如果不是，则做单播转发；是则继续下一步骤。
步骤2 判断报文的协议类型是否为IP，如果不是，则进入其他转发流程；是则继续下一步骤。
步骤3 检查报文的长度、IP地址、Checksum字段是否正确，如果不正确，则丢弃报文，否则继续下一步骤。
步骤4 判断是否为组播IP地址，如果不是组播则丢弃报文，是则进入继续下一步骤。
步骤5 检查入接口是否使能IP组播，如果不是则丢弃报文，是则继续下一步骤。
步骤6 在组播FIB（MFIB）表（如果是公网的报文，查公网MFIB表，如果是VPN报文，则查对应VPN的MFIB表）查找是否存在匹配的（S，G）表项：
• 如果存在匹配的（S，G）表项，并且接收该报文的接口与转发表项的入接口一致，则继续步骤7的处理。特殊地，对于Register状态的出接口，表明本设备为源DR但还没收到RP的Register-Stop消息，这时需要将收到的组播上送CPU（的组播协议模块），将组播报文封装在注册消息发送给RP。
• 如果存在匹配的（S，G）表项，但入接口不一致，将报文上送CPU处理。CPU进行RPF检查：对照单播路由表，若到组播源的接口与(S,G)表项的入接口一致，则说明（S，G）表项正确，报文来源路径错误，将报文丢弃；否则说明（S，G）表项已过时，于是根据单播路由表更新（S，G）表项中的入接口，并刷新转发表。然后再检查收到报文的接口是否就是更新后的接口，是则继续步骤7的处理，否则将其丢弃。
• 如果不存在匹配的（S，G）表项，有两种场景：
一种场景是本路由器是源DR，收到组播源发送的第1个组播报文，此时还没有（S,G）表项，需要将报文上送CPU处理，将报文封装成Register消息发给RP，同时CPU下发出接口为空的（S,G）表项，等收到RP的注册报文再添加出接口。如果注册失败，则为了减少上报对CPU的负担，后续的组播数据流就会进行转发，但是因（S,G）表项出接口为空，实际上是把报文丢弃了。
另一种场景是组播组的第1个报文从RP向接收者方向发送时，由于共享树上（除RP外）的路由器只有（*，G）表项，没有(S,G)表项，此时收到的组播报文也上送CPU处理，CPU生成(S,G)表项，其出接口列表从（*，G）表项拷贝。接着CPU对报文进行RPF检查，如果检查失败则丢弃报文，否则继续步骤7的处理。
步骤7 检查匹配的（S,G）表项是否有对应的组成员，即检查对应的出接口列表是否为空，如果为空，则报文丢弃；，否则继续下一步骤。
步骤8 检查报文的入接口与（S,G）表项的入接口是否一致，如果不一致则丢弃报文，否则继续下一步骤。
步骤9 进行组播复制等后续处理，如上行TM进行板间组播复制，下行TM进行板内组播复制。详细处理过程在本系列的前1~7帖中已描述，不再赘述，如您遗忘了，快戳下方的链接复习一下吧：）
本系列漫谈一个报文的路由器之旅，您将看到：
0、开篇引言（转发全景图）（点击可打开链接）
1、交换与寻址转发（点击可打开链接）
2、报文收发、解析与封装（点击可打开链接）
3、流量控制（反压、队列、限速） （点击可打开链接）
4、QoS基础（上篇） （点击可打开链接）
5、QoS基础（下篇） （点击可打开链接）
6、QoS处理流程 （点击可打开链接）
7、转发层面的其他处理（组播复制、NAT、包过滤、策略路由等）（点击可打开链接）
8、协议报文之旅（点击可打开链接）
9、IP单播转发流程（点击可打开链接）
10、L2桥接转发流程（点击可打开链接）
11、IP组播转发流程（本贴）
12、MPLS转发流程
迫不及待想看到全部的技术帖么？莫急莫急，猛戳阅读原文，开启您个人的路由器探秘之旅吧！
常见的各品牌路由器默认IP地址汇总清单
在实际生活中，人们难免会遇到需要对路由器进行一番配置，但又不知道设备的默认IP地址的情况。如果是自家的路由器，大不了硬重置（长按reset键）；但如果是别人的，恰巧他们又不知道该如何重新设定各种账号密码或参数，问题就比较大条了。为了化解这种尴尬，感兴趣的网友可以先行预习下各品牌的默认管理IP（不然就老实去翻看设备底部的标签吧）。
通常情况下，设备的底部都会贴上一张显示本地局域网管理IP（比如192.168.1.1）的标签，但如果设备放在难以触及的地方、或者铭牌字迹模糊甚至丢失的话，大家不妨从“ipconfig”命令着手。
默认网关（Default Gateway）即上层路由的IP地址。
在包括Windows在内的系统中，均支持在终端上运行“ipconfig”命令。（当然，如果有耐心的话，你也可以只通过鼠标，一步步地点击到网络连接中查看当前参数）。
下面是各常见品牌路由器的默认IP清单：
如果您使用的设备品牌不在上述列表中，也可以试着访问下RouterIPAddress.com或SetupRouter.com。
如果还不小心忘记了设备的默认账号与登录密码，也不妨去RouterPasswords.com或PortForward.com试下运气。
当然，在完成设置之后，我们还是建议你修改掉默认的账号或管理密码，以免因某些漏洞而被黑客攻击利用。
【NE探秘】一个报文的路由器之旅-(8)IP单播转发流程【原创】
嗨，亲爱的朋友们，NE探秘系列技术帖又与您相约了，有没有很期待？
本系列的前1~7帖介绍了一个报文在转发层面的处理流程，该流程中最重要的处理就是转发流程。不同业务有不同的转发流程，本系列后面几帖将分别介绍各类业务的转发流程，本帖介绍IP单播的转发流程，包括IPv4单播和IPv6单播。
一个报文的路由器之旅
——（8）IP单播转发流程
IP单播转发流程
端到端的IPv4单播转发过程
以大家熟悉的以太帧为例，先来回顾下IP单播端到端的转发流程。
下图是个最简单的IP转发场景，某局域网的主机A发送报文给另一局域网的主机B，中间经过一台路由器，那么这台路由器就是PC-A的网关。
由主机PC-A向主机PC-B发送IP报文，那么该报文的目的IP地址就是PC-B的IP地址，源IP地址就是主机PC-A的IP地址，目标MAC地址就是其网关路由器Port1的MAC地址，源MAC地址就是PC-A的MAC地址。
路由器转发过程：
1、路由器收到这个报文，发现其目的MAC为本机Port1端口的，表明需要本机来进行进一步解析（如果目的MAC不是本机，表明直接进行二层转发，不需要再解析帧的其他内容了）；
2、路由器进一步解析报文，得知该帧所承载的协议类型为IPv4（协议类型值=0x800），即需要进行IPv4转发；
3、查IP转发表（FIB表），得知该报文并不是发给自己的，而是需要送往出端口Port2，因此，路由器不再继续分析IP头后面的内容。
4、路由器将目的MAC更换成PC-B的MAC，将源MAC更换为出接口Port2的MAC，并将报文从Port2发送出去。
路由器的IPv4转发全流程
IPv4转发全流程如下图所示。需要关注的地方在于查表转发和获取封装信息两个环节（其他环节在本系列的前1~6贴中已描述，不再赘述）。
1）查表转发详细流程
流程说明：
步骤1、判断报文的目的MAC是否等于本机MAC，如果不是，则做L2转发；是则继续下一步骤。
步骤2、判断报文的协议类型是否为IPv4（例如以太帧，eth_type = 0x800），如果不是，则进入其他转发流程；是则继续下一步骤。
步骤3、检查报文的长度、IP地址、Checksum字段是否正确，如果不正确，则丢弃报文，否则继续下一步骤。
步骤4、判断目的IP地址是否为单播地址，如果不是单播则其他转发处理，是则进入继续下一步骤。
步骤5、用目的IP地址查FIB表得到的下一跳IP、出接口等信息（如果是公网的报文，查公网FIB表，如果是VPN报文，则查对应VPN的FIB表）。
如果是负载分担，会查到多份这样的信息，于是根据负载分担哈希算法选取其中的一份。
如果是FRR（FastReroute）状态，则会根据出接口状态做主备路由选择，如果出接口正常工作，则会选择主路由；否则选择FRR备份路由。
如果出接口为Trunk接口，会再根据Trunk负载分担哈希算法，选择Trunk成员口中的其中一个作为最终的出接口。
步骤6、如果使能了URPF检查，则用源IP地址查FIB表，如果命中，对于松散的URPF检查只要出接口为真实的外部接口则检查通过（对于出接口为CPU、NULL接口、TE接口、IPv4 Tunnel接口则松散的URPF检查不通过）；对应严格的URPF检查，用报文的入端口信息与源IP地址查FIB表得到的出口信息进行比较，相等则通过，不等则丢弃（对于入接口为VLAN子接口，出接口为入端口信息，同时出接口VLANID也要等于入口的VLANID，则检查才会通过）。
说明：
URPF（Unicast Reverse Path Forwarding），是一种单播逆向路由查找技术，用来预防伪造源地址攻击的手段。之所以称为逆向，是针对正常的路由查找而言的。一般情况下路由器接收到报文，获取报文的目的地址，针对目的地址查找路由。如果找到了进行正常的转发，否则丢弃该报文。
URPF的实现原理：通过获取报文的源地址和入接口，以源地址为目的地址，在转发表中查找源地址对应的接口是否与入接口匹配。如果不匹配认为源地址是伪装的，丢弃该报文。通过这种方式，能有效地防范网络中通过修改源地址而进行的恶意攻击行为的发生。
然而，有的场景（例如负载分担）同一目的地址在路由表中存在有多条路由表项，同一目的IP地址的报文发送的接口不唯一，即非对称路由。此时若应用URPF时，报文会异常丢弃。因此，URPF出现了严格模式和松散模式。严格模式要求接口匹配；而松散模式，不检查接口是否匹配，只要路由表项中存在针对源地址的路由，数据报文就通过URPF检查。
步骤7、如果目的IP为非本机IP，则报文头的TTL减1，并重新计算并修改Checksum值，继续执行后续的CAR等公共处理。如果目的IP为本机（查表发现下一跳为127.0.0.1），则直接送入上行TM部件。
之后的处理中，交换网根据出接口信息（出接口信息包含了目的单板和目的出接口）信息将报文发送到正确的下行单板。
2）获取封装信息
到了下行，下行包转发引擎PFE用下一跳IP或目的IP和VLANID查ARP表项，获取目的MAC信息，根据出接口信息查出接口表项获取端口MAC。因为，路由器需要将报文的目的MAC更换成下一跳设备的MAC，将源MAC更换成自己出接口的MAC。
如果查ARP表项没有命中，则启动ARP学习功能，过程如下：
1） 发送ARP请求报文，此报文的目的MAC为广播地址，目的地址为下一跳IP，源IP为自己的IP。
2）由于是MAC广播报文，在局域网内的设备或主机都能收到，因此下一跳设备也能收到。于是下一跳设备解析报文发现目的IP为自己，便发送ARP回应报文，里面携带了自己的MAC地址。
3）路由器收到回应报文，得到下一跳的MAC地址，添加到ARP表项中。
通过ARP学习后，重新查ARP表项获取下一跳MAC信息，便可继续后续的处理。
3）出口检查和封装
对于目的IP为本机的，在出口处理模块处上送到接口板CPU，再上送给主控板CPU。
对于目的地址非本机的，则在出接口处理模块时，根据需要进行MTU检查。如果报文长度不超过MTU，则将报文发送给接口卡。接口卡用待发送的数据帧内容计算帧检验序列FCS，然后对数据帧加封装帧间隙、前导码、帧开始界定符和FCS，并将数据帧转换成光/电信号，再发送到出接口线路上。
如果报文长度超过MTU，则判断报文头DF位，如果DF位置0，则分片后再发送给接口卡；若DF置1，表示报文源端不允许该报文分片，所以将报文做CP-CAR检查后上送接口板CPU，再上送主控板CPU，以便回应ICMP Too-Big消息给源端。
IPv6单播转发流程
IPv6转发流程与IPv4基本相同，不同点在于：
- 所查的表项不同，IPv4查FIBv4表，而IPv6查的是FIBv6表；IPv4查ARP表，而IPv6则是查邻居表。
- IPv6 MTU检查时，超过接口IPv6 MTU时不进行分片，而是上送CPU并返回ICMPv6 Too-big消息给源端（这符合IPv6协议标准）。
本系列漫谈一个报文的路由器之旅，您将看到：
0、开篇引言（转发全景图）（点击可打开链接）
1、交换与寻址转发（点击可打开链接）
2、报文收发、解析与封装（点击可打开链接）
3、流量控制（反压、队列、限速）（点击可打开链接）
4、QoS基础（上篇）（点击可打开链接）
5、QoS基础（下篇）（点击可打开链接）
6、QoS处理流程（点击可打开链接）
7、转发层面的其他处理（组播复制、NAT、包过滤、策略路由等）（点击可打开链接）
8、协议报文之旅（点击可打开链接）
9、IP单播转发流程（本帖）
10、L2桥接转发流程
11、IP组播转发流程
12、MPLS转发流程
迫不及待想看到全部的技术帖么？莫急莫急，猛戳阅读原文，开启您个人的路由器探秘之旅吧！
两个路由器ip地址冲突怎么解决？
问：两个路由器IP地址冲突怎么解决？家里路由器A、路由器B两个无线路由器，路由器A连接宽带能够正常上网，把路由器B连接到路由器A上，总是提示IP地址冲突，请问这个问题应该怎么解决。
答：两个路由器连接上网时，由于2个路由器的IP地址都是：192.168.1.1，这时候就会存在IP地址冲突的问题。解决办法就是修改路由器B的IP地址的，如何路由器B的IP地址？和路由器A、B之间的连接有关系的，下面进行详细的介绍。一、路由器A的LAN连接路由器B的WAN
如果是路由器A的LAN口（1、2、3、4）连接路由器B的WAN口，这时候路由器B的IP地址要修改为与路由器A的不在同一个网段。有用户反映不明白，路由器B与路由器A的IP地址不在同一个网段是什么意思，下面举例进行说明。
路由器A的LAN连接路由器B的WAN
如果路由器A的IP地址是：192.168.1.1或者192.168.0.1，那么路由器B的IP地址可以修改为：192.168.2.1，192.168.3.1，192.168.4.1，192.168.5.1等等。
修改方法：
在路由器B的设置界面，点击“网络参数”——>“LAN口设置”——>“IP地址”修改为：192.168.2.1——>点击“保存”，之后会提示重启路由器。
路由器B的IP地址修改为：192.168.2.1
温馨提示：路由器B重启之后，需要在浏览器中输入修改后的IP（本例是：192.168.2.1）重新登录到路由器B的设置界面的。二、路由器A的LAN连接路由器B的LAN
如果路由器A的LAN（1、2、3、4）口连接路由器B的LAN（1、2、3、4）口，这时候需要是路由器B的IP地址，与路由器A的IP地址在同一个网段，下面举例说明。
路由器A的LAN连接路由器B的LAN
（1）、如果路由器A的IP地址是：192.168.1.1，则路由器B的IP地址可以修改为：192.168.1.2，192.168.1.3，192.168.1.4，192.168.1.5，最大可以修改为：192.168.1.254。
（2）、如果路由器A的IP地址是：192.168.0.1，则路由器B的IP地址可以修改为：192.168.0.2，192.168.0.3，192.168.0.4，192.168.0.5，最大可以修改为：192.168.0.254。
总结：也就是路由器A与路由器BIP地址的前3段要保持一致，最后一段不一样。
修改方法
在路由器B的设置界面，点击“网络参数”——>“LAN口设置”——>“IP地址”修改为：192.168.1.200——>点击“保存”，之后会提示重启路由器。
路由器B的IP地址修改为：192.168.1.200
温馨提示：路由器B重启之后，需要在浏览器中输入修改后的IP（本例是：192.168.1.200）重新登录到路由器B的设置界面的。
以上就是两个路由器IP地址冲突的解决办法，大家应该先确定路由器A和路由器B之间的连接，然后在修改一下路由器B的IP地址即可。
在修改路由器B的IP地址的时候需要注意，路由器A的LAN连接路由器B的WAN时，路由器B的IP地址修改为与路由器A的IP地址不在同一个网段。路由器A的LAN连接路由器B的LAN时，路由器B的IP地址要修改为与路由器A的IP地址在同一个网段。
新手必看！快速知道自己路由的IP地址
我们在对无线路由器进行设置时，通过浏览器访问它的后台，就需要用户输入一个路由器的IP地址。但是，每个路由器的IP地址并不是相同的，目前还没有统一的路由器IP地址。往往对于新手来说，找到这一地址是一件很困难的事儿。其实，无线路由器的IP地址通过电脑很容易被发现，我们这就教给大家两招，帮助网络新手快速找到无线路由器的IP地址。
方法一：命令提示符
首先，我们按住键盘上的“Windows”键(一般在ctrl和alt之间)再按R键，就会出来“运行”窗口。在运行窗口中，输入“cmd'”，然后点击确定就会打开“命令提示符”。打开命令提示符以后，我们继续使用键盘输入“ipconfig”，按下回车，就会看到命令提示符中闪现出了一片信息。我们在这些信息中找到“默认网关”那一栏，这里显示的就是无线路由器的IP地址。
方法二：网络和共享中心
如果看着输入这些指令有点儿“头晕”的感觉，我们还可以在“网络和共享中心”中找到无线路怄气的IP地址。在开始操作之前，请用户确认目前电脑已经通过无线或者有线连接到无线路由器。第一步，先在桌面右下角的系统托盘中，单机联网的图标，然后在最下方打开“网络和共享中心”。打开后，我们找到“本地连接”这一栏信息，单机“本地连接”打开。
“本地连接状态”信息就会呈现在大家眼前，下一步我们点击“详细信息”。“详细信息”界面将可以看到所有关于自己网络的细节，无线路由器的IP地址同样存在于“默认网关”的那一栏文字中。这样一来，我们就能够知道自己家中无线路由器的IP地址啦!不过，需要提醒大家的是，路由器IP地址必须自己记录下来，并不支持复制功能。
网络小锦囊|如何设置路由器的IP地址（以TP-Link为例） 1
登录路由器，在浏览器中输入路由器的LAN口的IP地址，在弹出的对话框中填写路由器的管理用户名和密码后进入管理页面。
若路由器为默认设置，则其管理地址为192.168.1.1，用户名与密码均为admin（可以在路由器背后的说明上面找到）
2
登陆路由器成功以后， 在左边框中选择“网络参数”→“WAN口设置”，然后在右边框中的“WAN口连接类型”选择“PPPoE”。“上网账号”和“上网口令”中填入宽带账户的用户名和密码。
未完待续
运营商发行的大量路由器包含高危漏洞，大部分“问题路由器”IP位于中国
微信号：freebuf
据统计，全球的运营商向大众网民发行了至少70万台ADSL路由器，但不幸的是，这些路由器存在高危漏洞，进而很可能会造成大规模路由器攻击活动。值得一提的是，大多数的“问题路由器”IP地址都位于中国。
多项安全漏洞
知名安全研究员Kyle Lovett几个月前在多不同厂商的ADSL路由器中发现了安全漏洞。然而，这些路由器的制造或发行公司竟然一样——运营商。
这些路由器中的大部分都包含目录遍历漏洞，这些路由器存在一个webproc.cgi组件，黑客利用该组件可以窃取受害用户的重要数据。可以肯定的是这些投入使用的路由器的数量非常庞大，并且未来受害用户将更多。当然，这些“问题路由器”从2011年就开始发行了。
这些设备和路由器卖给不同国家的成千上万个互联网用户。有关这些路由器最糟糕的事情是，大多数这些路由器中都包含一个config.xml文件，攻击者完全可以利用路由器中的组件取得其控制权。config.xml里面包含了路由器的所有配置信息，包括管理员连接网络所需的密码，以及其他类似ISP连接用户名和密码账户，并包含客户端和服务器的TR-069凭证。
这些路由器使用的算法非常弱，正是这一点使得攻击者可以轻易拿到绝对控制权。拿到控制器后，攻击者做的第一件事就是以管理员身份登录，并修改路由器设置。所以，针对这种情况，DNS劫持攻击将会是攻击者最常用的方式之一。
所有路由器中存在的漏洞并非一样。60%的路由器都存在一个隐藏的服务账号，而且该帐号还使用了弱密码。另外，其他一些路由器中则存在后门、活动内存快照漏洞（内存中可能包含一些重要信息，包括私人数据）等。
安全研究人员Lovett借助设备漏洞搜索引擎SHODAN发现了2500万的SOHO设备存在漏洞（或已被入侵），而其中大多数的IP地址都位于中国。
参考来源securityaffairs，有适当修改，转载请注明来自FreeBuf黑客与极客（FreeBuf.COM
QQ空间的小伙伴请在微信搜索“齐赛科技网”加关注哦~今天，网络已经成为我们日常生活中必不可少的基础元素之一，因此当网络出现故障时，我们希望第一时间解决这些故障，而登录路由器的Web管理界面正是解决问题较为有效的方法之一。不过大多数用户通常记不住路由器的Web管理地址（相信该地址大多数用户都不会修改，因此通常就是路由器出厂时的默认IP地址），总是从192.168.X.X来不断尝试，以求猜中。
其实想查看路由器的IP地址信息很简单，借助Windows系统的命令提示符即可找到——在命令提示符窗口中输入ipconfig，在显示的信息中，默认网关的地址通常就是路由器的Web管理地址。通过ipconfig查询路由器IP地址
当然，如果你的网络已经断开（你的终端无法与路由器ping通，或者路由器的DHCP已经关闭），那么你就需要查询路由器的默认IP地址，然后为终端设备手工配置同网段的IP地址。那么如何查询路由器的默认IP地址呢？通常随机附带的说明书上会有，但相信大多数用户的路由器说明书早已找不到了，因此我们特别为大家汇总了一些常见路由器的默认IP地址，希望可以帮助大家快速解决网络故障。(内容比较多，建议大家保存图片之后再浏览）
一些常见路由器的默认IP地址
下图是个最简单的IP转发场景，某局域网的主机A发送报文给另一局域网的主机B，中间经过一台路由器，那么这台路由器就是PC-A的网关。
由主机PC-A向主机PC-B发送IP报文，那么该报文的目的IP地址就是PC-B的IP地址，源IP地址就是主机PC-A的IP地址，目标MAC地址就是其网关路由器Port1的MAC地址，源MAC地址就是PC-A的MAC地址。
路由器转发过程：
1、路由器收到这个报文，发现其目的MAC为本机Port1端口的，表明需要本机来进行进一步解析（如果目的MAC不是本机，表明直接进行二层转发，不需要再解析帧的其他内容了）；
2、路由器进一步解析报文，得知该帧所承载的协议类型为IPv4（协议类型值=0x800），即需要进行IPv4转发；
3、查IP转发表（FIB表），得知该报文并不是发给自己的，而是需要送往出端口Port2，因此，路由器不再继续分析IP头后面的内容。
4、路由器将目的MAC更换成PC-B的MAC，将源MAC更换为出接口Port2的MAC，并将报文从Port2发送出去。
路由器的IPv4转发全流程
IPv4转发全流程如下图所示。需要关注的地方在于查表转发和获取封装信息两个环节（其他环节在本系列的前1~6贴中已描述，不再赘述）。
（1）查表转发详细流程
流程说明：
步骤1：判断报文的目的MAC是否等于本机MAC，如果不是，则做L2转发；是则继续下一步骤。
步骤2：判断报文的协议类型是否为IPv4（例如以太帧，eth_type = 0x800），如果不是，则进入其他转发流程；是则继续下一步骤。
步骤3：检查报文的长度、IP地址、Checksum字段是否正确，如果不正确，则丢弃报文，否则继续下一步骤。
步骤4：判断目的IP地址是否为单播地址，如果不是单播则其他转发处理，是则进入继续下一步骤。
步骤5：用目的IP地址查FIB表得到的下一跳IP、出接口等信息（如果是公网的报文，查公网FIB表，如果是VPN报文，则查对应VPN的FIB表）。
如果是负载分担，会查到多份这样的信息，于是根据负载分担哈希算法选取其中的一份。
如果是FRR（FastReroute）状态，则会根据出接口状态做主备路由选择，如果出接口正常工作，则会选择主路由；否则选择FRR备份路由。
如果出接口为Trunk接口，会再根据Trunk负载分担哈希算法，选择Trunk成员口中的其中一个作为最终的出接口。
步骤6：如果使能了URPF检查，则用源IP地址查FIB表，如果命中，对于松散的URPF检查只要出接口为真实的外部接口则检查通过（对于出接口为CPU、NULL接口、TE接口、IPv4 Tunnel接口则松散的URPF检查不通过）；对应严格的URPF检查，用报文的入端口信息与源IP地址查FIB表得到的出口信息进行比较，相等则通过，不等则丢弃（对于入接口为VLAN子接口，出接口为入端口信息，同时出接口VLANID也要等于入口的VLANID，则检查才会通过）。
➤说明：
URPF（Unicast Reverse Path Forwarding），是一种单播逆向路由查找技术，用来预防伪造源地址攻击的手段。之所以称为逆向，是针对正常的路由查找而言的。一般情况下路由器接收到报文，获取报文的目的地址，针对目的地址查找路由。如果找到了进行正常的转发，否则丢弃该报文。
URPF的实现原理：通过获取报文的源地址和入接口，以源地址为目的地址，在转发表中查找源地址对应的接口是否与入接口匹配。如果不匹配认为源地址是伪装的，丢弃该报文。通过这种方式，能有效地防范网络中通过修改源地址而进行的恶意攻击行为的发生。
然而，有的场景（例如负载分担）同一目的地址在路由表中存在有多条路由表项，同一目的IP地址的报文发送的接口不唯一，即非对称路由。此时若应用URPF时，报文会异常丢弃。因此，URPF出现了严格模式和松散模式。严格模式要求接口匹配；而松散模式，不检查接口是否匹配，只要路由表项中存在针对源地址的路由，数据报文就通过URPF检查。
步骤7：如果目的IP为非本机IP，则报文头的TTL减1，并重新计算并修改Checksum值，继续执行后续的CAR等公共处理。如果目的IP为本机（查表发现下一跳为127.0.0.1），则直接送入上行TM部件。
之后的处理中，交换网根据出接口信息（出接口信息包含了目的单板和目的出接口）信息将报文发送到正确的下行单板。
（2）获取封装信息
到了下行，下行包转发引擎PFE用下一跳IP或目的IP和VLANID查ARP表项，获取目的MAC信息，根据出接口信息查出接口表项获取端口MAC。因为，路由器需要将报文的目的MAC更换成下一跳设备的MAC，将源MAC更换成自己出接口的MAC。
如果查ARP表项没有命中，则启动ARP学习功能，过程如下：
1） 发送ARP请求报文，此报文的目的MAC为广播地址，目的地址为下一跳IP，源IP为自己的IP。
2）由于是MAC广播报文，在局域网内的设备或主机都能收到，因此下一跳设备也能收到。于是下一跳设备解析报文发现目的IP为自己，便发送ARP回应报文，里面携带了自己的MAC地址。
3）路由器收到回应报文，得到下一跳的MAC地址，添加到ARP表项中。
通过ARP学习后，重新查ARP表项获取下一跳MAC信息，便可继续后续的处理。
（3）出口检查和封装
对于目的IP为本机的，在出口处理模块处上送到接口板CPU，再上送给主控板CPU。
对于目的地址非本机的，则在出接口处理模块时，根据需要进行MTU检查。如果报文长度不超过MTU，则将报文发送给接口卡。接口卡用待发送的数据帧内容计算帧检验序列FCS，然后对数据帧加封装帧间隙、前导码、帧开始界定符和FCS，并将数据帧转换成光/电信号，再发送到出接口线路上。
如果报文长度超过MTU，则判断报文头DF位，如果DF位置0，则分片后再发送给接口卡；若DF置1，表示报文源端不允许该报文分片，所以将报文做CP-CAR检查后上送接口板CPU，再上送主控板CPU，以便回应ICMP Too-Big消息给源端。
IPv6单播转发流程
IPv6转发流程与IPv4基本相同，不同点在于：
- 所查的表项不同，IPv4查FIBv4表，而IPv6查的是FIBv6表；IPv4查ARP表，而IPv6则是查邻居表。
- IPv6 MTU检查时，超过接口IPv6 MTU时不进行分片，而是上送CPU并返回ICMPv6 Too-big消息给源端（这符合IPv6协议标准）。
济南博赛网络技术有限公司是一家集IT产品销售、高端IT技术服务、技术培训为一体的综合性高新技术企业，与全球多家IT企业建立了长期合作伙伴关系，在产品技术服务领域、高端IT认证培训领域以及产品销售方面都有深层次的合作。
基于SDN的大型IP网络BGP路由优化方案
基于SDN的大型IP网络BGP路由优化方案
摘要：针对IP骨干网路由规模大、路径多、重叠度高而易绕转的问题，在分析传统BGP路由选路机制缺陷的基础上，采用SDN控制技术，提出了一种支持传统路由设备和OpenFlow设备的路由反射优化方法，并给出了具体实现算法及部署方案。典型应用场景的测试结果表明，国际访问时延平均缩短了30%，验证了方法的有效性。
关键词：软件定义网络；OpenFlow；边界网关协议；OpenDaylight
中图分类号：TN915.41
文献标识码：A
doi: 10.11959/j.issn.1000-0801.2016112
Route optimization method for BGP based on
SDN in large-scale IP network
TANG Hong, ZHU Huahong, CAO Weihua, ZOU Jie
Guangzhou Research Institute of China Telecom Co.,Ltd., Guangzhou 510630, China
Abstract: Aiming at rotation problem of route because of large-scale, multi-path, overlap in IP backbone networks, an optimization method for route reflection supported by both traditional routing devices and OpenFlow devices based on SDN controller technology was proposed. At first, the defects of traditional BGP routing mechanism was analyzed in detail. Then, a specific algorithm implementation and deployment scenarios were given. Test results of typical application scenarios demonstrate the validity of the proposed method. The average delay of international access reduces by 30%.
Key words: software defined networking, OpenFlow, border gateway protocol, OpenDaylight
1 引言
近年来，随着产业变革和新技术的发展，互联网迅速成为影响社会经济发展、改善人民生活品质的重要基石。互联网应用不断丰富，宽带用户数高速增长，尤其是“宽带中国”战略进一步促进了宽带网络能力的跃升，网络流量每年以60%的速度高速增长，给IP骨干网运营带来巨大的挑战。互联网路由条目数不断增加，但受限于传统分布式的路由算法以及匮乏的整体网络拓扑，大量的重叠路由导致流量绕转、用户感知下降等问题。因此，随着骨干网规模的增加及流量的增长，如何优化路由选路策略成为一个重要而有价值的研究课题。
软件定义网络（software defined networking，SDN）技术[1]为骨干网路由优化提供了有效手段，但骨干网设备数量多、改造成本高，全网设备的升级替换较为困难，需要考虑兼容现有设备能力的解决方案。本文在分析现有路由反射器选路机制缺陷的基础上，提出了一种基于源和目的地址的路由反射优化方法，并给出了骨干网部署方案。最后，在典型应用场景下进行测试，验证了方法的有效性。
2 传统路由反射器路由选路机制
边界网关协议（border gateway protocol，BGP）[2]是一种自治系统间的动态路由发现协议，它的基本功能是在自治系统间自动交换无环路的路由信息，通过交换带有自治系统号（AS）序列属性的路径可达信息，构造自治区域的拓扑图，从而消除路由环路并实施用户配置的路由策略。在大规模网络中，通过部署路由反射器来减少对等体连接关系，1所示。路由反射器收到多个指向同一IP 地址前缀但下一跳不同的路由信息，路由反射器按照BGP路由选择机制来确定最优路由，也就是选择下一跳，然后转发给客户机和非客户机。选路的规则如下[3]：
（1）如果next-hop无法到达，则不考虑；
（2）首选具有最大weight的路由（Cisco特有）；
（3）如果路由具有相同weight，则使用本地优先级最高的路由；
（4）如果具有相同本地优先级，则首选来自本身路由器的BGP路由；
（5）如果没有来自本身路由器上的BGP路由，则选择AS长度最短的路由；
（6）如果所有的路由具有相同的AS长度，则选择具有最低origin code的路由；
（7）如果origin code相同，则选择MED值最小的路由；
（8）如果MED相同，则首选外部路由，而不是内部路由；
（9）如果仍然相同，选择最近的IGP邻居的路由；
（10）如果仍然相同，选路由器ID最小的路由；
（11）如果仍然相同，选cluster_list最短的路由。
因此，从客户机角度看，经过路由反射器选择后的下一跳可能不是最佳选择——只是距离路由反射器最近的路由，而不是源和目的地址间距离最近的路由，导致次优路由的产生，2所示。
图2中，上海客户机和广州客户机1都有ICP的路由prefix 1，并将该条路由向路由反射器进行通告。路由反射器根据BGP选路规则进行选路，当（1）~（8）的属性都相同，无法判断时，根据规则（9）选择距离自身IGP最近的上海客户机作为下一跳反射给所有客户机，导致广州客户机2接入的用户经上海访问prefix 1，造成路由绕转。
3 基于源和目的地址的路由反射方法
3.1 基于源和目的地址的路由反射方法
传统路由反射器的选路规则在（9）中是从路由反射器自身角度计算到下一跳的IGP最短距离，因此所有的客户机都将收到同样的路由，对于某些客户机来说，该路由并非最优路径。在很多情况下，可能导致流量的绕转，造成时延增大，用户感知下降。针对该问题，IETF也有相关草案，路由器支持add-path功能[4]，反射器反射多条路由，由客户机自行计算最佳路由。考虑目前互联网路由数量超过50万条[5]，且波动较大，因此，对反射器的性能要求较高，客户机需要接收的路由条目也较多，实际应用中实施困难。为此，对该条选路规则进行修改，路由反射器反射路由时，对不同的客户机计算客户机到下一跳的IGP最短距离，从而选择源和目的地址间的路径最短路由。基于OpenFlow技术[6]，在网络中部署OpenFlow控制器，对不同的设备下发不同的流表实现最优路径的选择。图3为OpenFlow 1.3[7]的流表结构，对于相同的路由前缀，针对不同的客户机计算其与各下一跳之间的IGP距离，选择距离最小的下一跳作为最优路由下发流表。
然而，在骨干网中，仍然存在大量传统路由设备，对OpenFlow的支持有限。为了在现网中实现该方法，依然需要考虑基于BGP对网络设备进行控制。控制器主要包含状态信息采集、数据中心、策略管理、网络建模、统一计算以及指令适配模块，具体4所示。
状态信息采集模块采集IP骨干网拓扑及网络基础设施和互联网业务路由、业务流量流向和业务质量等信息数据，同时将这一系列的大数据入库到数据中心；统一计算模块从BGP路由表中选出上述选路规则中（1）~（8）全相同的路由条目，同时计算设备间IGP metric矩阵，并对不同的客户机计算下一跳IGP最短的最优路径；经路由仿真模块验证策略后，最后进行统一下发。主要算法实现如下所示。
步骤1 从当前BGP路由表查找选路规则（1）~（8）中路由属性相同（如local-preference、MED、AS path length）的路由，即经过路由反射器可能产生非优选的路由。
步骤2 将步骤1中查到的路由数据复制到数据表BGP prefix中（先清空BGP prefix中已有数据，再写入）。
步骤3 由于BGP路由更新频繁，为了便于比较更新的路由，数据表prefixSnap用于存放以前采用步骤1获取的路由。将BGP prefix表中的prefix与数据表prefixSnap中的prefix进行比较，如果相同，说明路由没有更新，不做处理；如果不同，则将BGP prefix表中的prefix增量更新到数据表prefixSnap中。
步骤4 采集当前网络中IGP拓扑信息，生成设备间IGP metric矩阵。
步骤5 获取当前控制器的客户机列表igpDevMetric，为了便于比较更新的拓扑，peerIpMetricSnap用于存放以前采集的客户机列表。将igpDevMetric与peerIpMetricSnap进行比较，如果相同，说明拓扑没有更新，不做处理；如果不同，则将igpDevMetric增量更新到peerIpMetricSnap中。
步骤6 获取peerIpMetricSnap中的客户机列表，针对每个客户机，分别以该客户机为根节点，基于IGP metric矩阵，采用SPF算法，对数据表prefixSnap中的相同prefix计算根节点到各下一跳的metric，将metric最小的下一跳作为该prefix的优选路由。
步骤7 无论是否需要进行配置下发，都将上述最优路由进行统计，并将其放入数据表WorkStatus中。
3.2 网络部署方案
软件定义网络技术为传统IP的优化提供了重要手段，然而，IP网络全面实现软件自主定义还有很长的过程。首先是技术的成熟度还不适合大规模现网运营的要求，如高可靠性、高安全性以及电信级SLA要求；其次，现网设备的技术支持能力也成为应用推广的关键。考虑到骨干网仍然以传统网络设备为主及新技术引入的可能风险，网络中的部署方案以增量叠加为主：在网络中部署SDN控制器，支持OpenFlow和BGP，对传统设备采用BGP的更新方式，对OpenFlow设备下发流表进行控制。其部署方案5所示。
控制器与路由反射器、相关的客户机建立IBGP邻居关系，并仅接收路由反射器反射的路由，同时获取IGP metric矩阵信息。结合BGP路由数据库及链路状态数据库，提取多路径路由，计算源到路由接收段之间的SPF计算，针对不同的客户机提取最优路径，经校验路由可达后分别对不同的客户机反射相关路由，或者下发流表，具体算法见第3.1节中的描述。客户机同时收到传统路由反射器及控制器的路由，根据BGP选路信息可以进一步得到最佳路径，放入路由表。该部署方案的好处在于，如果控制器发生故障或者计算错误，可以直接退出服务，原有IP地址仍然起效，不会对网络运营造成巨大影响。为了更好地对全网路由进行维护和监控，系统提供了相关的展示功能，6所示。
路由表中的数据可以按“路由前缀”（prefix字段）、归属AS（destAS字段）、next-hop进行查询及显示，方便人员进行操作。
4 测试结果分析
SDN控制器主要是一个软件实体，目前主流的开源控制器主要有NOX、POX、Ryu等。本文提出的控制器主要基于OpenDaylight开源平台[8]实现，采用OSGI框架和Java开发，南向支持SNMP、BGP、OpenFlow等协议，北向提供RESTful接口[9]，便于实现开放性。
测试的典型场景5所示，大量ICP会在多地接入骨干网，例如从上海、广州两地的ASBR均拥有ICP的路由，经骨干网路由反射器后只优选一条下一跳为上海节点的路由进行反射，导致广州接入段的用户需要绕转到上海节点访问ICP，造成时延增加，用户体验下降。尤其在国际网络环境下，绕转的距离将大幅度增加，从而裂化访问质量。在骨干网（100多台路由器，50万多条互联网路由）中部署SDN控制器，采用本文所提方法采集全网拓扑信息和路由数据，针对广州客户机2，计算出到达ICP的最优路径为广州客户机1，于是对广州客户机2下发下一跳为广州客户机1的ICP路由，实现路由最优化，降低单向访问时延约15 ms，7所示。进一步地，国际访问时延平均可降低30%。测试结果表明，本文方法可实现路由端到端优化，提高互联网访问质量，验证了方法的可行性。
5 结束语
SDN作为一种优化和简化网络操作的体系结构方式，具有更大的灵活性和敏捷性，为基础互联网设施提供了智能化选择，成为当前网络领域最热门和最具发展前途的技术之一。本文针对BGP的缺陷导致IP骨干网路由不佳、流量绕转问题，提出了一种基于SDN的路由反射方法，并给出了网络规模部署方案。测试结果表明，新方法可减少流量绕转情况，国际互联网访问质量可大幅度提升，证明了方法的有效性。然而，SDN作为一项系统工程，仍有大量的技术研发及实例化工作，后续将进一步完善控制器功能，实现网络的高质量运营。
参考文献：
[1]张朝昆, 崔勇, 唐翯祎, 等. 软件定义网络（SDN）研究进展[J]. 软件学报, 2015, 26(1): 62-81.
ZHANG C K, CUI Y, TANG H Y, et al. State-of-the-art survey on software-defined networking (SDN)[J]. Journal of Software, 2015, 26(1): 62-81.
[2]李道丰, 王高才, 王志伟, 等. 标准模型下可证明安全的BGP路由属性保护机制[J]. 计算机学报, 2015, 38(4): 859-871.
LI D F, WANG G C, WANG Z W, et al. Provable secure mechanism for BGP path protection in the standard model[J]. Chinese Journal of Computers, 2015, 38(4): 859-871.
[3]徐建锋, 朱华虹. 改进BGP实现大型复杂IP网络的负载均衡[J]. 电信科学, 2004, 20(10): 15-19.
XU J F, ZHU H H. Load sharing implementation in large complicated IP networks by improving BGP[J]. Telecommunications Science, 2004, 20(10): 15-19.
[4]SCUDDER J, RETANA A, WALTON D, et al. Advertisement of multiple paths in BGP[EB/OL]. [2012-12-30]. http://xueshu.baidu.com/s?wd=Advertisement+of+Multiple+Paths+in+BGP&rsv_bp=0&tn=SE_baiduxueshu_c1gjeupa&rsv_spt=3&ie=utf-8&f=8&rsv_sug2=1&sc_f_para=sc_tasktype%3D%7BfirstSimpleSearch%7D&rsv_n=2.
[5]辛喆. 一种基于SDN的IP骨干网流量调度方案的研究与实现[D]. 北京: 北京邮电大学, 2015.
XIN Z. Research and realization of IP backbone network traffic scheduling program based on OpenFlow[D]. Beijing: Beijing University of Posts and Telecommunications, 2015.
[6]左青云, 陈鸣, 赵广松, 等. 基于OpenFlow的 SDN技术研究[J]. 软件学报, 2013, 24(5): 1078-1097.
ZUO Q Y, CHEN M, ZHAO G S, et al. SDN technology research based on OpenFlow[J]. Journal of Software, 2013, 24(5): 1078-1097.
[7]徐秋伊. 基于SDN的路由映射算法的设计与实现[D]. 北京: 北京邮电大学, 2015.
XU Q Y. Design and realization of route mapping algorithm based on SDN[D]. Beijing: Beijing University of Posts and Telecommunications, 2015.
[8]AHMED S, MARTINI B, GHARBAOUI M, et al. Orchestration algorithms for network-assisted virtual machine migrations using OpenDaylight controller[C]// 2015 2nd International Conference on Electrical Information and Communication Technology (EICT), December 10-12, 2015, Khulna, Bangladesh. New Jersey: IEEE Press, 2015.
[9]WEI Z, LI L, MIN L, et al. REST API design patterns for SDN northbound API[C]// 2014 28th International Conference on Advanced Information Networking and Applications Workshops (WAINA), May 13-16, 2014, Victoria, BC, USA. New Jersey: IEEE Press, 2014: 358-365.
