问题：L3 agent down了，所有的网络连接不上，L3所在的物理机点的公网IP地址访问不了
10多年的可克达拉网站建设经验，针对设计、前端、开发、售后、文案、推广等六对一服务，响应快，48小时及时工作处理。成都全网营销推广的优势是能够根据用户设备显示端的尺寸不同，自动调整可克达拉建站的显示方式，使网站能够适用不同显示终端，在浏览器中调整网站的宽度，无论在任何一种浏览器上浏览网站，都能展现优雅布局与设计，从而大程度地提升浏览体验。成都创新互联公司从事“可克达拉网站设计”,“可克达拉网站推广”以来，每个客户项目都认真落实执行。
dhcpagent服务器down了，导致所有的云主机获取不到地址，所有云主机的公网IP访问不到
现象：
网络中断，所有的公网IP地址访问不到
排查过程：
1、查看openvswitch运行状态
2、查看数据流量的流向：
查看所有ovs桥
ovs-vsctl show
查看ovs数据流
ovs-ofctl dump-flows br-int 出现卡住的现象，没有任何相应，
由于ovs-vsctl show是从ovsdb取的数据，其正常显示表示ovsdb-server进程正常运行。ovs-ofctl是与ovs-vswitchd进程通信，命令卡住应该是ovs-vswitchd进程没有响应客户端请求导致。
3、查看日志
vim /var/log/openvswitch/ovsdb-server.log 日志
WARN|unix: send error: Broken pipe
2015-09-07T19:43:59.058Z|00010|reconnect|WARN|unix:connection dropped (Broken pipe) //出现隧道破坏的警告
查看/var/log/openvswitch/ovsdb-server.log
出现类似下面的行
|WARN|Unreasonably long 16518ms pollinterval
表明ovs-vswitchd可能因为某个线程死锁或导致不响应。
4、查看进程卡在那一步：
strace -p pid
pid是指进程的ID 在这里也就是ovs-vswitchd的PID
解决办法：
重启openvswitch服务
使用cron 任务检测
cat /etc/cron.d/monitor_vswitchd
* * * * * root timeout -s SIGKILL 2sovs-ofctl show br-mgmt || (date>>/var/log/mon_openvswitch.log;serviceopenvswitch restart >> /var/log/mon_openvswitch.log 2>&1 )
升级内核
长期来说还是不要用cron来做，而是升级内核比较好。升级到2.6.32-504.16.2.el6.x86_64后问题解决。
现象：
DHCP Agent重启或漂移时，部分虚拟机断网
问题原因：
在虚拟交换机比较多时，qdhcp的netns也比较多。漂移或者重启Neutron DHCP agent后，需要重建这些资源，时间会比较长，有时长达3-5分钟。如果在这个周期里正好有虚拟机需要续租，向DHCP服务器发送的请求就没有响应，最后超时续租失败，就算DHCP服务回复后，也不会重新尝试获取IP地址。这时进入虚拟机命令行，ifup一下eth0就好了。
对于CentOS，我们建议修改dhclient的配置文件，调长续租失败时重试的超时时间，以等待DHCP服务器的恢复。
解决方法：
修改配置文件/etc/dhcp/dhclient.conf
timeout 300;
这样CentOS虚拟机续租的请求会持续重试5分钟，以等待DHCP服务恢复。
问题：公有云平台：compute1和compute4两台计算节点的存储网络，不能互通。
解决过程：
1.compute1节点ping compute4节点，在compute1和compute4两台节点上使用tcpdump抓包发现，compute4上有ICMP request和ICMP reply。但compute1节点并没有接收到ICMP reply消息，并且有xxxpackets dropped by interface的提示。
2.登录到pica8交换机，检查两台机器的物理连接和链路层连接，正常。
3.查看compute1的物理网卡，发现在RX上有大量的丢包：
[root@compute1 ~]# ifconfig bond2
bond2 Link encap:Ethernet HWaddr00:0A:F7:5D:4A:E2
inet addr:172.16.3.51 Bcast:172.16.3.255 Mask:255.255.255.0
inet6 addr: fe80::20a:f7ff:fe5d:4ae2/64 Scope:Link
UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
RX packets:5974542045 errors:8394 dropped:1892018 overruns:8394frame:0
TX packets:30430136566 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:5387974623010 (4.9 TiB) TX bytes:28489033161925 (25.9 TiB)
4.使用ethtool --show-ring 或者ethtool -g 命令查看bond2上真实物理网卡的RX/TX ringbuffer：
[root@compute1 ~]# ethtool --show-ring p6p2
Ring parameters for p6p2:
Pre-set maximums:
RX: 4078
RX Mini: 0
RX Jumbo: 0
TX: 4078
Current hardware settings:
RX: 453
RX Mini: 0
RX Jumbo: 0
TX: 4078
5.怀疑是网卡上的ring buffer参数设置过小，无法处理从网卡上接受到的以太网数据帧。
6.调整RX ring buffer的大小，通过ethtool--set-ring或者ethtoo -G
root@compute1 ~]# ethtool --set-ring p6p2rx 4078
Cannot set device ring parameters:Input/output error
[root@compute1 ~]# ethtool --show-ring p6p2
Ring parameters for p6p2:
Pre-set maximums:
RX: 4078
RX Mini: 0
RX Jumbo: 0
TX: 4078
Current hardware settings:
RX: 4078
RX Mini: 0
RX Jumbo: 0
TX: 4078
7.这样的修改，在机器reboot会回到原来的配置，建议在写入到/etc/rc.local下
ethtool -G p6p2rx 4078
ethtool -G p7p2rx 4078
现象：网卡驱动缺陷导致offload后ping正常但TCP连接慢或断的问题诊断与解决
常见的原因有：
确认物理服务器网卡和上联交换机MTU是否有问题；一般硬件厂商的MTU默认是1500，当然也有例外，像Pica8的SDN交换机，MTU值在小于1512会丢包。
2.物理网卡offload
Fuel部署时，默认开启了物理网卡offload属性。由于开启了offload属性，有可能会出现TCP或者UDP检验和不一致导致的丢包或重传。
解决方法：
TCP校验和会确保整个报文在传输过程中不会发生变化，如果校验和不一致，TCP会丢弃这个报文或者触发超时重传。TCP的校验和是必须的，UDP的校验和是非必须的。此时，建议将rx和tx关闭。
RX Checksum：
在开启此功能后，物理网卡收到一个数据包时，网卡会代替内核协议栈计算传输层校验和，并且只在校验和正确的情况下将数据包交由内核处理，以节约系统CPU资源。
关闭此feature：ethtool -KDEVNAME rx on|off
TX Checksum：
这个是在数据包发送之前，由网卡计算校验和；开启此选项，内核会随机填充TCP或UDP的检验和字段，正确的填充会由物理网卡来完成。
关闭此feature：ethtool -K DEVNAME tx on|off
持久化offload设置
可以编辑/etc/rc.local加入ethtool命令。或者利用CentOS的ifcfg-脚本。譬如要关闭eth0的tx和rx的checksum offload，可以编辑下面的文件/etc/sysconfig/ network-scripts/ ifcfg-eth0加入一行 ETHTOOL_OPTS="-Keth0 rx off;-K eth0 tx off"然后ifup eth0，设置便生效。
