Open vSwith模拟网关实现不同子网的互通

简介:

一.实验目的

本实验通过Mininet构建子网,并使得OVS作为网关,来模拟子网间的互通。在实验的过程中,我们来学习一下内容:OVS构建子网过程。

OVS设置网关过程。

OVS配置流表过程。

Open vSwith模拟网关实现不同子网的互通

二.实验准备

实验环境我们使用Mininet进行构建,建议到Mininet官方下载最新的Mininet虚拟机,本实验中虚拟机版本是mininet-2.2.1-150420-ubuntu-14.04-server-amd64,或者参考官方文档中介绍的Native Installation from Source进行安装。

实验拓扑图如下:

Open vSwith模拟网关实现不同子网的互通 图1

三.实验步骤

1.构建网络拓扑。

我们的目标是要让两个不同子网的主机能相互通信,可以先构建出两个主机,然后给主机设置不同子网。由于Mininet虚拟的主机默认属于10.0.0.0/24,需要对主机网络进行设置。

说明:

$> 表示Linux命令行的输入,权限为root。

mininet> 表示Mininet命令行模式。

创建拓扑

$> mn --topo single,2 --mac

说明:参数--mac是为了创建的host有更简单的MAC地址,为后面流表创建提供方便。

查询状态

mininet> dump

可以看出,默认的h1和h2是在同一网段,而且可以相互ping通。

mininet> h1 ping h2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=1.96 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=0.412 ms

修改网络设置

mininet> h1 ifconfig h1-eth0 10.0.0.1/24 netmask 255.0.0.0
mininet> h2 ifconfig h2-eth0 20.0.0.1/24 netmask 255.0.0.0

测试网络状态如下:

mininet> h1 ping h2
connect: Network is unreachable

由于通过配置,h1和h2已经不在同一网段,当h1 ping h2时,包会转发到子网的网关来处理,但是由于当前环境中没有针对两个网段设置网关,最终状态为不可达。此时我们可以为主机设置网关。

设置网关

mininet> h1 route add default gw 10.0.0.254 h1-eth0
mininet> h2 route add default gw 20.0.0.254 h2-eth0

测试网络状态如下:

mininet> h1 ping h2
PING 20.0.0.1 (20.0.0.1) 56(84) bytes of data.
From 10.0.0.1 icmp_seq=1 Destination Host Unreachable
From 10.0.0.1 icmp_seq=2 Destination Host Unreachable

为了更直观的观察当前网络状态,在新的Linux窗口使用tcpdump来查看h1 ping h2过程中包的信息。如下:

$>tcpdump -vvv -i s1-eth1
tcpdump: WARNING: s1-eth1: no IPv4 address assigned
tcpdump: listening on s1-eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
05:38:06.917012 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.0.254 tell 10.0.0.1, length 28
05:38:07.917134 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.0.254 tell 10.0.0.1, length 28

当h1-eth0发送ARP包请求s1-eth1网关,而当前环境中没有网关设备,OVS无法进行转发;另外,如果OVS连接了控制器,如OpenDaylight,这可以利用它预设的ARP Proxy,让控制器来提供目标地址信息。因此ICMP封包前,由于获取不到目标地址信息,而导致网络不可达。

2. 设置OVS为网关

如果实验连接了控制器,这可以通过控制器获得目标地址的信息,这部分可以单独通过另外的实验进行验证。由于试验中没有任何控制器,因此需要对OVS进行配置,使得其具有gateway的功能,能夠对ARP进行回复。

mininet> s1 ifconfig s1:0 10.0.0.254
mininet> s1 ifconfig s1:1 20.0.0.254

测试网络状态,发现h1与网关可以ping通了。

mininet> h1 ping 10.0.0.254
PING 10.0.0.254 (10.0.0.254) 56(84) bytes of data.
64 bytes from 10.0.0.254: icmp_seq=1 ttl=64 time=3.35 ms
64 bytes from 10.0.0.254: icmp_seq=2 ttl=64 time=0.669 ms

从tcpdump窗口观察到的信息也显示相关信息如下:

10.0.0.1 > 10.0.0.254: ICMP echo request, id 4284, seq 3, length 64
06:01:43.104097 IP (tos 0x0, ttl 64, id 3241, offset 0, flags [none], proto ICMP (1), length 84)
10.0.0.254 > 10.0.0.1: ICMP echo reply, id 4284, seq 3, length 64
06:01:46.114482 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.0.1 tell 10.0.0.254, length 28

