札记-ryu l3 switch & mapreduce

简单记录下今天看到和思考的一些内容：

Part 1

今天阅读了beikejinmiao的两篇博客，分别为

Ryu控制器官方应用simple_switch_13.py解读，Ryu控制器官方应用simple_switch_13.py解读2。

通过作者的博客，加深了对OF下简单交换机的实现原理，同时与作者一同对他提出的两个问题做了思考

1. 为什么要有3次Packet-in事件？可以的话应该只要1次；

2. 为什么simple_switch_13.py代码中下发的流表项有两个匹配项：in_port，eth_dst？只使用 eth_dst可以么；

先考虑问题1，如果控制器在收到arp request触发的packet-in包时，立刻下发流表项告诉交换机，“发往主机1的包从端口1转发出去“，那么当主机2发出arp reply的回复时，此时交换机会根据流表项直接转发包，而不再向控制器询问（此时控制器没有记录到主机2的mac to port映射，交换机也没有处理发往主机2的包的流表项）。于是当主机1再次发送包（如ICMP请求，ping主机2）时，交换机还是会将它上交给控制器作处理，按照作者修改后的代码（只对广播包泛洪），接下来是无法处理的（ping自然不通）。

我在想，是否有以下实现的可能，控制器对ICMP请求也进行泛洪，主机2收到并回复，虽然这个回复又一次直接被交换机转发给主机1，那么至少应该是ping通的，时延会很长，而且以后每一次发往主机2的包都还是要通过packet-in发给交换机作处理；这个想法可以通过实验作验证，未完...........

再考虑问题2，其关键之处和问题1相近，即交换机始终无法获得处理发往h3的包的流表项，于是每次都是上交给控制器去处理，这也是作者留下的思考题；以下控制器代码转自上述博客：

def _packet_in_handler(self, ev):
msg = ev.msg
datapath = msg.datapath
ofproto = datapath.ofproto
parser = datapath.ofproto_parser
in_port = msg.match['in_port']

pkt = packet.Packet(msg.data)
eth = pkt.get_protocols(ethernet.ethernet)[0]

dst = eth.dst
src = eth.src

dpid = datapath.id
self.mac_to_port.setdefault(dpid, {})

self.logger.info("packet in %s %s %s %s", dpid, src, dst, in_port)

self.mac_to_port[dpid][src] = in_port

if dst in self.mac_to_port[dpid]:
out_port = self.mac_to_port[dpid][dst]
else:
out_port = ofproto.OFPP_FLOOD

actions = [parser.OFPActionOutput(out_port)]

if out_port != ofproto.OFPP_FLOOD:
# 修改处
# match = parser.OFPMatch(in_port=in_port, eth_dst=dst)
match = parser.OFPMatch(eth_dst=dst)
self.add_flow(datapath, 1, match, actions)

data = None
if msg.buffer_id == ofproto.OFP_NO_BUFFER:
data = msg.data

out = parser.OFPPacketOut(datapath=datapath, buffer_id=msg.buffer_id,
in_port=in_port, actions=actions, data=data)
datapath.send_msg(out)

首先，要注意的是，原作者修改代码使得流表项只对eth_dst作匹配；

在h1 ping h2的过程中，交换机分别添加了目的地为主机1、主机2的包处理的流表项；

接着(1).h1 ping h3时，arp request作为广播包，正常地交给控制器处理，控制器更新h1的mac to port，但在映射表中没有h3的mac to port，于是out_port为泛洪，而arp reply是单播的，在交换机中匹配了eth_dst为h1（这里不要求对in_port作匹配）的流表项，直接转发给h1，不给控制器处理、记录h3的mac to port的机会，所以控制器始终得不到h3的mac to port记录，也就无法下发处理发往h3的包的流表项给交换机；

如果接着的是(2).h3 ping h1，arp request同样正常上交给控制器，这时控制器可以记录h3的mac to port，而arp reply由于交换机没有处理发往h3的包的流表项，被上交给控制器，控制器发现已经存储了目的地的mac to port映射，于是就下发了流表项，该流表项就是处理发往h3的包。

这就导致了查看流表项时，(1)比(2)少了一条处理到h3(00:00:00:00:00:03)数据包的流表项。

思考：

这两天一直被问题2困扰，最后能够相通是因为回顾了基础知识点--ARP，“ARP请求分组是广播发送的，ARP响应分组是普通的单播，即从一个源地址发送到一个目的地址”，被请求的对象一方面会回复一个ARP响应分组，另一方面也会在自己的ARP缓存中记录下请求方的地址映射。

Part 2

"用通俗易懂的大白话讲解Map/Reduce原理", 做一个爱分享的人, http://blog.csdn.net/lifuxiangcaohui/article/details/22675437
作者以用多种材料制作不同口味辣椒酱为例，形象地解释了MapReduce的原理，

从每种材料中取出一定量，是Map映射的过程，

将它们合在一起进行搅拌，是Reduce归约的过程。

之前常常看到MapReduce，正好今天又在数据中心对网络性能的要求中看到，就稍作了解

"大缓存：对于Map-reduce业务涉及到的同时存在多个节点往一个节点打流 的情况，要求网络设备有足够的缓存，如果缓存太小的话很容易丢包，需要的缓存大小：Buffer=Burst*(1-1/N) //N是收敛比

例如Map-reduce存在10台服务器打一台服务器的情况，收敛比是10，如果每台服务器瞬间突发1MB(1000个1KB字长的报文）的流量，在此期间堵塞口必须要有9MB的缓存来保证业务不丢包，10*1M*(1-1/10)=9M。"

-- 数据中心网络浅析，作者为H3C研发， http://www.newsmth.net/nForum/#!article/CloudComputing/13814?au=coo8
其中，收敛比的概念也引起了我的注意，收敛比=下行带宽/上行带宽，“对于通讯密集型的网络任何一级网络的上下行带宽尽可能接近1:1，这样没有收敛对于数据中心的高吞吐量是非常有必要的，同时减少网络阻塞。“