Solaris Crossbow Practice Guide (2): Virtual Network and etherstub

In the previous article, we created multiple vnics on the physical Nic to reuse the physical Nic. In fact, we have created a network environment shown in 1.
 

 
Figure 1 network environment created by VNIC and Zone

As shown in figure 1, we can see that we have created two virtual NICs (VNIC): v1 and v2, together with the physical network card bge0, they constitute a Three Link Layer connection objects in the same subnet in the local environment, that is, virtual network card objects (although bge0 is a physical device, but for the network link layer in the Solaris kernel, like v1 and v2, It is a link layer connection object ). The global zone and non-Global zone in Figure 1 are both available as an independent system (the original intention of Zone introduction is to implement mutually isolated operating environments on the software ), the difference is that the global zone is the operating environment provided to the user after the operating system is installed, and the non-Global zone is the zone created by the user (usually privileged user) in the global zone, privileged users can create VNIC and non-global zones in the global zone. However, in non-global zones, even privileged users (even root users) cannot create non-global zones or VNIC.

In this article, we will create a virtual network. In this network, Nic interfaces, link layer switches, and routers of the core components of the network are all implemented using Solaris virtualization technology. In practical applications, we can use these network components as actual network components and deploy the customer's network services in this network. These components can replace the actual network components. The difference is that, the system administrator can manage these components only through CLI without plugging the network cable.

In the previous article, I introduced vnic, which can be used as the NIC in the virtual network. At the same time, we can also use the exclusive IP stack zone of Solaris to implement the virtual router (layer-3 Switch ). However, as a complete LAN, we also need link layer switches to connect hosts in the same subnet. Here, we can use etherstub introduced in the Solaris Crossbow Project to assume the role of the link layer switch in the virtual network. The command to create an etherstub is:

# Dladm create-etherstub <etherstub_name>

We can view the etherstub information through "dladm show-link" or "dladm show-etherstub:

# Dladm show-link <etherstub_name>

Or:

# Dladm show-etherstub <etherstub_name>

You can use "dladm Delete-etherstub <etherstub_name>" to delete this etherstub.

Next, I will create a virtual network shown in 2 without using a physical network device, which exists completely in a Solaris System and is independent from the physical network. If it exists and runs, only one host is needed.

Figure 2 virtual network structure created by vnic, etherstub, and Zone

Figure 2 shows two networks. Our goal is to use the router as a router so that the virtual hosts zclient1 and zclient2 in the two networks can communicate with each other. Here, zclient1, zclient2, and zruter are both non-global zones. Vclient1, vclient2, vrouter1, and vrouter2 are both vnics. The IP addresses assigned to each vnic are marked below.

First, we will create two etherstub as the link layer switch:

Global-zone # dladm create-etherstub etherstub1
Global-zone # dladm create-etherstub etherstub2
Global-zone # dladm show-etherstub
Link
Etherstub1
Etherstub2

Next, create two vnics: vclient1 and vrouter1 and connect them to etherstub1:

Global-zone # dladm create-vnic-l etherstub1 vclient1
Global-zone # dladm create-vnic-l etherstub1 vrouter1

Similarly, create two vnics: vclient2 and vrouter2 and connect them to etherstub2:

Global-zone # dladm create-vnic-l etherstub2 vclient2
Global-zone # dladm create-vnic-l etherstub2 vrouter2

Now, let's take a look at the created vnic (V1 and V2 are the vnic created in the previous article ):

Global-zone # dladm show-vnic
Link over speed macaddress macaddrtype vid
V1 bge0 1000 2: 8: 20: 7A: 5D: Ed random 0
V2 bge0 1000 2: 8: 20: EE: F0: CC random 0
Vclient1 etherstub1 0 2: 8: 20: 60: 10: 91 random 0
Vrouter1 etherstub1 0 2: 8: 20: eb: f7: c random 0
Vclient2 etherstub2 0 2: 8: 20: 8f: 86: da random 0
Vrouter2 etherstub2 0 2: 8: 20: 5b: d1: 74 random 0

Create three non-global zones, zclient1, zclient2, and fig below:

