联通宽带是用sdn一般默认网关是多少吗

来源：蜘蛛抓取(WebSpider) 时间：2018-10-27 22:03 标签： 一般默认网关是多少

接着我的上一篇文章本文讨论嘚主题是集成的容器的OVN。 在本实验结束时我们将创建一个容器主机“VM”（虚拟机），其中包含一对容器 这些容器将直接绑定到OVN逻辑交換机中，并且可以直接从逻辑网络内的所有虚拟机访问

根据官方的OVN架构文档，OVN的容器网络选择使用VLAN Trunk作为连接到容器主机VM的方式并要求來自每个容器的流量被隔离在一个唯一的VLAN内。这也意味着在OVN和容器主机之间必须对VLAN信息进行同步以确保它们在同一时间给特定容器使用哪个VLAN tag。通过这种方式它对容器主机施加了一定程度的控制，以确保主机上的容器被相互隔离

我把OVN实现步骤细分为三步:

  • 创建一个连接主機VM的逻辑端口。

  • 为容器定义逻辑端口将它们映射到“父”虚拟机逻辑端口，并定义要使用的VLAN tag

  • OVN配置OVS流，将被VLAN标记的流量从“父”虚拟机嘚逻辑端口映射到目标容器的逻辑端口

在开始之前，请花点时间看一下当前环境信息

OVN 逻辑网络拓扑:


在本次实验中，我将创建一个新的偽“虚拟机”vm5，它将托管我们的伪“容器”新虚拟机将接入到现有的DMZ交换机，和vm1和vm2相邻 我们将对新虚拟机及其容器使用DHCP。在为vm5创建邏辑端口之前我们需要查看在上一篇文章中为DMZ网络创建的DHCP选项。 我们将直接查询OVN北向数据库以获取此DHCP选项相关信息

我这个实验环境的輸出结果是：


让我们为vm5创建逻辑端口。 你现在应该对这些命令不陌生了 请务必将{uuid}替换为上述DHCP选项条目中的UUID。


现在我们将为在vm5上运行的容器创建逻辑端口 此过程几乎与创建正常的逻辑端口相同，需要注意有几个新的命令

在ubuntu1上进行如下操作：


因此，唯一的区别是为容器逻輯端口设置了一个parent_name和vlan tag 您可以通过查看数据库条目来验证这些。

我这个实验环境的输出结果是：


关于这个实验的第一件事情是我们没有使用真正的虚拟机，而是直接在Ubuntu主机上把ovs内部端口模拟成虚拟机 对于vm1,vm2,vm3和vm4，我们直接在br-int上创建这些内部端口但对于vm5，我们的实验要求有點不同因此我们将使用专用的ovs网桥。 这个br-vm5的网桥不会由OVN管理并且将模拟真实的容器主机VM内部的ovs网桥。 此网桥将为VM及其容器提供本地网絡连接并将执行VLAN tagging。

配置完成之后就是下图：

我的实验配置很简单我把容器都放在同一个逻辑交换机上。然而没有要求必须这样做其實我可以将容器逻辑端口放置在任一台逻辑交换机上。

在ubuntu2主机上进行如下操作：


通过ping vm5的默认一般默认网关是多少来验证网络连通性：


现在vm5巳经启动了我们可以配置它的伪“容器”。 除了vlan相关配置之外它们看起来几乎完全和我们的伪“虚拟机”们一模一样。



如果按照ovn官方架构文档直接在虚拟机管理程序上运行容器，或者直接用patch端口连接到集成网桥那么在网络规模特别大的情况下，OVN系统可能会崩溃

“嵌套”网络解决方案是很好的，因为它大大减少了集成桥上的VIF的数量从而最小化容器本身的性能损失。

最后再说明一下本实验的重点鈈是建立一个完全真实的容器环境，而是展示OVN的内置的容器网络功能集

接着我的上一篇文章本文讨论嘚主题是集成的容器的OVN。 在本实验结束时我们将创建一个容器主机“VM”（虚拟机），其中包含一对容器 这些容器将直接绑定到OVN逻辑交換机中，并且可以直接从逻辑网络内的所有虚拟机访问

根据官方的OVN架构文档，OVN的容器网络选择使用VLAN Trunk作为连接到容器主机VM的方式并要求來自每个容器的流量被隔离在一个唯一的VLAN内。这也意味着在OVN和容器主机之间必须对VLAN信息进行同步以确保它们在同一时间给特定容器使用哪个VLAN tag。通过这种方式它对容器主机施加了一定程度的控制，以确保主机上的容器被相互隔离

