Openstack节点网卡连Cisco交换机出现环路的处理

前一阵子部署了两台Openstack的计算节点,奇怪的是每隔一段时间连管理网的网卡eth0灯不亮,交换机上对应的19端口灯变橙色,登陆上去一看,eth0显示:

运行ip link set eth0 up无效。 登陆交换机,查看端口状态:

可以看到19端口出现问题,继续看日志

发现原来是出现了环路,参考cisco的官方文档,一个可能的原因是交换机定时发送keepalive,这个数据包进入节点后又出来,到了同一个端口,则交换机认为可能出现环路,从而禁用。 解决办法是禁用keepalive:

当然也可以升级到高版本的IOS,默认会禁用keeplive。 然后恢复出错的端口:

过了300秒后,端口应该恢复正常,此时能够连接上主机了。 我觉得也可以在节点侧,在连接eth0的ovs桥br0加stp,以观后效

参考文章 Cisco交换机命令行配置(http://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus5000/sw/configuration/guide/cli_rel_4_0_1a/CLIConfigurationGuide/sm_syslog.html) Cisco交换机端口出错处理(http://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/69980-errdisable-recovery.html)

openstack icehouse update errors

最近将Openstack从havana升级到icehouse,总体问题不大,但是还是有点小问题,花了一点时间。 1 密钥过期,keystone的密钥提示过期。 如nova提示: 2014-04-29 10:52:14.074 27081 WARNING keystoneclient.middleware.auth_token [-] Verify error: Command ‘openssl’ returned non-zero exit status 4 解决办法是1) 备份/etc/keystone/ssl目录并删除,运行keystone-manage pki_setup –keystone-user keystone –keystone-group keystone,上面的ssl目录会生成,这里的用户名和用户组为linux系统中的keystone对应的用户和组 3) 修改ssl目录属主和权限700. neutron也可能由此提示,解决办法是删除/var/lib/neutron/keystone-signing目录,并重启neutron-server。 此外,可能还需要删除/tmp下的keystone-signing-xxxxx目录。 总体而言,上面的错误表面现象为keystone 401 Unauthorized的错误,但是解决问题需要定位到相应模块,用debug=true和verbose=true从调试信息中找出问题。 如nova list返回401的原因有可能是neutron的证书问题,所以大家在调错是一定要仔细。 … Continue reading

Openstack中构造伪造源地址攻击

前一篇是将防御,这一篇简单说一下openstack下如何发动伪造源ip的DoS攻击 1 修改iptables和ebtables的设定,例如攻击vm为100.0.0.17,那么查询相应的iptables规则:

找到iptables中含有091f121f-8的链:neutron-openvswi-s091f121f-8,neutron-openvswi-i091f121f-8,neutron-openvswi-o091f121f-8,和nova-instance-xxx(与该vm对应的)插入一条优先级最高的ACCEPT链 找到ebtables中nat表中091f121f-8的链:I-tap091f121f-8c-arp-ip,I-tap091f121f-8c-ipv4-ip,插入一条优先级最高的ACCEPT链 2 安装ruby,下载pentibox 3 启动pentibox,选择Network tools->Net DoS Tester -> 任意一种即可发动攻击 如果第1步中加了规则还是不通,请检查源主机和目的主机的安全组是否允许 下面的我写的脚本,希望对大家有所帮助  Bash |   copy code |?12#!/bin/bash3 4ip=$15echo $ip6id=<code>neutron port-list |grep "$ip"|awk ‘{print $2}’ echo $id if [ -z $id ] then echo “id null” … Continue reading

Openstack中伪造源地址攻击的防御

背景:Openstack在H版之前的时候,租户可以租用虚拟机发动DoS攻击,很多攻击的方式是伪造源地址。还有别的攻击,如ARP攻击等等,都是通过伪造源MAC或IP地址实现的。本文简单介绍一下openstack中抵御虚假源地址的攻击。 这种攻击的特点是攻击者从虚拟化系统内部发起,攻击目标可能是公网主机,或者是内网的主机。对于前者的防御比较容易,只需要在物理网络边界就可以部署安全设施进行检测和清洗;但是后者的攻击流量大部分是存在于虚拟网络和虚拟网络设备中,物理的安全设备是无法观测或理解物理网络中的流量,无法进行有效的防护,所以对于始于内部的DoS攻击,应该在虚拟化环境中将检测并抵御。 在Openstack的架构下,预计一种检测DoS攻击的方式是依靠检测模块Ceilometer,等它成熟之后,就可及时通知管理员或系统,通过Ceilometer与Neutron协作堵住这种攻击。 不过现在Ceilometer还在初级阶段,所以还是需要依靠网络虚拟化模块Neutron进行防护,好在IaaS系统知道VM的真实IP和MAC,所以可以直接在L2防火墙上对数据包进行过滤,H版已经引入了这部分特性。 下面以一台vm为例: # neutron port-list|grep 100.0.0.16 | 368d35e1-4db7-405f-af26-1f2b6f224bd8 | | fa:16:3e:34:c8:f8 | {“subnet_id”: “57b30eb5-e9ee-489f-85ea-77bcaa6249e5”, “ip_address”: “100.0.0.16”} | 2013.2.1引入了基于IPTABLES的过滤方案 iptables -L -nvx 可以看到: Chain neutron-openvswi-s368d35e1-4 (1 references) pkts bytes target prot opt in … Continue reading

