精华内容
下载资源
问答
  • Openstack Neutron 集成 SDN控制器

    千次阅读 2017-04-28 18:25:23
    Neutron 集成SDN控制器   一.Neutron的组成元素   Neutron-server可以理解为一个专门用来接收Neutron REST API调用的服务器,然后负责将不同的REST API分发到不同的neutron-plugin上。   Neutron-plugin...

    Neutron 集成SDN控制器

     

    一.Neutron的组成元素

     

    Neutron-server可以理解为一个专门用来接收Neutron REST API调用的服务器,然后负责将不同的REST API分发到不同的neutron-plugin上。

     

    Neutron-plugin可以理解为不同网络功能实现的入口,各个厂商可以开发自己的plugin。Neutron-plugin接收neutron-server分发过来的REST API,向neutron database完成一些信息的注册,然后将具体要执行的业务操作和参数通知给自身对应的neutron agent。

     

    Neutron-agent可以直观地理解为neutron-plugin在设备上的代理,接收相应的neutron-plugin通知的业务操作和参数,并转换为具体的设备级操作,以指导设备的动作。当设备本地发生问题时,neutron-agent会将情况通知给neutron-plugin。

     

    Neutron database  就是Neutron的数据库,一些业务相关的参数都存在这里

     

    Network provider  即为实际执行功能的网络设备,一般为虚拟交换机(OVS或者Linux Bridge)。

     

     

    二.Neutron-plugin说明
    Plugin, agents和neutron-server一起管理虚拟交换机,Plugin, agents依赖Neutron。Plugin分为core和additional,用来处理neutronserver传过来的请求

    Agent跑在compute节点之上,与neutron的plugin进行通信

     

    ML2 的plugin都是属于core。分为type和mechanism两种。Type drivers (如flat, VLAN, GRE 和VXLAN) 定义 L2 type。mechanism drivers (如OVS, ODL, Cisco, NEC, etc) 负责一系列动作(更新、创建、删除)网络、子网、端口。

     

     

    Neutron可以通过ML2插件和ODL北向接口融合,ODL通过OVSDB南向插件管理OpenStack计算节点中的网络流。

     

    . OpenDaylight(ODL)介绍

    OpenDaylight是一套以社区为主导的开源SDN框架,旨在推动创新实施以SDN透明化。面对SDN型 网络,需要合适的工具管理基础设施,这正是OpenDaylight的专长。

    OpenDaylight Controller作为项目核心,拥有一套模块化、可插拔且极为灵活的控制器,这使其能够被部署在任何支持Java的平台之上。这款控制器中还包含一套模块合集,能够执行需要快速完成的网络任务。

    OpenDaylight Controller提供了一个模块化的开放SDN控制器,它提供了开放的北向 API(开放给应用的接口),同时南向支持多种包括openflow在内的多种SDN协议。底层支持混合模式的交换机和经典的Openflow交换机

     

    ODL安装:

    http://www.sdnlab.com/17984.html

     

    在neutron旧版本里

    opendaylight作为ml2drivers 存在于neutron项目中,在neutron较新的版本中一些sdn plugin,已开始从目中移除,一命名为诸networking-xxxx的独立目。

     

    .OpenStack和OpenDaylight(ODL)的集成

    Neutron包含ML2机制驱动,该机制驱动(ODL)作为REST代理能够调用所有的NeutronAPI。ODL包含北向REST服务(Neutron API服务),能够调用这些代理API缓存数据并可用于ODL的其他服务,这些RESTful API可以完成OpenStack和ODL的绑定。OpenDaylight与Openstack集成主要依赖ML2 plugin.

     

     

    ODL和OpenStack集成步骤如下:

    1、在虚拟机或者物理机上构建和安装合适的ODL版本。

    2、正确配置并启动ODL

    3、部署OpenStack

    4、配置OpenStack,为ODL和Openstack的集成做准备:

    * 确保核心插件在ML2

    配置/etc/neutron/neutron.conf

    [DEFAULT]
    core_plugin=neutron.plugins.ml2.plugin.Ml2Plugin

    * 获取networking-odl

                   sudo pip install networking-odl

     * 将ODL作为”mechanism_drivers”添加到ML2上

                配置/etc/neutron/plugins/ml2/ml2_conf.ini

                修改mechanism_drivers = openvswitch为     

                mechanism_drivers= opendaylight

     

     * 配置ml2_conf.ini文件的[ml2_odl]区域:

    [ml2_odl]
    username=<ODL_USERNAME>
    password=<ODL_PASSWORD>
    url=http://<ODL_IP_ADDRESS>:<ODL_PORT>/controller/nb/v2/neutron
    port_binding_controller=pseudo-agentdb-binding

     * 重置Neutron’s database

    mysql -e "DROP DATABASE IF EXISTS neutron;"
    mysql -e "CREATE DATABASE neutron CHARACTER SET utf8;"
    /usr/local/bin/neutron-db-manage --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugins/ml2/ml2_conf.ini upgrade head

     

    * 重启 neutron-server:

    systemctl start neutron-server

     

    5、配置ovs虚拟交换机使用ODL

    # ovs-vsctl set-manager tcp:${ODL_IP_ADDRESS}:6640

    6、设置节点OVS configurations

    # sudo neutron-odl-ovs-hostconfig

    7、检测OVS服务是否正常

    # ovs-vsctl show

     

    8、在OpenStack构建虚拟网络

    9、验证ODL界面生成的网络拓扑是否与想要的一致

     

    参考文档:https://docs.openstack.org/developer/networking-odl/installation.html

     

    .OpenStack和OVN的集成

    OVNOpenvSwitch项目组为OpenvSwitchSDN控制器,同其他SDN产品相比,OVNOpenvSwitch OpenStack有更好的兼容性和性能。

     

    OVS OVN 是非常简单快捷的。原有的网、路由等数据不会失,也不需要对这些数据出来行数据迁移,只需要添加一个 plugin 来配置 OVN 即可

     

     

    OVN的优点如下:

    1.    OVN使得Neutron组件数量减

    OVNML2 driver OVS ML2 driver NeutronOVS agentOVN原生支持L3DHCP功能,这样就不再需要Neutron L3 agent DHCP agent DVR

    2. OVN提供了多原生的虚功能,提升了OVS的工作效率和性能

    3. OVN 支持原生的三功能,不需要借助 Linux TCP/IP stack,用OpenFlow 流表来实现路由找,ARP 查找,TTL MAC 地址的更改。

    4.OVN里面数据的写都是通 OVSDB来做的,取代了 Neutron 的消息列机制,所以有了 OVN 之后,理Neutron 里面所有的 agent 都不需要了,Neutron 变成了一个 API server 理用 REST 请求,其他的功能都交给 OVN 来做,只需要在 Neutron 里面加一个 plugin 用配置 OVN

     

    集成文档:https://docs.openstack.org/developer/networking-ovn/install.html

     

    展开全文
  • neutronSDN简单测试

    2019-10-02 12:59:12
    title: Neutron SDN 手动实现手册 date: 2017-04-13 23:37 tags: Network 本文旨在通过自己搭建类似neutron (openvswitch + gre) 实现SDN 的环境,学习了解其工作原理,模拟核心原理,比如:同一租户自定义网络...

    title: Neutron SDN 手动实现手册 date: 2017-04-13 23:37 tags: Network


    本文旨在通过自己搭建类似neutron (openvswitch + gre) 实现SDN 的环境,学习了解其工作原理,模拟核心原理,比如:同一租户自定义网络 instance 互通,手动为instance 分配 floating ip 等相关内容。

    ![image](E:\公司资料\github page\hexo\source_posts\文档图片\手工SDN1.png)

    ###主机网卡配置

    controller:
    	     eth0:10.20.0.201   (management network)
    	     eht1:172.16.0.201 (public/external network) eht2:192.168.4.201 (private network,gre tunning) compute01: eth0:10.20.0.202 (management network) eht1:(disabled) eht2:192.168.4.202 (private network,gre tunning)

    ##模拟安装网络节点(Network1)

    模拟Network 节点相关实现,比如L3、dhcp-agent实现,为了模拟多节点网络情况,这里Network同时也模拟一个计算节点,模拟M2 openvswitch 实现,上面运行instance1。

    网络接口配置

    vi /etc/sysconfig/network-scripts/ifcfg-eth0
    	DEVICE=eth0
    	TYPE=Ethernet
    	ONBOOT=yes
    	NM_CONTROLLED=yes
    	BOOTPROTO=static
    	IPADDR=10.20.0.201
    	NETMASK=255.255.255.0 vi /etc/sysconfig/network-scripts/ifcfg-eth1 DEVICE=eth1 TYPE=Ethernet ONBOOT=yes NM_CONTROLLED=yes BOOTPROTO=static IPADDR=172.16.0.201 NETMASK=255.255.255.0 vi /etc/sysconfig/network-scripts/ifcfg-eth2 DEVICE=eth2 TYPE=Ethernet ONBOOT=yes NM_CONTROLLED=yes BOOTPROTO=static IPADDR=192.168.4.201 NETMASK=255.255.255.0

    重启网络服务

    service network restart

    安装需要用到的包

    yum install libvirt openvswitch python-virtinst xauth tigervnc qemu-* -y

    移除默认的libvirt 网络,方便清晰分析网络情况

    virsh net-destroy default
    virsh net-autostart --disable default virsh net-undefine default

    设置允许ipforwarding

    vi /etc/sysctl.conf 
    	net.ipv4.ip_forward=1
    	net.ipv4.conf.all.rp_filter=0 net.ipv4.conf.default.rp_filter=0

    立即生效

    sysctl -p

    启动openvswitch

    service openvswitch start
    chkconfig openvswitch on

    创建一个linux bridge

    brctl addbr qbr01
    ip link set qbr01 up

    创建一个instance,并连接到qbr01 Bridge,网络接口部分配置如下

    <interface type='bridge'>
    	      <source bridge='qbr01'/> <target dev='tap01'/> <model type='virtio'/> <driver name='qemu'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface>

    可以参考附件./gre/instance1.xml创建

    cp ~/gre/ /var/tmp/
    	cd /var/tmp/gre
    	mv cirros-0.3.0-x86_64-disk.img instance1.img
    	virsh define instance1.xml virsh start instance1 virsh vncdisplay instance1 vncviewer :0

    启动console 以后,登录添加ip 地址 192.168.1.11

    ip addr add 192.168.1.11/24 dev eth0
    route add default gw 192.168.1.1

    创建一个内部bridge br-int, 模拟 OpenStack integrated bridge

    ovs-vsctl add-br br-int
    ovs-vsctl add-port br-int gre0 -- set interface gre0 type=gre options:remote_ip=192.168.4.202

    创建一个veth peer,连接Linux Bridge 'qbr01' 和 OpenvSwich Bridge 'br-ini'

    ip link add qvo01 type veth peer name qvb01
    brctl addif qbr01 qvb01
    ovs-vsctl add-port br-int qvo01
    ovs-vsctl set port qvo01 tag=100
    ip link set qvb01 up
    ip link set qvo01 up

    查看现在network1上的 br-int

    ovs-vsctl show

    ##模拟安装计算节点(compute1)

    ##网络接口配置

    vi /etc/sysconfig/network-scripts/ifcfg-eth0
    	DEVICE=eth0
    	TYPE=Ethernet
    	ONBOOT=yes
    	NM_CONTROLLED=yes
    	BOOTPROTO=static
    	IPADDR=10.20.0.202
    	NETMASK=255.255.255.0 vi /etc/sysconfig/network-scripts/ifcfg-eth1 DEVICE=eth1 TYPE=Ethernet ONBOOT=yes NM_CONTROLLED=yes BOOTPROTO=static IPADDR=172.16.0.202 NETMASK=255.255.255.0 vi /etc/sysconfig/network-scripts/ifcfg-eth2 DEVICE=eth2 TYPE=Ethernet ONBOOT=yes NM_CONTROLLED=yes BOOTPROTO=static IPADDR=192.168.4.202 NETMASK=255.255.255.0

    重启网络服务

    service network restart

    安装需要用到的包

    yum install libvirt openvswitch python-virtinst xauth tigervnc  qemu-*

    移除libvirt 默认的网络

    virsh net-destroy default
    virsh net-autostart --disableu default virsh net-undefine default

    设置允许ipforwarding

    vi /etc/sysctl.conf 
        net.ipv4.ip_forward=1
        net.ipv4.conf.all.rp_filter=0 net.ipv4.conf.default.rp_filter=0

    立即生效

    sysctl -p

    启动openvswitch

    service openvswitch start
    chkconfig openvswitch on

    创建一个linux bridge

    brctl addbr qbr02
    ip link set qbr02 up

    创建一个vm,并连接到qbr02

    <interface type='bridge'>
          <source bridge='qbr02'/> <target dev='tap02'/> <model type='virtio'/> <driver name='qemu'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface>

    上gre目录到compute1 节点,可以参考附件./gre/instance2.xml创建

    cp ~/gre/ /var/tmp/
    cd /var/tmp/gre
    mv cirros-0.3.0-x86_64-disk.img instance2.img
    virsh define instance2.xml virsh start instance2 virsh vncdisplay instance2 vncviewer :0

    启动console 以后,登录添加ip得知 192.168.1.12

    ip addr add 192.168.1.12/24 dev eth0
    route add default gw 192.168.1.1

    创建一个内部bridge br-int, 模拟 OpenStack integrated bridge

    ovs-vsctl add-br br-int
    ovs-vsctl add-port br-int gre0 -- set interface gre0 type=gre options:remote_ip=192.168.4.201

    创建一个veth peer,连接Linux Bridge 'qbr02' 和 OpenvSwich Bridge 'br-ini'

    ip link add qvo02 type veth peer name qvb02
    brctl addif qbr02 qvb02
    ovs-vsctl add-port br-int qvo02
    ovs-vsctl set port qvo02 tag=100
    ip link set qvb02 up
    ip link set qvo02 up

    查看现在network1 上的 br-int

    ovs-vsctl show

    检查是否能连通instance1,在instance2的控制台

    ping 192.168.1.11

    ##通过 Network Namespace 实现租户私有网络互访

    添加一个namespace,dhcp01用于隔离租户网络。

    ip netns add dhcp01

    为私有网络192.168.1.0/24 ,在命名空间dhcp01 中 创建dhcp 服务

    ovs-vsctl add-port br-int tapdhcp01 -- set interface tapdhcp01 type=internal
    ovs-vsctl set port tapdhcp01 tag=100
    ip link set tapdhcp01 netns dhcp01 ip netns exec dhcp01 ip addr add 192.168.1.2/24 dev tapdhcp01 ip netns exec dhcp01 ip link set tapdhcp01 up

    检查网络是否连通,在namespace 访问instance1 和 instance2

    ip netns exec dhcp01 ping 192.168.1.12
    ip netns exec dhcp01 ping 192.168.1.11

    ##通过 Network Namespace 和Iptables 实现L3 router

    ovs-vsctl add-br br-ex

    重新配置eth1 和 br-ex

    vi /etc/sysconfig/network-scripts/ifcfg-eth1
    
    	DEVICE=eth1
    	ONBOOT=yes
    	BOOTPROTO=none
    	PROMISC=yes
    	MTU=1546
    	################################### DEVICE=ens160 TYPE=OVSPort DEVICETYPE=ovs OVS_BRIDGE=br-ex ONBOOT=yes #################################### vi /etc/sysconfig/network-scripts/ifcfg-br-ex DEVICE=br-ex TYPE=Bridge ONBOOT=yes BOOTPROTO=none IPADDR0=172.16.0.201 PREFIX0=24 ####################################### DEVICE=br-ex ONBOOT=yes DEVICETYPE=ovs TYPE=OVSBridge BOOTPROTO=static IPADDR=192.168.2.134 NETMASK=255.255.255.0 GATEWAY=192.168.2.1 DNS1=218.2.2.2 ######################################

    重启启动网络服务

    ovs-vsctl add-port br-ex eth1 && service network restart

    检查网络,配置后是否连通

    ping 172.16.0.201

    添加一个namespace,router01 用于路由和floating ip 分配

    ip netns add router01

    在br-int添加一个接口,作为私有网络192.168.1.0/24的网关

    ovs-vsctl add-port br-int qr01 -- set interface qr01 type=internal ovs-vsctl set port qr01 tag=100 ip link set qr01 netns router01 ip netns exec router01 ip addr add 192.168.1.1/24 dev qr01 ip netns exec router01 ip link set qr01 up ip netns exec router01 ip link set lo up

    在br-ex中添加一个接口,用于私网192.168.1.0/24设置下一跳地址

    ovs-vsctl add-port br-ex qg01 -- set interface qg01  type=internal ip link set qg01 netns router01 ip netns exec router01 ip addr add 172.16.0.100/24 dev qg01 ip netns exec router01 ip link set qg01 up ip netns exec router01 ip link set lo up

    模拟分配floating ip 访问instance1

    为instance1 192.168.1.11 分配floating ip,172.16.0.101

    ip netns exec router01 ip addr add 172.16.0.101/32 dev qg01 
    ip netns exec router01  iptables -t nat -A OUTPUT -d 172.16.0.101/32 -j DNAT --to-destination 192.168.1.11 ip netns exec router01 iptables -t nat -A PREROUTING -d 172.16.0.101/32 -j DNAT --to-destination 192.168.1.11 ip netns exec router01 iptables -t nat -A POSTROUTING -s 192.168.1.11/32 -j SNAT --to-source 172.16.0.101 ip netns exec router01 iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -j SNAT --to-source 172.16.0.100

    测试floating ip

    ping 172.16.0.101

    如果需要清除nat chain

    iptables -t nat -F
    ip netns exec router01 iptables -t nat -A OUTPUT -d 192.168.2.102/32 -j DNAT --to-destination 192.168.10.11 ip netns exec router01 iptables -t nat -A PREROUTING -d 192.168.2.102/32 -j DNAT --to-destination 192.168.10.11 ip netns exec router01 iptables -t nat -A POSTROUTING -s 192.168.10.11/32 -j SNAT --to-source 192.168.2.102 ip netns exec router01 ip addr add 192.168.2.103/32 dev qg01 ip netns exec router01 iptables -t nat -A OUTPUT -d 192.168.2.103/32 -j DNAT --to-destination 192.168.10.11 ip netns exec router01 iptables -t nat -A PREROUTING -d 192.168.2.103/32 -j DNAT --to-destination 192.168.10.11 ip netns exec router01 iptables -t nat -A POSTROUTING -s 192.168.10.11/32 -j SNAT --to-source 192.168.2.103 ip netns exec router01 route add default gw 192.168.2.1 ip netns exec router01 route -n

    转载于:https://www.cnblogs.com/wanstack/p/7650560.html

    展开全文
  • NeutronSDN

    2017-08-01 13:11:00
    对于SDN大家估计都耳熟能详,这里首先讲讲虚拟化网络技术故事,当VM技术出现的时候,存储通过本地存储或远端挂载的形式基本没有太大变化,但是网络技术呈现形式一直不断翻新。 OVS可以说是一个网络虚拟化里一个重量...

    对于SDN大家估计都耳熟能详,这里首先讲讲虚拟化网络技术故事,当VM技术出现的时候,存储通过本地存储或远端挂载的形式基本没有太大变化,但是网络技术呈现形式一直不断翻新。

    OVS可以说是一个网络虚拟化里一个重量级的开源产品级作品,OVS模仿物理交换机设备的工作流程,实现了很多物理交换机当时才支持的许多网络功能,但是每次配置都需要到宿主机里去手工设置,管理员们正在烦恼之时,SDN就像朝阳带来了希望
    就是可以将OVS设置SDN的控制器,然后管理员就可以通过页面点击按钮来调用SDN的北向API来配置和管理多个OVS,这为网络虚拟化管理和配置带来了便捷;这给某些工程师带来了些认识:

    1 软件时代来临了,软件实现的虚拟网元可以取代系统工程师和运维工程师一直摸不透的黑盒子;

    2 SDN的名称Software Defined Network名称更让人理解为软件替代一切的SDX理念,后来衍生到软件定义存储SDS和软件定义数据中心SDDC的概念

    这里说几个虚拟化(存储、计算和网络)的好处:

    1 通过虚拟化,屏蔽底层故障,增加手工干预所需时间,便于运维;

    2 通过一虚多提高资源使用效率,节省成本;

    3 便于集中管理资源,为云计算的服务提供坚实基础支持;

    这里需要提及下,一台物理机虚拟多个虚拟机时虚拟化,多个物理机虚拟一台虚拟机同样是虚拟化。虚拟机和物理机同时被云平台管理也是现阶段很多场景需要的,包括Openstack的组件里有管理虚拟机的Nova和相应管理裸机的Ironic。

    这里澄清下几个概念:SDN提出的时候并没有区分所控制的软件转发层面是虚拟网元还是物理网元,但是从SDN的理念开放的南向接口这项来看,OpenvSwitch这类虚拟网元支持的Openflow协议速度比硬件支持实现肯定要快很多(这里并不是说OVS是第一种SDN里的网元,也不是说SDN里先支持虚拟网元后支持物理网元),多多少少关联了些NFV(Network Function Virtualization)的思想(NFV的理念现在很多被设计为VMaas,SDN结合NFV在部署和网络管理上提供更多的相互支撑)。

    但是SDN的名称和对OVS支持,让系统工程师和运维工程师多多少少会认为SDN就是软件代替硬件网络和SDN就是运维网络的工具;当系统工程师和运维工程师云SDN津津乐道的时候,而此时的网络工程师在做什么哪?理论上讲SDN是属于网络领域的概念,而SDN产生前期的时候绝大多数的网络工程师(到现在还有很多设备商的网络工程师)还是沉浸在数据包转发和网络协议的开发中,几乎对SDN没有什么概念。

    我们现在经常看到各种分享和峰会里,提及SDN应用的很多是互联网公司的运维工程师(需求是网络可视,突破网络协议OSPF/BGP等不可控的约束对网络操作,作为一种运维工具实现可视化网络)和云计算公司的系统工程师(软件实现网络,摆脱理解不了的硬件盒子,使用软交换或白盒交换机实现可控),设备商的网络工程师分享SDN的则相比不是太多。

    个人观点:最懂网络设计的工程师还在于世界上各大设备商公司里,SDN这种新架构的落地要靠他们(当然包括他们从设备商跳槽或创业后后到互联网和云计算公司从事的SDN网络设计落地工作,以及协助集成商落地SDN)。

    做网络开发的对虚拟网元的网络原理都懂,上手代码也会很快;但是没有玩过网络设备的工程师搞网络,对黑盒子都会始终有很多迷惑的认知,这些往往是导致出网络问题的根源,曾经出现过某云平台因为交换机问题导致的云平台故障
    OpenvSwitch现在来说是比较出名的虚拟网元,还有思科的Nexus 1000V,微软的Hyper-v Vswitch,Vmware的VSS/VDS等;OpenvSwitch来讲,相比于硬件交换机,支持的功能逐渐完整,并且已经发布集成Conntrackd的有状态规则(OVN已经实用之来作为Neutron里替代Iptables实现安全组,但最新2.4版本的OVS未发布该特性),这点作为新特性的创新来说是传统硬件交换机支持不了的;

    但是OVS在Egress Pipeline Processing方面支持度还有待进一步增强(Openflow1.5才有这个支持),包括流表对出口的匹配、端口出方向QOS带宽限速、出入方向对BUM报文的抑制等,但是OVS的性能和现在万兆的交换机相比,还相差很远。

    个人观点:所以在虚拟化网络不成熟的今天,需要虚拟交换机这类来不断完善新特性;但是纵观网络发展,包括杀毒硬件、L7交换机等类似产品,以及博通等芯片厂商硬件开始支持端口虚拟化和虚交换机等,网络虚拟化产品最终也应以网络设备的虚拟化来实现为主,从而释放出所占用的服务器 CPU等资源。

    这里再说下传统网络的SDN应对的问题:以前的大规模网络互通是靠路由协议实现路由发布实现数据转发面互通(此时路由协议的交互基本是通过数据转发面来实现即带内),路由协议一旦启用人类很少能主动干预,这种不可控导致了一些问题;

    无法动态为所部署的业务分配所需网络资源(为何以前不能分配所需?因为以前的网络资源还不足够多,现在随着网络设备能力增强带宽只是个数字而已);大象流集中到某些链路导致网络带宽使用率不理想等;大象流超过单链路带宽如果走多路径ECMP会导致接收端服务器对报文重排序非常耗CPU;

    这也是为何单端口带宽一直上升的原因,从千兆到万兆,现在又盛行升级到25G,然后40G/100G,后续还会再增加。

    传统网络还有一些问题:比如各厂家堆叠基本都是各厂家自身产品几个有限型号才能堆叠,这就导致了另一个问题,作为汇聚或核心层设备进行HA的时候,一旦一台设备在某种场景下触发了BUG或问题,另一台同型号设备的话则也会有同样的问题,使得HA失效。

    上面讲了这么多,主要是说SDN出现的一些背景,这里简单说下SDN的概念,SDN主要是说能够将应用和底层网络转发关联起来,让上层应用控制底层数据转发,所以SDN的名称ADN(Application Defined Network) 更符合一些;

    那这就要底层转发网元和管理面做一些相应的改进,SDN有三个特征:控制转发(逻辑)分离 ,开放的(不是开源)的编程接口 ;集中(逻辑)的网络控制。所以SDN的本质个人认为是:
    一种新型的可视化网络设计架构

    • 一种网络资源管理和优化使用方式
    • 一种节约资源降低网络成本的技术
    • 一种体现对网络需求增速变慢的技术体现点

    另外SDN不是:

    • SDN不是网络虚拟化或NFV ,即SDN不是软件实现网络,
    • SDN不是网络设备,包括OVS和白盒交换机
    • SDN不是某种网络协议,包括Openflow(含TTP)
    • SDN不是网络的必须或主宰技术 ,和其他技术一样,需求推动
    • SDN不是纯粹的网络配置工具
    • SDN不是纯粹的网络运维工具
    • SDN不是软件网元替代硬件网元
    • SDN不是提升转发面网元本身性能的工具,只是网络资源使用方式的改变,换句话说SDN只是换了种对网元的使用方式,将其自身的最佳性能得到了发挥;所这点来讲,对于苛求或批判SDN方案(尤其是Neutron结合SDN)提升网元自身转发性能的同学,只能说还不理解SDN或者还不理解网络

    SDN的各向接口:

    • 北向暂时没有标准,各家控制器基本都有自己的接口,这点北向标准还不如Neutron
    • 南向:Openflow,Netconf,BGP、OVSDB及思科的Openflex等等(一款控制器可以同时使用多种南向协议)
    • 东西向:BGP等等(有个SDN东西向的Draft:SDNi,还有篇paper提出了East-west bridge)
    • SDN级联,包括了SDN的南向和东西流流量,暂时未看到标准

    这里着重说下最后一点,Openstack的L版添加了Port的Qos特性API,另外企业网尤其是中小企业的小规模网络会不会从SDN里收益?大家一致的印象是只有大规模设备用SDN才划算,对此个人观点是找到合适的应用场景SDN一样可以让小规模网络收益,包括企业办公网等。

    说完了SDN也顺便聊下NFV,NFV自身是说为了解决当前hardware-based情形下,随着应用更新的加快,硬件跟不上应用需求的步伐,导致硬件设备寿命缩短导致浪费,需要对存储、计算等所需的网络功能进行虚拟化,来加快创新,并节省对硬件设备的投资。

    个人理解,NFV是英特尔等CPU厂商用X86和虚拟化厂商用虚拟化技术进军网络研发领域的一种策略;首先,上层应用对网络所需的特性并没有那么多的个性化定制,尤其是随着先交换机白盒智能化和存储设备的白盒化,应对创新需求只是这些厂商对运营商的单方说辞;其次,无论NFV在运营商的产品化形态如何(VMaas就是一种形态),运营商对网络设备的需求都是不可少的,但NFV对传统网设备商还是有了一定的智能化促;

    最后英特尔等也同时硬件设备领域没有放手,通过收购FM研发硬件交换芯片,并结合X86推出基于FM10000的ServerSwtich,使其网络方面虚拟网元和硬件网元优化一体化解决方案的战略内容之一。所以NFV可谓是“项庄舞剑,意在沛公”,Openstack里也越来越多的NFV特性比如Service chain方面的支持。

    现在来看云计算方面的内容,云计算中大二层需求、网络虚拟导流所用隔离技术包括Vlan Mpls Vxlan Nvgre STT Geneve 等,Vxlan逐渐 成为趋势 ,但OVS 2.4.0版本Geneve支持basic 版本;所以这里抛出一个问题,现有技术的规模还是受限,如何做到隔离域有无限大的可能哪?

    因为现在来看可能IPV6的地址数目128比特和STT在内隔离域数目最多为64bit,但是终将还是个固定值,相对于将来的星球间宇际通信来说,数目还是少的可怜(当然星球间通信是不是以太网或IP还是未知数)。

    然后回到分享开头所提及的虚拟机技术,个人观点现在KVM/XEN/Hyper-v/ESX等都是半虚拟化,实现了VM跨主机的才是真正意义上的虚拟化,虚拟化方面包括现在盛行的Docker 引入的网络管理组件都是仅是用了已有的网络技术,对网络技术的本质创新都没有做出贡献,仅仅是在使用样式上有了翻新;

    但这些确实促进了技术的发展,包括在计算服务器通用后的存储和网络的白盒化,网络方面也促进了服务器网卡虚拟化(SR-IOV等)和交换机的虚拟化(交换芯片的虚拟化和端口hair-pin等特性),服务器网卡收发包方面DPDK的出现也有一定的影响。

    这里才到今天真正的主题里说下Neutron相关的内容,Neutron是什么?

    • Openstack开源社区网络配置管理组件
    • Neutron的网络服务包括L2-L7
    • Neutron只是管理配置VM所用网络
    • Neutron有很多SDN控制器作为plugin

    Neutron的主要功能:L2功能(Port、Subnet、Network、Qos、安全组等)、L3(Router/DVR、DCHP等)、L4-L7(FWaas、LBaas、VPNaas、DNSaas-Designate等)。对应的网络功能底层网元实现来看,Port对应VM挂载的VNIC相应TAP/TUN设备,Subnet只是一个IP Pool的数据集合,Network则要对应分配网络类型和相应隔离域ID,Qos功能可以基于OVS来实现,安全组最初基于linux bridge上的iptables,这种有状态的规则前面也提及现在可以基于OVS来实现了;

    L3上Router实现是通过linux的Namespace,不过Dragonflow则是通过OpenvSwitch的流表,DHCP和DNS服务最初是通过Dnsmasq;L4-L7的服务开源实现方案里,FWaas是通过Router里的Iptables,LBaas是通过Haproxy,VPNaas则是Openswan,当然现在很多设备厂商比如Juniper、思科、华为和F5将L4-L7的底层实现换成了自己的设备。

    Neutron的机制是通过plugin/driver/agent等方式实现不同底层网元实现的集成,plugin里L2-L3称之为core plugin,L4-L7成为service plugin;driver是同一个plugin下替换不同网元实现的方式,而agent是部署在底层网元一侧的相应Driver代理,来对网元转换参数并下发到网元里;

    Dragonflow/OVN是Neutron比较新的Core plugin,不过都想将service plugin也统一起来。Neutron的未来,这里借用下华为同事章宇(sina微博:一棹凌烟)的话说:将来只剩下Neutron的北向API及Neutron server;这点比较赞同;

    Openstack本来只是一个框架,底层实现应该让云平台厂商来定制化。

    Neutron毕竟是份开源代码,现有实现ML2等有比较多的缺点:

    • 过多的臃肿代码,维护和修改比较困难

    这么多plugin,这么多种类plugin,也是醉了

    • 系统工程师思维搞网络,软件才可控

    无法理解和集成硬件是其永远的痛,设备商的加入才走向网络正规

    • 开源实现思路,实现优先,产品化次之

    企业厂商产品化道路多舛,有碍Neutron社区发展

    • 多方利益博弈,规划道路多变

    主张所用技术经常被颠覆,积累容易付诸东流

    Neutron的演进:

    • Nova-network是前身
    • Core plugin完成L2/L3/DHCP等基本功能
    • Service plugin完成L4~L7功能升级
    • DVR等实现系统层次的HA可用
    • Neutron结合SDN实现网络可控为终极形态 ,Neutron有很多SDN控制器作为plugin

    这里提及下DVR,解决同路由下跨网段的三层东西流量卸载 ,减轻集中式网络节点负担 ,因为同网段二层通信本来就不经过网络节点,DVR的实现软硬都可以,并不只有OVS等虚拟网元才能实现。


    作者:北京小武

    来源:51CTO

    展开全文
  • 目录 -SDN现状 -(一)SDN现状 -SDN诞生的背景 -SDN的介绍 -(二)SDN领域的相关组织和发展现状 -1、ONF -2、OpenDaylight -3、IETF -4、ETSI ...SDN现状 ...(一)SDN现状 ...SDN...

     

    目录

    SDN现状

    - (一)SDN现状

        - SDN诞生的背景

        - SDN的介绍

    - (二)SDN领域的相关组织和发展现状

        - 1、ONF

        - 2、OpenDaylight

        - 3、 IETF

        - 4、ETSI

    SDN现状

    (一)SDN现状

    SDN诞生的背景

    SDN技术其实要从更往前一点的技术说起,也就是传统(现在主流)TCP/IP协议,得益于TCP/IP的巨大成功,出现 IP over Everything、Everything over IP,以至于大学时期计算机网络课程的内容的基本上就是围绕着TCP/IP协议在讲。直到SDN的出现。

    那个时候讲网络的典型模型,总是会有一个这样的结构。

     

    图 2

    TCP/IP模型下的网络通信

    基本上就是在讲应用的数据如何一层一层地封装、一层一层的解封装最后传到应用的手中。也都会举那个的著名的邮差的例子,协助理解在这样一个分层的架构中数据的处理过程。在这个过程中,每一层都有每一层的处理机制。三层设备代表着路由器、二层设备代表为交换机。路由的重点在如何选路、如何转发,并就以此展开,各种路由协议之间差异。交换的重点在数据帧的转发、组播、广播、接入的安全。每一层都有每一层任务,每一层都有不同处理规则。而所有不同厂家、不同类型的设备之间都通过标准的协议进行交互。

    而在这种背景下,网络的设计方案也按照设备功能的不同划分出不同的层级。每个层级都由大量专门的硬件设备实现特定的转发任务。交换机负责二层的转发,端口的连接、准入、二层广播。路由器负责与其他网络的连接、选路、NAT等操作。除此之外网络中还存在着大量FW、IPS、IDS等专用硬件设备,执行某一类特定的任务。

    如果有新业务需求需要增加新的流量类型、或者要修改协议的解析方式、则要么更换设备、要么添加新的设备。所以网络功能升级往往都是以年为单位,层级化组网、扁平化组网、新增二层特性等等。设备厂家通过在网络中加入新的设备来推动用户网络的更新换代。

     

    图 3

    08年某网络厂家的数据中心外联区网络设计方案

    这种情况带来的是像思科这样的厂家在一波IT发展的浪潮中迅速崛起。各个厂家争相在自己的设备中加入各种独有的特性,响应使用的需求,同时屏蔽其他的竞争对手。也让思科这样的厂家一时分光无限,赚取巨额的利润。

     

    但是这样的架构带来的问题也非常突出。

    1.传统的网络中同一层面上所有的节点都是平等,需要建立特定(二层、三层)的邻居关系之后在设备之间以广播或者组播的方式传递设备内部的转发表,才能实现基础的互联互通。

    图 4

    这种去中心化的结构中每一台设备都是智能的,保证了网络不会因为单个设备的实效而网络整体失效。但是带来的问题也非常显著。所有交换机和路由器都需要管理和单独配置,大量复杂和重复的工作。这种方式当网络规模小时还能勉强接受,而一旦中型网络中有上百台设备需要配置,而大型网络中有上万台设备需要配置时,维护工作就变得不可接受了。而每当网络中路由信息发生变更的时候,则要迎来整网的收敛,更新的信息要以广播或者组播的方式洪泛全网。当然,通过良好的规划,能够将这一范围控制在尽量小的范围内。但是协议交互带来的效率低下的问题无法解决,想要灵活地实现网络的调整,几乎完全不现实。

     

    有一些网络管理软件的厂家也宣称能够极大地简化这一工作量,一定程度上实现设备的自动发现、配置批量下发。此类软件往往通过标准的snmp、或者是telnet、ssh,通过模块化的配置管理命令和文件实现管理功能。在面临多个厂家、多个种类型的设备混合组网的情况下,效果往往要打折扣,因为硬件厂家的相对封闭,基本很难完全获取所有设备的配置和状态信息。更别提自动实现流量选路优化、路由变更、地址池增删等自动化的管理功能。

     

    图 5

    某网管软件的网络设备管理功能

    不同厂家的之间CLI配置命令不同,甚至同一厂家,不同软件版本之间的配置都有差异。网管提供的信息也不同。想弥补这之间的差异,要靠大量的人力和经验。

    除此之外,还有一个非常突出的问题是,在一个大型的网路中,用户很难对网络中流量的走向、流量的类型有一个直观的认知。网管人员很难知道其关心的数据究竟是怎么在网络中穿梭的,只能靠假设和尽量减少路由的复杂程度,对路由信息进行削减。这直接导致网络故障难以定位,逐步排查问题非常困难,费时费力。

     

    2.传统设备为了满足转发性能的需求,大量的功能(例如二层、三层数据包的处理、加密解密等)都是直接通过硬件芯片来完成。这样能设计出转发性能非常强劲,而且延迟非常低的网络设备。但是ASIC芯片的功能出厂之后就已经被固定了。想要加入新的功能、新的业务只能重新设计芯片,一般ASIC从设计、定型整个生命周期为5-10年,想设计一块新的ASIC芯片快一点也至少需要2年。这中间新的业务需求都只能憋着。

     

    图 6

    理解CPU与ASIC的关系,对理解交换机的控制和数据层面非常有帮助,国外有一篇博客写得很通俗易懂。提炼出来就是:

    图 7

    • ASIC芯片收到包之后,会先读取二层帧中的以太网类型字段,从而得出包的类型,不同类型的包通过不同的协议进行解析。如:arp、IPv4、IPv6、IPX等。
    • 如果遇到诸如以太网类型为0x0800(IPv4数据包)、目的地址为路由器的地址或者组播地址(如:224.0.0.5)的数据包时,ASIC芯片会将数据包通过内部的PCIe总线转发给CPU,CPU再对数据包进行处理。
    • 这个时候CPU会根据包中的信息进行相应的操作,如:更新路由表、ARP表、回应报文等。回应的报文也同样再通过ASIC芯片转发出去。
    • 如果是一般的数据包,需要通过三层或者二层转发去目的地时,则ASIC芯片会直接通过查询路由表、MAC地址表然后从交换机上相应的端口转发出去。
    • 整个过程中CPU充当交换机的大脑,也就是传统交换机的控制层面,用来运行内置的各种复杂的协议和功能。而ASIC则是根据已知的规则执行转发操作,充当的是交换机内部的数据层面。

    当然,详细展开的话的,其实还有很多内容,包括用来各种表所用的内存的类型、协议的识别等。但其实理解了这个之后,对了解SDN控制和数据层面的分离就很容易了。

    博客原文地址如下,有兴趣的可以去看看 :

    http://thenetworksherpa.com/data-control-plane-separation-sortof/

     

    3.厂家对用户的锁定

    虽然标准的TCP/IP、OSPF、spanning-tree 等能够满足一般网络最基本的通讯需求,实现各个厂家的设备互联互通。看似一片和谐、非常开放。但额外的功能的都是要付钱的而且很容易被厂家绑定。比如:思科将交换机和路由器内部软件的版本分为lan base、ip base、ip service、Advance IP service等,不同的版本支持的功能特性又不同,如lan base仅支持基本的二层转发的功能,连静态路由都不支持,而ip base版本支持一些基本常用的路由协议如rip,igrp等,而ip service版本则支持cisco拥有的全部路由协议如ospf,eigrp,IS-IS等。

    图 8

    这一块隐性的开销容易被忽视

    除此之外,还有支持语音的IP voice、支持安全特性的security等等版本的软件。如果一个企业几个分支之间需要通过隧道互联,而且企业内部有一些话机需要路由器作为小型的语音的网关的话,则需要付出昂贵的license费用,并且各个分支都必须要用到同一厂家的设备。特别是有一个细节是,在相当长的一段时间内,使用思科路由器的VPN一类安全加密功能时,不能选使用诸如:AES128、AES256之类的加密算法,只能使用加密性较差的DES。当时我还一度以为是配置错误,后来才了解到是因为美国对中国的出口技术限制,导致在中国公开销售的ios内将这一部分的功能屏蔽,即使有钱也无法使用。这还是只是整个IT行业的冰山一角,由此可以知道,传统的网络厂家,在保证技术优势的情况下,给终端用户带来的极大的不便和高昂的成本。

    这种为新功能、兼容性买单的现象对于有及大量设备采购需求的运营商来说尤为突出。

     

    SDN的介绍

    所以当最开始openflow协议想要建立一种标准的设备的控制协议时,立即获得大家的亲睐,特别是深受其苦的运营商。

    SDN的理念很简单,核心是:1、控制层面和数据层面的分离,实现集中化的控制;2、开放的可编程接口,以灵活实现业务需求;3、实现网络配置和管理的自动化。

    在一个典型的SDN架构中,通常包含以下角色:

    图 9

    网络设备:既包括了传统网络厂家的交换机、路由器(如:ciscohuaweijuniper等),也包括了各种软件的插件(如:linux bridgeovsdvr等),这些设备依旧承担流量的转发工作。

    控制器:这是SDN的精髓了,传统设备的控制层面的功能全部被集中到了控制器,每一个网络设备不再单独运行各种协议、计算路径等,只需要接收控制器下发转表和配置。控制器用来与网络设备通信的协议,则被称为南向协议,包括:openflowOF-CONFIGPOFOVS DBsnmp等,主要用于将网络设备运行所需要的各种配置下发给网络设备。基于控制器的功能开发的各种上层应用,则是通过北向接口与控制器进行通信。

    应用:可以是网络管理软件、也可以说各种业务系统、编排等。

    这很好的解决了上面的问题:

    1、所有的设备可以通过南向协议进行统一配置,底层的差异被抹去。

    2、新的业务需要新的协议或者处理方式,可通过开放的编程接口灵活实现

    3、底层的差异被抹掉后,厂家无法再控制用户,用户咸鱼翻身。

     

    由此可以看出,SDN并不是说的不要物理设备了,也不是一单纯的部署一个neutron或者ODL控制器.其核心的理念是:业务通过网络开放的接口来实现全网的统一控制,最终实现网络配合业务的敏捷和高自动化。其上面的业务可以有很多种,可以是网络直播、可以是自动选路、也可以是双十一开始前的自动巡检。其下的设备也可以包括传统的路由器、Openflow交换机、OpenvSwitch等。而很多SDN的厂家都在中间搞事情。

     

    (二)SDN领域的相关组织和发展现状

    1、ONF

    开放网络基金会(Open Networking Foundation)2011年由 德国电信, Facebook, Google, Microsoft, Verizon, 和 Yahoo!创立,这其中绝大多数的成员都是用户单位。ONF主要工作就是制定了openflow、OF-Config这两个的用于SDN控制器和网络设备之间通信的标准协议。SDN控制器使用openflow协议可以直接向转发设备推送转发规则,使得全网的设备都能具备可编程性以能够及时响应业务的需求。由此也可以看出ONF组织把重点放在了控制平面与数据平面之间的交互上。除此之外,ONF组织还通过技术顾问组和芯片厂商顾问委员会来推动SDN相关的标准交换机和芯片的发展。

    这些都与ONF的目标息息相关,该组织的核心诉求可以用一句话来概括:通过推动SDN标准的落地,来实现使用“标准”的协议在“标准”的硬件上,通过编程接口实现各种网络的功能,最终摆脱硬件厂家的束缚(重点)。这里面标准的协议就是openflow,标准交换机即良好支持sdn的白牌交换机。其中白牌交换机的核心即使其中的SDN芯片,其要求具备超高的转发性能,同时可编程,这是传统的ASIC芯片和np芯片都无法同时满足的要求。

     

    如果这一目标最终成真,将彻底地改变计算机网络这一行业。那么任意厂家生产的白牌交换机都将能完全满足这些大型用户的使用需求,传统网络厂家这么多年建立起来竞争壁垒将不复存在,这也是这些企业大力推进SDN标准化的原因之一。当然这也绝对是传统的网络设备厂家(如,思科、juniper等)愿意见到的,并直接导致了ODL这一组织的崛起。

     

    图 11

    ONF组织主要支持的ONOS是一个开源的SDN控制器平台,

    “而获得ONF支持的ONOS(开放网络操作系统)则被运营商们寄予众望。ONOS,是由最早创造发明SDN技术的斯坦福、伯克利等知名大学联合运营商、设备制造商发起的非营利性开源社区组织,其目标是创建一个运营商级的开源SDN网络操作系统,满足运营商网络迁移到SDN的需求。有分析师指出,很多运营商愿意接受ONOS,因为它可以为运营商提供敏捷和灵活性,并且有可能使其摆脱设备供应商的束缚。”

     

    2、OpenDaylight

    网络行业的巨头们自然不会愿意看到ONF在SDN领域一统江湖,那他们将在行业内变得毫无话语权,最终沦为低附加值的代工工厂,但是又无法逆SDN的潮流而行。因此另起炉灶建立了另一个开源的SDN项目:ODL(Open Daylight)。与ONF不同,OpenDaylight是由思科和IBM 联合其合作伙伴建立。其初创成员包括:微软、博科、思科、思杰、戴尔、爱立信、富士通、IBM、英特尔、瞻博网络、微软、NEC、惠普、红帽和VMware等。我们可以看到这些成员都是设备供应商。这其中一个重要角色就是思科,思科不仅占据着组织重要的话语权,并且因为在控制器中强行加入思科自己控制器的代码而与Big switch产生分歧,最终直接导致Big switch这一曾经ODL组织的铂金会员的退出。

    ODL的诉求是尽量在现有交换机设备的基础上,实现网络控制和转发层面的分离,以及网络功能的接口化和可编程化。所以在ODL的架构中,SDN控制器的南向协议不仅支持了标准的openflow协议,还包括其他协议以及部分厂家的专用接口等。各个厂家也都在自己的交换机中加入有自己特色的东西,而非纯的openflow实现。

    因此ODL架构在保留底层硬件设备复杂性的同时,尽可能地将网络功能抽象成网络应用的接口,供用户使用,而不需用户去关心底层复杂的配置。

    ODL组织也在积极推动着SDN技术的快速发展,其因为有各大厂家的强力加持,发展速度非常的快,几乎3个月就能推出一个新的版本。

     

    图 12

    ODL拥有一套模块化、可插拔灵活地控制平台作为核心,这个控制平台基于Java开发,理论上可以运行在任何支持Java的平台上,其官方文档推荐的最佳运行环境是最新的Linux(Ubuntu 12.04+)及JVM1.7+。

    ODL控制平台引入了SAL,SAL北向连接功能模块,以插件的形式为之提供底层设备服务,南向连接多种协议,屏蔽不同协议的差异性,为上层功能模块提供一致性服务,使得上层模块与下层模块之间的调用相互隔离。SAL可自动适配底层不同设备,使开发者专注于业务应用的开发。

    类似淘宝这样地超大型网络,也花费了大量的精力在底层设备的适配上。不同厂家、不同设备、甚至不同软件版本都有着配置的差异。这其中涉及到ovsdb、openflow、OF-Config、snmp、SSH、CLI等等。只有花费大量的经历完成底层操作可行后,才能实现底层设备的抽象化。业务的调整、上线不需要关心底层的差异。并最终实现网络的自动化运维、管理。

    这些工作对于一般小的企业来说基本等于不可能,甚至对于一些运营商来说都难以实现。这也是为什么当前ODL稳定性差,BUG较多的原因之一。如今各个核心的网络厂家都参与进来之后,从源头开始解决这一问题后,情况也许能够有改观,但是这里面的坑不是一时半会能够填完的。

     

    图 13

    ONF和ODL之间的争锋,其实代表了两种SDN思路之间的对抗,究竟会谁胜谁败现在还很难说。ONF强调统一的协议和统一的硬件,消除专用的系统和设备,开放网络能力平台,是理想情况下SDN该有的形态。而现实是各个网络厂家们明显会押注在ODL上,缺少传统硬件厂家的支持,ONF能够发展到什么地步还不清楚。从架构上来说,一旦openflow从标准到技术到设备完全普及之后,显然ONF的架构将比ODL这种解决方案的架构更加优秀。但是目前看来未来一段时间内主流的解决方案将是ODL。

     

    3、 IETF

    IETF是互联网工程任务组(Internet Engineering Task Force)的简写。IETF成立于1985年年底,是全球互联网最具权威的技术标准化组织,主要任务是负责互联网相关技术规范的研发和制定,当前绝大多数国际互联网技术标准出自IETF。

    早在SDN提出之前,IETF就对很多类似SDN的方法和技术进行了探索研究,与ONF相比较,IETF的相关工作更多的是由网络设备厂商主导,聚焦于SDN相关功能和技术如何在网络中实现的细节上。

    在IETF第85次会议上召开了IRS BoF会议,关于IRS问题的描述、需求、应用场景和架构模型等方向的草案文稿已超过10篇,会议讨论同意成立IRS WG,并将研究组命名为I2RS(Interface to the Routing System)。I2RS的研究草案提出的支持的SDN体系架构如图7-3所示。

    I2RS主张在现有的网络层协议基础上,增加插件(plug-in),并在网络与应用层之间增加SDN Orchestrator进行能力开放的封装,而不是直接采用OpenFlow进行能力开放,目的是尽量保留和重用现有的各种路由协议和IP网络技术。I2RS的路由系统需要发布网络拓扑和状态,通过网络元数据进行计算选路,并将相关结果传递给各设备的控制平面。I2RS接口的使用者可能是管理应用、网络控制器或者对网络定制的用户应用,目前I2RS工作组还没有形成RFC和工作组文稿。

    4、ETSI

    2012年10月,AT&T、英国电信BT、德国电信、Orange等7家运营商在欧洲电信标准协会(ETSI)发起成立了一个新的网络功能虚拟化标准工作组NFV ISG(Network Functions Virtualisation Industry Specification Group),目前已有52家网络运营商、电信设备供应商、IT设备供应商,以及技术供应商参加。

    NFV的研究和标准化进度分两个阶段,2013年为第一阶段,主要是定义针对部分网络的功能虚拟化标准,如IMS和EPC核心网络,并从基本网络功能、网络设备的虚拟化开始着手。NFV的第一次会议于2013年1月15日至17日召开,这次会议明确了NFV的工作目标是制定支持虚拟功能硬件和软件基础设施的要求和架构规范,以及发展网络功能的指南,第一批规范将于2013年年底前完成。第二个阶段到2014年年底结束,将涵盖所有的核心网和接入网络中网元的功能虚拟化标准。

    ETSI NFV的重点是网络功能的虚拟化,并且在架构中体现了更多的运营商的思路,包括在南向协议中加入了ForCES、PCE-P等协议。

     

    http://www.c-fol.net/news/content/31/201604/20160428083652.html

    http://www.sdnlab.com/3991.html

    中国电信CTNet-2025网络架构白皮书

    转载于:https://www.cnblogs.com/pmyewei/p/6262441.html

    展开全文
  • 摘要:Neutron是OpenStack提供网络服务的专用组件,虽然目前其功能已相对比较完备,但还存在一些不足之处,需要结合SDN架构来解决部分网络部署难题。本文分享了相应的实践思路。 编者按:Neutron是OpenStack提供...
  • 这里面有个canvans 画图的js 代码。有意思,研究一下。 Neutron 介绍:...Neutron本身不是SDN架构,但是不妨碍其结合其他技术成为SDN的架构,包括现在新的...
  • 为什么说Neutron不是SDN

    千次阅读 2015-03-07 15:49:33
    作者:SDN qq群#北京-小武,微博@北京-小武  个人博客: ... ...@盛科张卫峰 卫峰总新作《SDN及云计算平台中的网络性能优化》这篇文章写的很有深度,其中将Neutron中的部分组件来用硬件实现,以提
  • 本文先介绍一下VLAN Trunk的基本概念,以及OpenStack Neutron和OpenFlow based SDN是如何为Trunk port提供网络支持。OpenStack对VLAN Trunk的支持具体是什么?
  • OpenStack Neutron SDN 实现详解
  • Neutron SDN实现技术图解.pdf
  • neutron SDN的实现

    2014-08-04 16:08:17
    neutron SDN的实现¶ 预先了解¶ 在了解整个SDN机制前,我们需要了解一点基础知识,以便能够深入掌握neutron SDN的实现原理。 NameSpaceVlan & GRE物理网络拓扑 NameSpaces¶
  • SDN原理图二 计算节点网络三 TAP设备的使用四 VETH的使用(Virtual Ethernet Pair)五 Linux Bridge的使用六 Open vSwith的使用七 SDN数据流八 计算节点实战1 查看虚拟机2 通过virsh edit 4 查看该虚拟机...
  • 本文旨在通过自己搭建类似neutron (openvswitch + gre) 实现SDN 的环境,学习了解其工作原理,模拟核心原理,比如:同一租户自定义网络 instance 互通,手动为instance 分配 floating ip 等相关内容。 <ignore...
  • 首先,向大家科普下Kubernetes所选择的CNI网络接口,简单介绍下网络实现的背景。 CNI即Container Network Interface,是一套容器网络的定义规范,包括方法规范、参数...CNI实现外界的交互都通过进程参数和环境...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 1,526
精华内容 610
关键字:

neutron与sdn