OpenStack neutron-openvswitch-agent 启动分析

来源:互联网 发布:linux socket 编程 编辑:程序博客网 时间:2024/05/22 06:28

OpenStack neutron-openvswitch-agent 启动分析

注:本文分析采用ml2 openvswitch插件(2016.01.08 update)。
- neutron-openvswitch-agent启动过程
- ovs初始流表分析
- ovs对象类图

neutron-openvswitch-agent启动过程

启动命令:/usr/bin/python /usr/bin/neutron-openvswitch-agent –config-file /etc/neutron/neutron.conf –config-file /etc/neutron/plugins/ml2/ml2_conf.ini

首先看下/usr/bin/neutron-openvswitch-agent文件

neutron-openvswitch-agent

真正的调用neutron的入口代码,其中不同的服务对应不同的启动入口,如agents下的l3,dhcp等。
这里写图片描述

接下来是agent main函数入口:
agent main

此时遇到of_interface配置,有两种选择ovs-ofctl和native,分别对应openflow下面的两个目录入口,如选择ovs-ofctl则进入ovs_ofctl目录下面main文件。
这里写图片描述

最后真正的ovs_neutron_agent开始启动
这里写图片描述

ovs初始流表分析

br-int

def setup_integration_br(self):    '''Setup the integration bridge.    '''    self.int_br.set_agent_uuid_stamp(self.agent_uuid_stamp)    # Ensure the integration bridge is created.    # ovs_lib.OVSBridge.create() will run    #   ovs-vsctl -- --may-exist add-br BRIDGE_NAME    # which does nothing if bridge already exists.    self.int_br.create()    self.int_br.set_secure_mode()    self.int_br.setup_controllers(self.conf)    self.int_br.delete_port(self.conf.OVS.int_peer_patch_port)    if self.conf.AGENT.drop_flows_on_start:        self.int_br.delete_flows()    self.int_br.setup_default_table()def setup_default_table(self):    self.install_normal()    self.setup_canary_table()    self.install_drop(table_id=constants.ARP_SPOOF_TABLE)

br-tun

def setup_default_table(self, patch_int_ofport, arp_responder_enabled):    # Table 0 (default) will sort incoming traffic depending on in_port    with self.deferred() as deferred_br:        deferred_br.add_flow(priority=1,                             in_port=patch_int_ofport,                             actions="resubmit(,%s)" %                             constants.PATCH_LV_TO_TUN)        deferred_br.add_flow(priority=0, actions="drop")        if arp_responder_enabled:            # ARP broadcast-ed request go to the local ARP_RESPONDER            # table to be locally resolved            # REVISIT(yamamoto): add arp_op=arp.ARP_REQUEST matcher?            deferred_br.add_flow(table=constants.PATCH_LV_TO_TUN,                                 priority=1,                                 proto='arp',                                 dl_dst="ff:ff:ff:ff:ff:ff",                                 actions=("resubmit(,%s)" %                                   constants.ARP_RESPONDER))        # PATCH_LV_TO_TUN table will handle packets coming from patch_int        # unicasts go to table UCAST_TO_TUN where remote addresses are        # learnt        deferred_br.add_flow(table=constants.PATCH_LV_TO_TUN,                             priority=0,                             dl_dst="00:00:00:00:00:00/01:00:00:00:00:00",                             actions=("resubmit(,%s)" %                               constants.UCAST_TO_TUN))        # Broadcasts/multicasts go to table FLOOD_TO_TUN that handles        # flooding        deferred_br.add_flow(table=constants.PATCH_LV_TO_TUN,                             priority=0,                             dl_dst="01:00:00:00:00:00/01:00:00:00:00:00",                             actions=("resubmit(,%s)" %                               constants.FLOOD_TO_TUN))        # Tables [tunnel_type]_TUN_TO_LV will set lvid depending on tun_id        # for each tunnel type, and resubmit to table LEARN_FROM_TUN where        # remote mac addresses will be learnt        for tunnel_type in constants.TUNNEL_NETWORK_TYPES:            deferred_br.add_flow(table=constants.TUN_TABLE[tunnel_type],                                 priority=0, actions="drop")        # LEARN_FROM_TUN table will have a single flow using a learn action        # to dynamically set-up flows in UCAST_TO_TUN corresponding to        # remote mac addresses (assumes that lvid has already been set by        # a previous flow)        learned_flow = ("cookie=%(cookie)s,"                        "table=%(table)s,"                        "priority=1,"                        "hard_timeout=300,"                        "NXM_OF_VLAN_TCI[0..11],"                        "NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[],"                        "load:0->NXM_OF_VLAN_TCI[],"                        "load:NXM_NX_TUN_ID[]->NXM_NX_TUN_ID[],"                        "output:NXM_OF_IN_PORT[]" %                        {'cookie': self.agent_uuid_stamp,                         'table': constants.UCAST_TO_TUN})        # Once remote mac addresses are learnt, output packet to patch_int        deferred_br.add_flow(table=constants.LEARN_FROM_TUN,                             priority=1,                             actions="learn(%s),output:%s" %                             (learned_flow, patch_int_ofport))        # Egress unicast will be handled in table UCAST_TO_TUN, where        # remote mac addresses will be learned. For now, just add a        # default flow that will resubmit unknown unicasts to table        #  FLOOD_TO_TUN to treat them as broadcasts/multicasts        deferred_br.add_flow(table=constants.UCAST_TO_TUN,                             priority=0,                             actions="resubmit(,%s)" %                             constants.FLOOD_TO_TUN)        if arp_responder_enabled:            # If none of the ARP entries correspond to the requested IP,            # the broadcast-ed packet is resubmitted to the flooding table            deferred_br.add_flow(table=constants.ARP_RESPONDER,                                 priority=0,                                 actions="resubmit(,%s)" %                                 constants.FLOOD_TO_TUN)    # FLOOD_TO_TUN will handle flooding in tunnels based on lvid,    # for now, add a default drop action    self.install_drop(table_id=constants.FLOOD_TO_TUN)

ovs对象类图

这里写图片描述

这里写图片描述

0 0
原创粉丝点击