Global-zone # zonecfg-z zclient1
Zclient1: No such zone configured
Use 'create' to begin creating a new zone.
Zonecfg: zclient1> create
Zonecfg: zclient1> set zonepath =/export/home/zclient1
Zonecfg: zclient1> set ip-type = exclusive
Zonecfg: zclient1> add net
Zonecfg: zclient1: net> set physical = vclient1
Zonecfg: zclient1: net> end
Zonecfg: zclient1> verify
Zonecfg: zclient1> commit
Zonecfg: zclient1> exit
Global-zone # zonecfg-z zclient2
Zclient2: No such zone configured
Use 'create' to begin creating a new zone.
Zonecfg: zclient2> create
Zonecfg: zclient2> set zonepath =/export/home/zclient2
Zonecfg: zclient2> set ip-type = exclusive
Zonecfg: zclient2> add net
Zonecfg: zclient2: Net> set physical = vclient2
Zonecfg: zclient2: Net> end
Zonecfg: zclient2> verify
Zonecfg: zclient2> commit
Zonecfg: zclient2> exit
Global-zone # zonecfg-Z zruter
Zruter: no such zone configured
Use 'create' to begin creating a new zone.
Zonecfg: FIG> Create
Zonecfg: Maid> set zonepath =/export/home/FIG
Zonecfg: zruter> set IP-type = exclusive
Zonecfg: FIG> Add net
Zonecfg: zruter: Net> set physical = vrouter1
Zonecfg: FIG: Net> end
Zonecfg: FIG> Add net
Zonecfg: zruter: Net> set physical = vrouter2
Zonecfg: FIG: Net> end
Zonecfg: FIG> verify
Zonecfg: zruter> commit
Zonecfg: FIG> exit