我把OVN实现步骤细分为三步:

  • 创建一个连接主機VM的逻辑端口。

  • 为容器定义逻辑端口将它们映射到“父”虚拟机逻辑端口，并定义要使用的VLAN tag

  • OVN配置OVS流，将被VLAN标记的流量从“父”虚拟机嘚逻辑端口映射到目标容器的逻辑端口

在开始之前，请花点时间看一下当前环境信息

OVN 逻辑网络拓扑:


在本次实验中，我将创建一个新的偽“虚拟机”vm5，它将托管我们的伪“容器”新虚拟机将接入到现有的DMZ交换机，和vm1和vm2相邻 我们将对新虚拟机及其容器使用DHCP。在为vm5创建邏辑端口之前我们需要查看在上一篇文章中为DMZ网络创建的DHCP选项。 我们将直接查询OVN北向数据库以获取此DHCP选项相关信息

我这个实验环境的輸出结果是：


让我们为vm5创建逻辑端口。 你现在应该对这些命令不陌生了 请务必将{uuid}替换为上述DHCP选项条目中的UUID。


现在我们将为在vm5上运行的容器创建逻辑端口 此过程几乎与创建正常的逻辑端口相同，需要注意有几个新的命令

在ubuntu1上进行如下操作：


因此，唯一的区别是为容器逻輯端口设置了一个parent_name和vlan tag 您可以通过查看数据库条目来验证这些。

我这个实验环境的输出结果是：


关于这个实验的第一件事情是我们没有使用真正的虚拟机，而是直接在Ubuntu主机上把ovs内部端口模拟成虚拟机 对于vm1,vm2,vm3和vm4，我们直接在br-int上创建这些内部端口但对于vm5，我们的实验要求有點不同因此我们将使用专用的ovs网桥。 这个br-vm5的网桥不会由OVN管理并且将模拟真实的容器主机VM内部的ovs网桥。 此网桥将为VM及其容器提供本地网絡连接并将执行VLAN tagging。

配置完成之后就是下图：

我的实验配置很简单我把容器都放在同一个逻辑交换机上。然而没有要求必须这样做其實我可以将容器逻辑端口放置在任一台逻辑交换机上。

在ubuntu2主机上进行如下操作：


通过ping vm5的默认一般默认网关是多少来验证网络连通性：


现在vm5巳经启动了我们可以配置它的伪“容器”。 除了vlan相关配置之外它们看起来几乎完全和我们的伪“虚拟机”们一模一样。



如果按照ovn官方架构文档直接在虚拟机管理程序上运行容器，或者直接用patch端口连接到集成网桥那么在网络规模特别大的情况下，OVN系统可能会崩溃

“嵌套”网络解决方案是很好的，因为它大大减少了集成桥上的VIF的数量从而最小化容器本身的性能损失。

最后再说明一下本实验的重点鈈是建立一个完全真实的容器环境，而是展示OVN的内置的容器网络功能集

在openshift中如果使用docker 命令启动一个docker容器，容器中的网络没有任何不同；唯一的不同就是docker网络拍的网桥名是ibr0而不是docker0

那运行在kubernetes/openshift中的pods呢 一个pod是由一组相关的容器组成，pod中的容器共享网络接口/hostname；两个容器（两个进程）可以使用“localhost”交流

OpenShift通过OpenShift-SDN组件保证了集群中在同一个namespace下的所有pods可以相互访问到，即使运行在不同的主機上主要有两大特点：1. 所有namespaces下的所有pods在同一个网络中可以看见对方。2. 每一个namespace可以表现为一个私有网络（即多租户）

分配/16私有子网空间（默认10.1.0.0/16）作为集群网络在集群网络中每个node节点分配/24大小的ip地址空间给node节点上的pods。每个node自己分配一个一般默认网关是多少地址（例如10.1.x.1）子網的广播地址（10.0.x.255）不能分配给node或者pod。意味着在默认配置下OpenShift集群中最多有256个node节点以及每个node节点最多254个pod

br0通过虚拟网络设备对“vovsbr”和“vlinuxbr”跟Ibr0相連接，进而能够跟通过docker命令启动的docker容器通信同时通过tun0连接node的host网络进而能够访问外网，tun0扮演了OpenShift集群中所有pods一般默认网关是多少的角色Ibr0扮演了单独docker容器一般默认网关是多少的角色。所以它们都被分配到了node几点子网默认一般默认网关是多少ip地址但是并不产生冲突，因为容器囷pods分别只能看到属于它们自己的Ibr0和tun0一般默认网关是多少



网络配置如果多租户SDN 被选中，所有的网络包通过内核的openflow data path 被标记上VNID从而被隔离成不鼡的namespace


主机上通过ip a查看网络信息

我要回帖

更多关于 一般默认网关是多少 的文章

 

随机推荐