设为首页 收藏本站
查看: 1093|回复: 1

[经验分享] VCenter中嵌套openstack VM不能ping通外部网络问题解决的方法

[复制链接]

尚未签到

发表于 2017-12-5 09:25:12 | 显示全部楼层 |阅读模式
  问题描写叙述:
  近期搭建了vCenter环境,并使用vCenter创建的VM搭建了一套openstack环境。在验证openstack的外网功能时。发现报文死活ping不通外网,抓包发现报文在vcenter的dvs处给丢掉了,这是很奇怪的事情。细致排查后。现vCenter居然感知报文的mac对于不受vCenter管理的VM发出的报文直接忽视。
  先上图:
DSC0000.jpg

  解释例如以下:
  1)ESX-B016是安装了VMWare ESX的主机,受vCenter管理和控制。我使用vCenter创建一个虚拟分布式交换机(dvs01),使用ESX-B016主机的eth2作为这个交换机的上行口(可能有人会问,为什么用eth2作为上行口,这个由于eth0和eth1被别人占用了:))。ESX-B016     的eth2网卡连接到外部物理交换机switch1的g1口。然后通过交换机的g3口连接到了物理网关路由器Rrouter1上;物理网关路由器的IP为162.3.110.1。
  2)使用vCenter在ESX-B016主机上创建了一个VM(虚拟机名称为OpenStack_VM),用来安装OpenStack环境,这个VM的网卡eth0连接到dvs01的port组dVPort1上;
  3) 在OpenStack环境上。我创建了租户网络(net1:192.168.0.0/24)、虚拟机(user_vm),路由器(R),将net1关联到router上,并创建了网络(ext1:162.3.0.0/16)作为外部网络
  4) 创建的ext外部网络是vlan类型,vlanid设置为1000。 dVPort1port组为vlan中继。同意2-4094通过,同一时候g1设置为trunk口。g2设置为access口,仅仅同意vlan 1000通过.
  一起就绪后。我进入user_vm虚拟机中运行ping 162.3.110.1操作,理论上应该可以ping通网关,可是奇怪的是怎么也不通。
  定位过程
  好吧,仅仅能祭出抓包的利器tcpdump,首先看一下报文的传输路线:user_vm -> br-int ->R -> snat -> br-int -> br-eth0 -> eth0 -> dvs01 -> uplink口(eth2)->  g1 –> g3 -> Router1,
  1) 第一步我在User_VM运行ping 162.3.110.1
  2) 首先确定ping报文是否发出去了,在user_vm虚拟机的eth0上抓包。发现可以抓到通往162.3.110.1的ICMP请求报文。但没有响应;
  3) 在R上抓包。也能抓到通往162.3.110.1的ICMP请求报文。但没有响应;
  4) 在eth0口抓包,相同能抓到通往162.3.110.1的ICMP请求报文,但没有响应,说明报文已经从openstack_VM虚拟机中发出去了,进入了dvs01分布式交换机;
  5) 分布式交换机dvs01通过上行口送给了物理交换机switch1的g1口,我在switch1上运行displaymac-address | include GE0/0/1命令,监控全部经过g1口的报文。没有发现源mac地址为snat的外网口mac的不论什么报文(这里为何是外网口的源mac。不明确的同学能够细致思考下),这说明报文没有如期送到switch1中。难道经过dvs01时凭空消失了?
  解决的方法:
  经过查资料,发现原来的确是被dvs01丢失了。这是由于port组的配置导致的,将OpenStack_VM相应的port组配置改动例如以下就可以解决这个问题:
DSC0001.jpg

  根本原因在于,我们使用openstack创建的snat上面的外网口对dvs01来说是不被承认的, 假设将伪传输设置为拒绝的话, ESX会将正在传输的报文mac和全部适配上有效的mac进行比对,发现有不一致的报文会进行丢弃。
  这里何谓有效?肯定是ESX自己分配的mac地址是有效的,而openstack分配的mac地址ESX感知不到,也因此觉得是无效的。

  附加资料:
  以下是VMware官方文档对混杂模式和伪传输的描写叙述:
  Promiscuous Mode(混杂模式):
  混杂模式控制虚拟机能否够查看 ESX 主机上其它节点的单播通信量。
  默认情况下,此选项设置为 [Reject(拒绝)],这意味着虚拟网络适配器在混杂模式下无法执行。在混杂模式中,虚拟网络适配器无需执行不论什么接收过滤。因此客户操作系统可接收线路上观察到的全部通信量。
  虽然混杂模式能够有效跟踪网络活动,但这样的执行模式极不安全,由于不管某些数据包是否仅仅能由特定的网络适配器接收,在混杂模式中全部适配器都可訪问这类数据包。
  这意味着虚拟机中的管理员或 Root 用户能够查看传输至其它客户机或主机操作系统的通信量。  
  虽然最经常使用的混杂模式应当处于关闭状态,但假设正在执行网络入侵检測软件或数据包port扫描器。那么也可将虚拟交换机配置为在混杂模式中执行。
  Forged Transmits(伪传输):  
伪传输将影响出站通信量。默认情况下,此选项设置为 [Accept(接受)],这意味着 ESX 主机不会将源 MAC 地址与有效 MAC 地址进行比較。假设将此选项设置为 [Reject(拒绝)],ESX 主机会将操作系统正在传输的源 MAC 地址与其适配器的有效 MAC 地址进行比較。查看它们是否匹配。假设地址不匹配,ESX 会丢弃此数据包。客户操作系统不会检測到其虚拟网络适配器无法使用模拟的 MAC 地址发送数据包。  ESX 主机将在不论什么使用模拟地址传递数据包传输之前将其截获。因此,客户操作系统可能会假设数据包已被丢弃。

运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-420718-1-1.html 上篇帖子: openstack中数据库连接数太多--pymysql.err.OperationalError,1040, u'Too many connections' 下篇帖子: OpenStack设计与实现5——RESTful API和WSGI
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表