天下大势,分久必合,合久必分.
推荐书籍:
编程+网络
建议使用Python作为入手语言.
实验工具:
需求:网络产品是硬件形态的产品,迭代远远比软件慢,不能满足需求
SNMP的主要功能还是监控而不是配置 而一个网络体系可能有多种设备,他们的配置命令不尽相同,在建立连接树的时候都是通过:邻居建立-信息共享-路径选择,每一个谁被都有自己的大脑,通过自己的算法建立路径树. 如果网络发生了变动,也是通过接力棒的形式告诉下一棒,太慢了!
全局带宽监控也是未来的趋势,每一个节点都共享出来自己的信息,最终实现了流量可视化
openflow只有三层结构:控制和转发完全分离
应用层:脚本,功能
API
控制层:一个安装了控制器的服务器
openflow南向接口
转发层:设备
controller是最重要的,不仅要上下通讯,同级的controller还要互相通讯
什么是流? 拥有相同属性的数据包集合. eg.同一个IP源,或者同一个目的地,或者同一个协议
流表项到底长什么样?
mininet>dpctl dump-flows//查看流表项
***s1-------------
NXST_FLOW reply(xid=0x14):
cookie=0x0,duration=90.597s,table=0,n_packets=2,n_bytes=84,idle_timeout=60,idle_age=49,priority=0,arp,in_port=1,vlan_tci=0x0000,dl_src=06:c2:4a:11:6e:e9,dl_dst=72:bc:31:c6:48:21,arp_spa=10.0.0.2,arp_op=2 actions=output:2
//idle_timeout 超时时间
//arp/icmp
//in_port进端口
//arp_spa源地址
//arp_tpa目的地址
Header Fields—Counters—Actions
Header Fields
从上面的例子,显然,流表项的包头域包含了从二层,三层,四层的全部(MAC,IP,PORT)
Counters
只要你能想到的,全都能计数
Actions
Openflow1.3中的流表项
Match Field—Priority—Counters—Instructions —TImeouts—Cookies
Match Field 是原来的包头域的扩展,除了原来的MAC IP PORT,增多了MPLS,IPv6,PBB等
Priority 优先级越高越早结合
Counters 比以前加入了对每组,每个队列,每个动作集的计数
Instructions 相比于之前的actions
? 比1.0版本复杂了好多!
当一个表项的指令集没有包含Goto-Table的时候,流水线处理停止,然后行动集就被执行
Timeouts 流表项的老化时间
Cookies 附属信息
Controller和数据平面如何建立连接
数据平面 hello-> controller
-//超级大的包
<-set config
packet in->//没有flow table的时候递交此包
-port status//数据平面学到新知识之后通知controller
消息种类–一共分成三类(由谁发起来区分)
controller-to-switch controller获取switch状态/指导switch
asynchronous消息 switch将网络事件或者交换机消息更新给控制器
symmetric消息 谁都可以发起
OVS:支持openflow协议的虚拟交换机,与之相对应的是白盒交换机