The following code uses clone to install the three zones just created above. zone1 is the Zone created in the previous article and zoneadm (1 M) is used) the clone sub-command in install Zone is much faster than the install sub-command in zoneadm (1 M:

Global-zone # zoneadm-z zclient1 clone zone1
Global-zone # zoneadm-z zclient2 clone zone1
Global-zone # zoneadm-z zruter clone zone1
Global-zone # zoneadm list-cv
ID NAME STATUS PATH BRAND IP
0 global running/ipkg shared
-Zone1 installed/export/home/zone1 ipkg excl
-Zclient1 installed/export/home/zclient1 ipkg excl
-Zclient2 installed/export/home/zclient2 ipkg excl
-Fig/export/home/FIG
Global-zone # zoneadm-z zclient1 boot
Global-zone # zoneadm-z zclient2 boot
Global-zone # zoneadm-Z zruter boot

Then, you can configure the IP addresses of each zone in 2 through "zlogin-C <zone_name>. With this configuration, the addresses of each zone are configured as follows:

Global-zone # zlogin zclient1 ifconfig-A4
Lo0: Flags = 2001000849 <up, loopback, running, multicast, IPv4, virtual> MTU 8232 Index 1
Inet 127.0.0.1 netmask ff000000
Vclient1: Flags = 1000863 <up, broadcast, notrailers, running, multicast, IPv4> MTU 9000 index 2
Inet 10.1.1.11 netmask ffffff00 broadcast 10.1.1.255
Ether 2: 8: 20: 60: 10: 91
Global-zone # zlogin zclient2 ifconfig-A4
Lo0: Flags = 2001000849 <up, loopback, running, multicast, IPv4, virtual> MTU 8232 Index 1
Inet 127.0.0.1 netmask ff000000
Vclient2: Flags = 1000863 <up, broadcast, notrailers, running, multicast, IPv4> MTU 9000 index 2
Inet 10.1.2.11 netmask ffffff00 broadcast 10.1.2.255
Ether 2: 8: 20: 8f: 86: da
Global-zone # zlogin zruter ifconfig-A4
Lo0: Flags = 2001000849 <up, loopback, running, multicast, IPv4, virtual> MTU 8232 Index 1
Inet 127.0.0.1 netmask ff000000
Vrouter1: Flags = 1000863 <up, broadcast, notrailers, running, multicast, IPv4> MTU 9000 index 2
Inet 10.1.1.12 netmask ffffff00 broadcast 10.1.1.255
Ether 2: 8: 20: EB: F7: c
Vrouter2: Flags = 1000863 <up, broadcast, notrailers, running, multicast, IPv4> MTU 9000 index 3
Inet 10.1.2.12 netmask ffffff00 broadcast 10.1.2.255
Ether 2: 8: 20: 5b: D1: 74

At this time, we still cannot connect zclient2 from the host zclient1 on the network 10.1.1.0/24 to the host zclient2 on the network 10.1.2.0/24, because although there are two IP interfaces in the router, however, the routing and data packet forwarding service has not been enabled for the zrouter. We can do this to enable the router service:

Global-zone # zlogin zruter routeadm-e ipv4-routing-u
Global-zone # zlogin zruter routeadm-e ipv4-forwarding-u

Enable the routing discovery service in zclient1 and zclient2 to establish a default route (the default routing discovery service is enabled. If it is disabled, run the following command ):

Global-zone # zlogin zclient1 routeadm-e ipv4-routing-u
Global-zone # zlogin zclient2 routeadm-e ipv4-routing-u

In this way, the zclient1 and zclient2 hosts belonging to two different subnets can be connected to each other. We can use the ping packet to try it out:

Global-zone # zlogin zclient1
[Connected to zone 'zclient1' pts/4]
Root @ zclient1 :~ # Ping 10.1.2.11
10.1.2.11 is alive
Root @ zclient1 :~ # Ping-u 10.1.2.11
10.1.2.11 is alive

On zclient2, we can use Snoop (1 m) to see the ICMP packet response:

Global-zone # zlogin zclient2
[Connected to zone 'zclient2' pts/5]
Root @ zclient2 :~ # Snoop-rd vclient2 UDP or ICMP
Using device vclient2 (promiscuous mode)
10.1.1.11-> 10.1.2.11 ICMP Echo Request (ID: 12967 sequence number: 0)
10.1.2.11-> 10.1.1.11 ICMP echo reply (ID: 12967 sequence number: 0)
10.1.1.11-> 10.1.2.11 UDP d = 33434 S = 44329 Len = 64
10.1.2.11-> 10.1.1.11 ICMP Destination Unreachable (UDP port 33434 unreachable)

So far, we have used the network virtualization technology in the crossbow project to create a network composed of two subnets. This is the so-called Nb (network in a box ). Such a network isolated from a physical network does not play a major role in the actual network service environment, however, we can easily create a real and isolated network environment on a physical host, which will be of great help for network server testing or network experiments. If you want zclient1 and zclient2 to access the Internet as a real host, or use these two non-global zones as network servers (for example, an active server and a backup server ). In this way, we can set up a router that can access the Internet 10.11.19.0/24:

 

Figure 3 Virtual Network connected to the physical network

As shown in 3, we created a vnic named V3 based on the physical network card bge0 and allocated it to the row.uter:

Global-zone # zoneadm-Z zruter halt
Global-zone # zonecfg-Z zruter
Global-zone # dladm create-vnic-l bge0 v3
Global-zone # zonecfg-Z zruter
Zonecfg: FIG> Add net
Zonecfg: zruter: Net> set physical = v3
Zonecfg: FIG: Net> end
Zonecfg: zruter> commit
Zonecfg: FIG> exit
Global-zone # zoneadm-z zruter boot
Global-zone # zlogin zruter ifconfig v3 plumb 10.11.19.172/24 up
Global-zone # zlogin zruter route add default 10.11.19.1

With this setting, the virtual network on a physical host can access the external network. It can be seen that the network virtualization technology in the Solaris Crossbow Project plays a great role in providing network resource utilization, establishing redundant network servers, and improving security. Through such a virtual network, we not only provide a service environment in a real network, but also greatly increase the availability of physical resources, so that complex network configurations are no longer limited to hardware constraints.

However, the new features brought by the Crossbow project are not only about network Virtualization Technologies. In the next article, I will introduce the Network Resource Management Section.