但是,此时h1 ping h2还是不会通的。因为当前转发平面没有任何流对发过来的ICMP包做转发。因此,我们需要添加一些流,使得整个网络最终运作起来。

3. 配置流表

处理ARP请求

当网管的ARP流到来后,将其交给本地的OVS处理。

mininet> sh ovs-ofctl add-flow s1 "table=0,priority=65535,arp,arp_tpa=10.0.0.254 actions=LOCAL"
mininet> sh ovs-ofctl add-flow s1 "table=0,priority=65535,arp,arp_tpa=20.0.0.254 actions=LOCAL"

处理ARP应答

该应答回复目标地址的出口,比如将目标网络10.0.0.1的包通过出口端口1抓发出去。端口信息可以查询如下:

mininet> sh ovs-vsctl -- --columns=name,ofport list Interface
name : "s1-eth2"
ofport : 2
name : "s1-eth1"
ofport : 1
name : "s1"
ofport : 65534

处理应答的流表如下:

mininet> sh ovs-ofctl add-flow s1 "table=0,priority=1,arp,nw_dst=10.0.0.1,actions=output:1"
mininet> sh ovs-ofctl add-flow s1 "table=0,priority=1,arp,nw_dst=20.0.0.1,actions=output:2"

处理了应答包后,实际上网络还是不能通。到目前为止,仅对ARP的包做了相应的处理,而ICMP的包为处理。

10.0.0.1 > 20.0.0.1: ICMP echo request, id 5004, seq 1, length 64
06:28:06.932565 IP (tos 0x0, ttl 64, id 52645, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.0.1 > 20.0.0.1: ICMP echo request, id 5004, seq 2, length 64
06:28:07.932469 IP (tos 0x0, ttl 64, id 52646, offset 0, flags [DF], proto ICMP (1), length 84)

ICMP应答处理

接下来需要对ICMP的请求进行处理。为了使得流表表达更清晰,我们将ICMP路由的处理放在另外一个table处理。 也就是在table(1)中设置一个最低优先级的流,将非ARP的包丢给下一个流表处理。

mininet> sh ovs-ofctl add-flow s1  "table=0,priority=0,actions=resubmit(,1)"

在table(1)中,OVS的角色有点像router,我们需要修改ICMP封包的目标MAC地址。

mininet> sh ovs-ofctl add-flow s1 "table=1,icmp,nw_dst=10.0.0.1,actions=mod_dl_dst=00:00:00:00:00:01,output:1"
mininet> sh ovs-ofctl add-flow s1 "table=1,icmp,nw_dst=20.0.0.1,actions=mod_dl_dst=00:00:00:00:00:02,output:2"

最后,执行h1 ping h2,两个子网的主机能顺利ping通。

mininet> h1 ping h2
PING 20.0.0.1 (20.0.0.1) 56(84) bytes of data.
64 bytes from 20.0.0.1: icmp_seq=1 ttl=64 time=1.29 ms
64 bytes from 20.0.0.1: icmp_seq=2 ttl=64 time=0.080 ms
64 bytes from 20.0.0.1: icmp_seq=3 ttl=64 time=0.089 ms


作者:何妍 

来源:51CTO

相关文章
|
Docker 容器
Docker | 自定义网络(网关、子网地址)
Docker | 自定义网络(网关、子网地址)
1041 0
Docker | 自定义网络(网关、子网地址)
|
弹性计算 网络安全 网络架构
如何通过nat网关实现不同VPC间的互通
如何通过nat网关实现不同VPC间的互通
|
网络安全
aws-vpc-nat网关(私有子网访问Internet)
aws-vpc-nat网关(私有子网访问Internet)
238 0
aws-vpc-nat网关(私有子网访问Internet)
|
运维 安全 网络协议
SOFAGW 网关:安全可信的跨域 RPC/消息 互通解决方案
本文将介绍 SOFAGW 互通网关,首先切入在跨站点通信时碰到的核心痛点,引入 SOFAGW 互通网关的解决方案,会重点说明如何解决在安全、互通、接入成本、高效等几方面问题,介绍 SOFAGW 网关的内部实现架构,展示 SOFAGW 网关达成的业务成果。
SOFAGW 网关:安全可信的跨域 RPC/消息 互通解决方案
|
3月前
|
监控 负载均衡 Java
深入理解Spring Cloud中的服务网关
深入理解Spring Cloud中的服务网关
|
12天前
|
监控 负载均衡 安全
微服务(五)-服务网关zuul(一)
微服务(五)-服务网关zuul(一)
下一篇
无影云桌面