SDN中“软件”如何定义“网络”SDN软件定义网络,字面释义都说了是“软件”来定义“网络”,但有心之人会想:这个“软件”到底是如何定义了我们所熟知的“网络”?众所周知,SDN软件定义网络,核心思想就是所谓的“转发、控制分离”,正所谓一谈SDN必谈“转发、控制”,一传十十传百,口口相传。当我们这些产品经理到客户现场交流SDN时,或许客户也能娓娓道来“转发、控制、分离”。但事实是怎么样呢? B. SDN控制器对于ARP报文的处理
背景阐述: ① 网络拓扑已发现 ② 控制器采用ODL(OpenDayLight) ③ 本地主机H1(10.0.0.1)和对端主机H2(10.0.0.2)均连接于SDN交换机下面 ④ 整个过程是H1请求H2的ARP,H2响应H1 整个解析过程 ① H1去pingH2,即10.0.0.1去ping10.0.0.2。因为没有H2的MAC,此时需要做一次ARP解析。此时ARP请求(原本是广播)被SwitchA通过Openflow形式单播上送给Controller(packet-in报文) ② Controller收到H1的ARP请求,记录H1位于Switch A下游,且记录相关的位置信息。 ③ 正因为Controller有所有交换机的拓扑及位置信息,此时Controller会给全网中每台SDN交换机都发送一个10.0.0.0/8网段的ARP请求消息,来请求10.0.0.2的MAC地址。但源IP并非10.0.0.1,而是Controller的网关地址,此处为10.0.0.254。此时报文均为packet-out,即通过Controller手工泛洪,但此泛洪是有选择性的,只针对同网段(10.0.0.0/8) ④ 所有交换机都能收到此ARP单播请求,而只有Switch B会做出回应,因为H2接在Switch B下游。此时通过packet-in,所有SDN交换机会将此ARP泛洪发送到同网段的端口。 ⑤ H2收到此时的ARP请求,正常做出回应。 ⑥ Switch B收到H2的ARP响应,无脑上送到Controller。Controller收到ARP响应,发现正是前面发出的ARP请求的响应报文。记录此时的H2位置信息及ARP信息。 ⑦ Controller通过Openflow将ARP响应回应给Switch A,Switch A将报文回送给H1。 此时做个小结,Controller已经完整知道SwitchA/SwitchB/H1/H2的位置信息及MAC/ARP信息。Switch A/H1知道完整的ARP/MAC信息。而SwitchB也有H1/H2的完整IP。唯独H2此时只知道H1的IP,而不知道H1的MAC。 ⑧ H1的整个ARP请求过程已经完成。接下来要输送ICMP请求报文。报文经由Switch A正常输送到H2(此时是实际转发流量,而且Switch A已有完整转发路径,不需要再上送Controller) ⑨ H2收到ICMP报文,想要回应,但是没有H1的MAC,需要再次做ARP请求。此时H2请求H1的MAC地址,报文被Switch B上送Controller,Controller已有H1的MAC,则Controller做出回应,将H1的MAC回应给H2。 ⑩ H2收到ARP,则整个过程完整。回应ICMP报文。整个业务流打通。 可以看到,最关键的应该是第三步,即Controller发送伪装ARP报文给全局同网段交换机,以此来实现ARP广播的同样效果。但也正是这样一个看似合理的安全行为,带来了很多不安全的隐患。可以想象,Controller有几种方式可以获取终端主机的MAC情况:1.通过免费ARP的方式、2.定时申请下游终端的MAC方式,都可以保证对下游终端MAC的始终更新。 但同样,集中Controller的方式也带来了单点安全的风险考虑,一旦一台下游主机中毒,不断变化自己的MAC不断做出更新动作,此时会极大消耗Controller的资源,形成DOS攻击。同样,Controller的安全如果不是很坚固,则一旦被攻破,所有终端信息一览无余。 抛砖引玉,SDN的安全还有很多路要走。
责编:樊晓婷 微信扫一扫实时了解行业动态 微信扫一扫分享本文给好友 著作权声明:kaiyun体育官方人口
文章著作权分属kaiyun体育官方人口
、网友和合作伙伴,部分非原创文章作者信息可能有所缺失,如需补充或修改请与我们联系,工作人员会在1个工作日内配合处理。 |
最新文章
|