neutron中一种常见网络不通的现象,附修复脚本

neutron中经常发现vm ping不通网关,我发现很多情况是因为ovs-plugin没有将qvb连接到qbr桥上,所以解决办法也很简单,就是将其连上,即将qbr设为master。 具体的neutron、ovs、veth和iptables等就不展开讲了,具体可以看下图 当一个vm启动或被硬重启之后,tap接口(当使用gre模式时为tap)和qbr桥会被自动创建,而且tap的master为qbr。理论上qvb的master也应该是qbr,但我经常发现这个link的master没有被设置。那么设置脚本就很简单了:  Bash |   copy code |?1#!/bin/bash2 3LINKS=<code>ip link|grep qvb |awk ‘{print $2}’ |sed s’/.$//’|sed s’/^…//’ for LINK in $LINKS do # a qbr link should appear after hard reboot an instance ip link set “qbr$LINK” up echo … Continue reading

主动查询ovs的信息

openvswitch的flow信息获取途径现在通常是通过命令行CLI的方式(ovs-ofctl),或是部署agent,如neutron-ovs-agent,但通常这两种方法都需要在ovs所在的节点上部署,比较麻烦。 还有一种办法是网络controller通过openflow协议获取ovs的信息(如流信息),不过其负载就加重了。那么能否模拟网络controller的功能去获取流信息呢?当然可以,不过如果将ovs的控制器设置为主动模式连接我们的软件的话,那么这个软件就需要实现controller的功能,并且要与其他controller协作,更加麻烦。 其实openvswitch可以以服务端的形态存在,我们的软件可以连接ovs,从而获取其信息。要点在于 设置ovs为被动模式 ovs-vsctl set-controller br-tun tcp:30.0.0.1 ptcp:6601 这样ovs既可以主动连接网络controller(30.0.0.1:6633),又可以监听6601端口,接受客户端请求。此处br-tun与6601是一对,如果获取其他网桥的信息,则需要监听新的端口 设置ovs-ofctl为远程模式 在controller和node1两台机器上分别运行下面的命令:

可见从不同主机都可以访问controller节点的br-tun桥,信息相同。 虽然ovs-ofctl不是自动化的方法,当时可以使用管道等技术实现程序化的办法。 在此感谢@Outlook的提示

用REST获得openvswitch ovsdb的信息

客户端可以通过ovsdb定义的协议访问openvswitch的数据库,协议在http://tools.ietf.org/html/draft-pfaff-ovsdb-proto-02,看来要成为ietf的标准了?怎么查询这些数据其实有一个样例,但是比较简单,我这里略作扩展,说明如何查询ovs的网桥、所连controller和流信息。 准备工作 因为ovs需要认证(公钥)才能访问其数据,我们为了简化直接在ovs所在节点上运行以下命令:

然后可以直接通过tcp的方式访问ovsdb了 echo发送存活信息 客户端可以使用tcp方式与服务器保持长连接,所以可能定时需要发送echo信息与服务器确认存活。可编写以下脚本:  Python |   copy code |?0102import socket03import json04 05OVSDB_IP = ‘127.0.0.1’06OVSDB_PORT = 663207BUFSIZE = 40960008 09s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)10s.connect((OVSDB_IP, OVSDB_PORT))11 12query = {"method":"echo", "params":[], "id": 0}13s.send(json.dumps(query))14response = s.recv(BUFSIZE)15print response16 执行结果为: {“id”:0,”result”:[],”error”:null} 这是最简单的获取信息方式了,我们接下来要看看OVSDB中到底有些什么数据 获得所有数据库名 脚本中其他不变,最后三行换为以下内容,以后步骤也是类似:  Python |   copy code |?12query = … Continue reading

Floodlight的流量控制

floodlight在bigswitch退出opendaylight后算是活过来了,新的版本在负载均衡中加入了一些机制,可以参见net.floodlight.loadbalancer 不过我关心的是FL对流量的控制,特别是判断packet_in速率的机制,这个在前几个月的Floodlight是没有的。 现在FL的处理机制是在收到packet_in数据包后,首先判断是否超过阈值,在inputThrottled方法中,计算每1000个数据包所花的时间,得出速率。如果速率超过packetInRateThresholdHigh阈值,则进入监控限制流量模式(enablePacketInThrottle) 在该模式下,依次检查packet_in数据包的src mac(频率为每50个packet_in一次)和in port(频率为每100个packet_in一次),如果近期(1s内)有该类数据包则将其禁止。 这种方法的初衷应该是防止controller的负载过高,例如禁止mac是为了防止host发送过多包,禁止in port是为了禁止sw转发过多包。但后者有可能出现在恶意vm发动DDoS攻击(一个in port,但无数src mac),客观上却使控制器免受DDoS攻击,自然也让域内的VM被DDoS。 贴一下主干代码:

让我们计算一下这种机制的效率,由于阈值packetInRateThresholdHigh设置的是1000,那么now-lastMessageTime应为1000ms=1s;考虑到controller每1000个packet_in进行判断,也就是说入包的极限是每秒1000个packet_in数据包,即1000条新流。这个在小范围内是没问题的,但Nick McKeown等人在经典文章“OpenFlow: Enabling Innovation in Campus Networks”中提到Preliminary results suggested that an Ethane controller based on a low-cost desktop PC could process over 10,000 … Continue reading

Floodlight路由机制解析

路由部分是floodlight最核心的机制,这两天仔细读了一下floodlight这部分的代码,总算有了大体上的了解,与各位分享。 本文中的floodlight(FL)与控制器/网络控制器(NC, nework controller ) 等术语等同,交换机(SW)默认为openflow-enabled switch,不再赘述。 首先谈一下SDN控制器的路由原理:当交换机收到一个不能被当前流表各条流匹配的数据包时,会把这个数据包以openflow的格式(PACKET_IN)发送给控制器。控制器经过路由决策后,同样以openflow的格式(PACKET_OUT)的方式将该数据包的下一跳信息回给该交换机。 如果学过最短路径计算的同学一定知道,两点之间的最短路径计算首先要知道任意两点之间是否相连,如果两者间有link相连还需知道其长度。所以总体而言,FL路由包括两部分:拓扑更新和路由计算,前者是定时事先完成的,形成一个全局的拓扑结构,后者是收到数据包后运行时完成的,根据拓扑生成路由策略。 首先看拓扑更新。SDN环境中拓扑是集中控制的,故FL需要了解全局的拓扑环境,所以FL在链路更新时自动更新拓扑。 1 链路更新 当交换机加入SDN环境后,控制器通过LLDP协议定时地获得该交换机与其他设备连接的link信息,然后添加或更新这些link(LinkDiscoveryManager.addOrUpdateLink()),最后将这些link更新的事件添加到updates队列中(LinkDiscoveryManager.handleLldp())。 2 拓扑更新 计算路由的关键在于路径更新和路由计算,该过程为: 2.1 启动 首先拓扑管理启动(TopologyManager.startUp())时新起一个线程UpdateTopologyWorker,间隔500ms重复运行 。 2.2 更新拓扑 如果之前在第一步中有一些链路、交换机等更新,那么LDUpdates队列中会有元素,那么依次取出这些链路更新的元素(TopologyManager.updateTopology()/TopologyManager.applyUpdates()),判断其类型(如链路更新/删除、端口增加/删除),进行响应处理。 以链路更新为例,调用TopologyManager.addOrUpdateLink()方法,判断链路类型(多跳、单跳或隧道),再把link添加到相应交换机的端口中,如果是多跳的则再删除可能的单跳link 2.3 计算拓扑路径 每次新建一个实例(TopologyManager.createNewInstance()),初始化过程中计算拓扑路径(TopologyInstance.compute()),具体地: 2.3.1 归类 将现有所有相连的link置于同一个簇中,从而形成多个簇结构(identifyOpenflowDomains()) 2.3.2 建簇 遍历所有link(addLinksToOpenflowDomains()),如果link连接的是同一个簇,则将其加入该簇,所以该方法统计了所有簇内的link。FL这么做也是减少路由计算的开销,不然若干个大二层网络中共有n个节点,就需要n平方的存储开销,计算效率也会下降,如果将不相连的节点分开就减少了上述开销。 2.3.3 遍历所有簇 … Continue reading

raspberry wlan0 ifconfig fail

树莓派的wifi网卡总是上不了网,搞了很久都找不到解决办法 提示错误是当运行ifconfig wlan0分配ip时出错: [20014.112395] wlan0: deauthenticating from xxx by local choice (reason=3) 但是lsusb时发现设备还在,应该不是电源的问题,百思不得其解 google了很久终于发现当前居然有wpa的进程(我的wlan0是无密码的) pi@raspberrypi ~ $ ps aux|grep wpa root 2071 0.0 0.3 5952 860 ? Ss 23:47 0:00 /sbin/wpa_supplicant -s -B -P /var/run/wpa_supplicant.wlan0.pid … Continue reading