Posted By Kepler Lam

When a tenant network is created in any project, Neutron will allocate a unique VLAN number (which OpenStack refer it as segment ID) for that tenant network. Note that this VLAN number is ONLY used in the physical network but NOT inside the OVS of the compute node. This is the most confusing thing, as OpenStack beginners will always have the misconception that the segment ID is used internally in the compute nodes.

Now let’s see what happen in the compute node. When you create a new VM and attach it to your tenant network, Nova component of the OpenStack will find a compute node to launch your VM. Then Neutron will try to allocate an “internal” VLAN of the OVS inside the compute node and put your VM to that internal VLAN. Neutron will instruct the OVS to map the internal VLAN traffic to the physical VLAN when going out to the physical NIC of the compute node and vice versa. Obvious, if 2 VMs are on the same tenant network, they will be put in the same internal VLAN.

The term “internal” here has the meaning of local, it means that the VLAN value of the OVS maybe different in different compute node, even if they belong to the same tenant network. But they will be translated to the same VLAN of the provider network when traffic goes onto the physical network. In short, the provider VLAN bridges the internal VLANs of all compute nodes for the same tenant network.

tnet2pnet

Why is it so complicated? Why not directly use the VLAN number inside the OVS so that translation is not required. From my point of view, if you use VLAN for the provider network, it seems that it’s really unnecessary. But what about VXLAN and GRE? As the address space of VLAN is not large enough to have a one-to-one mapping to the VXLAN or GRE segment ID, so it make sense to use a local VLAN number within the compute node, as you will never put all tenant networks in one single node. The number of VLANs should be good enough within one single node. In fact, Cisco DFA uses similar trick in the leaf switch.

Once you understand the above implementation, there should be no magic for the case of using GRE and VXLAN as the provider network.

OK, let’s see what happen if we use VXLAN (or GRE) for the physical network. Actually the only different is that when you create a tenant network, instead of allocate a VLAN for that network segment, OpenStack will allocate a VXLAN ID (VNID) (or in GRE it will allocate a key) for that network, once again this ID is referred as segment ID.

Then when you create an instance (VM) on that tenant network, once again OpenStack will find a compute node to launch your VM. However, the VM will be put onto one of the internal VLAN of the OVS in that compute node. As internally, OVS uses VLAN (not VXLAN nor GRE). Nonetheless, OpenStack will instruct the OVS to remember the mapping between the internal VLAN and the segment ID. So when the Ethernet frame goes out of the compute node to the physical network, the OVS will encapsulate it onto the corresponding VXLAN using the mapped VNID (segment ID). Similarly, in the case of GRE, the frame is encapsulated in the corresponding GRE tunnel with the mapped key.

In simple word, it just making use of VXLAN (or GRE) to bridge the internal VLANs of the compute nodes, so that all those VLANs are now in the same layer 2 domain.


 
Posted By Kepler Lam

Continue with my previous blog entry which I have mentioned that OpenStack can make use of VLANs in physical network for tenant network segregation.

Yet, what is the limitation of VLAN? What is the maximum number of VLANs you can use? Yes, only 4K, that needs to be shared with all the tenants in your cloud. Also, all your compute nodes’ physical NIC need to be on the same layer 2 network.

Then what’s the solution? If you have followed my previous blogs, you will figure out that VXLAN is one of the promising solutions. As the VNID of VXLAN supports 24 bits addressing space i.e. 16 million LAN segments. Moreover, by using VXLAN, the compute nodes’ physical NIC need not to be on the same layer 2, they can be in different subnets of the physical network, so that they can be anywhere in your data center.

Besides using VXLAN, there is another option that Neutron provides, which is the traditional GRE tunnel. GRE is just like VXLAN, both are tunneling technology that making use of IP network to encapsulate the Ethernet frames. However, GRE is point-to-point in nature, while VXLAN can make use of IP multicast to carry multi-destination Ethernet frames. In GRE header, there is 32 bit key field that can be used to identify different tenant network number.

To summary, you have 3 choices:

  1. Use VLAN,
  2. Use GRE
  3. Use VXLAN.

Let me discuss the detail one by one.

If you want to use VLAN, your compute nodes should be reside on the same layer 2 domain of your physical network, the physical NIC of your compute nodes need to connected to a trunk port of the uplink switch. And all those trunk ports need to be the same layer 2, i.e. cannot be routed. Just like the figure below:

OSVlan

In the traditional Cisco 3-tier data center design, layer 2 domains are resided within the same aggregation block. As the layer 2 boundary is between the aggregation and the core, unless you extend your layer 2 over the core, otherwise, your compute nodes cannot be attached to access switches in different aggregation blocks.

3tier

That’s the reason for Cisco Nexus to provide the Fabric Path technology so that you can extend the layer 2 anywhere in your data center. Similar solution is the Cisco DFA and ACI.

Talking back to the OpenStack, let me discuss the relationship between the tenant network and the VLAN of your physical network.

When a tenant network is created in any project, Neutron will allocate a unique VLAN number (which OpenStack refer it as segment ID) for that tenant network. Note that this VLAN number is ONLY used in the physical network but NOT inside the OVS of the compute node. This is the most confusing thing, as OpenStack beginners will always have the misconception that the segment ID is used internally in the compute nodes.

Let me discuss the relationship between the tenant network and the VLAN of your physical network in next blog entry. Please follow here to the part 3 of this blog.


 
Posted By Kepler Lam

Recently, I have a consultation request for the OpenStack and Cisco DFA integration which is a relativity new solution, and I find that although there are documentations and blogs discussing the network architecture about OpenStack, most of them are focusing on the internal network inside the compute node (hypervisor). It seems that there is not much information about the relationship of the physical network (OpenStack refer it as provider network) and the tenant network (network that defined in OpenStack). Here in this blog I try to bridge the gap, so that I wish it will be easier for networking guys to understand how to design the physical network for the OpenStack.

At first, just want to have a brief introduction about OpenStack (in case you don’t know what it is). OpenStack is not a single vendor product, instead it’s an open source software developed by the community. They refer it as a cloud operating system. From my point of view, if you are familiar with VMware, OpenStack is somewhat like the vCenter. You can use OpenStack to manage different compute nodes, create and launch VMs (OpenStack refer it as instance) in those compute nodes. Of course, can also create different LAN segments (virtual in some sense) for the VMs.

In cloud environment, one of the important features is to support multi-tenants. OpenStack allows the administrator to create different tenants (which is referred as projects). As a tenant administrator, you can create different tenant networks in your project, and attach instances on different tenant network. Basically a tenant network is a layer 2 domain (like the traditional VLAN, or right now Cisco refer it as bridge domain in terms of the Cisco ACI). So VMs on different tenant networks should be in different subnets and need a layer 3 device to route traffic between them.

Following figure illustrates how OpenStack Web UI (dashboard) looks like after creating 2 tenant networks of each 2 VMs on it:

dashboard1
 

What I am going to discuss is the relationship of the tenant network and the provider (physical) network. Let’s first have a look on the whole network picture. Your compute nodes are actually connected to your physical network. Yet the VMs are not directly connected to the physical network, instead they are logically connected to an internal switch OVS within the compute node. So logically it’s like the following diagram (in fact it’s more complicate then that, internally it’s not only one single bridge, but I just want to simplify the picture so that networking people can understand it much quickly).

OstkNet


Now the question is, how does each tenant network mapped to the physical network? Recall that each tenant network (no matter within the same tenant or different tenants) is a layer 2 domain. So the most natural way is to use VLAN in the physical network for the layer 2 segregation – it’s true that one of the methods is to configure the OpenStack network component (they call it Neutron) to use different VLAN for different tenant network traffic.

However, besides VLAN, OpenStack provides 2 more solutions, please follow here to the part 2 of this blog.

 


 
Posted By Kepler Lam

In the DESIGN course, there is a question about how to bridge different network segments in different sites on to the same layer 2 network. One of the obvious solutions is using GRE tunnel between routers.

But here, I am not going to discuss how to configure GRE tunnel, as there are many documents on it. What I am going to discuss is, if you cannot change the router configuration (say if the router is not managed by you), then can you directly bridge 2 or even more Windows PC to the same layer 2 network? The solution is using the UBridge tool.

Long time ago, I have discussed how to use the Ethernet over UDP feature of UBridge. By using the new release, right now you can use the VXLAN encapsulation. Moreover, you can use the head end replication to bridge more than 2 PCs.

For example, if you have 3 different PCs on 3 sites and have IP address 10.10.1.10, 10.10.2.10 and 10.10.3.10 respectively, and want to bridge them all over subnet 10.20.1.0/24.

multisite
Then you can click here to download the UBridge tool, install the Winpcap. Create a loopback interface (or use other existing interface other than the one for the VTEP IP) in each PC. Configure the loopback interface of the 3 PCs to have IP address 10.20.1.1, 10.20.1.2 and 10.20.1.3 respectively.

Now, in PC1, execute:

C:\> ubdg 5000#V:E@10.10.1.10:10.10.2.10+10.10.3.10 5000#W:E

Select the loopback interface as prompted.

Similarly, under PC2:

C:\> ubdg 5000#V:E@10.10.2.10:10.10.1.10+10.10.3.10 5000#W:E

Similarly, under PC3:

C:\> ubdg 5000#V:E@10.10.3.10:10.10.1.10+10.10.2.10 5000#W:E

You should be able to ping among the loopback interfaces of all the PCs.

Some other design choose, such as it you don’t want to use the full mesh configuration, you can actually use the hub-and-spoke design by using the relay mode, you can further encrypt the traffic. Please refer to my other VXLAN blog entries.


 
Posted By Kepler Lam

In this last part of the blog entries, I will discuss the encryption feature of UBridge (open source tool under Windows platform) for VXLAN. As mentioned before, VXLAN just carry Ethernet frames over IP network without any encryption. As the original design of VXLAN is to be just used within Data Center, it is not a big deal without encryption.

But if you extend your VXLAN over a public network, encryption may become an important feature. As such a requirement, UBridge now supports encryption of the original Ethernet frame.

Currently, only pre share key (PSK) configuration using BlowFish encryption algorithm is being supported. Other stronger encryption algorithm maybe supported in future release. As the original goal is to make UBridge as an Ad Hoc tool that to be used example in testing environment, and not to be prolonged use.

Like other PSK technology, it’s susceptible for brute force attack. So use it at your own discretion.

encrypt
 

To configure encryption, you just need to define a PSK and configure it after the remote VTEP parameter separated by an asterisk. Then when UBridge sends Ethernet frame over that leg, the frame will be encrypted. Obviously, all other VTEP(s) also need to be configured with the same key.

Just follow my previous example of the provider and access mode VTEPs in Part 3, if you want to encrypt traffic between them. Only the corresponding leg need to be configure with a key. Say if you want to use ‘secret’ as the key.

Then for the provider mode legs::

  • Provider leg: 5000#V:E@192.168.150.35:0*secret:8472

Now execute ubdg:

C:> ubdg 5000#V:E@192.168.150.35:225.1.1.1:8472 5000#V:E@192.168.150.35:0*secret:8472

For the access mode VTEP,:

  • Access mode VXLAN leg: 5000#V:E@10.10.1.63*:130.240.65.110*secret:8000

Now execute ubdg:

C:> ubdg 5000#V:E@10.10.1.63*:130.240.65.110*secret:8000 5000#W:E


 
Posted By Kepler Lam

As discussed in part 1 blog entry, all VTEPs must use the same UDP port number within the same VXLAN. This is a hindrance to extending the VXLAN to some VTEPs behind a PAT device. Unless static NAT or port mapping is being used.

Furthermore, even with the unicast mode, which can be used among VTEPs over the Internet. But it still requires the VTEP addresses to be known from each other. That further prevents VTEP device to move around behind NAT devices, as the IP address is no longer static in such case.

It’s not surprising that the VXLAN has such limitations, since most of VTEP devices are static devices that not being move around. But with the UBridge which can be executed in Windows platforms, i.e. you can run it in your laptop PC and move around anywhere.

Now with a new innovation of dynamic VTEP, you can still able to bridge your Windows laptop even behind any PAT device over the Internet, just like a remote access VPN. Dynamic VTEP consist of two different VTEP modes:

  1. Provider mode VTEP (like a VPN server) – which allows a VTEP device to be configured without specifying the remote VTEPs. It dynamically learns the remote VTEP address and UDP port number.
  2. Access mode VTEP (like a VPN client) – which allows a VTEP device without a fixed global IP and be placed behind any PAT device.

Note that the provider mode VTEP still requires a global IP and a fixed port number, despite that it can be statically mapped behind NAT device.  

To configure a provider mode VTEP and relay to other VXLAN, you just need to create a leg and specific ‘0’ as the remote VTEP parameter. And create other legs for other VXLAN domain.

Example, to configure your Windows machine as a provider mode VTEP, suppose your PC has an IP address 192.168.150.35 which will be the VTEP address connected to the IP network. You need to relay remote access mode VTEP to an existing data center VXLAN that uses a standard multicast mode with multicast group address 225.1.1.1 using VNID 5000 and UDP port number 8472. (Of course, HER mode VTEPs can also be relayed).

dyn
 

Then create 2 legs::

  • Bridge to data center VXLAN: 5000#V:E@192.168.150.35:225.1.1.1:8472
  • Provider leg: 5000#V:E@192.168.150.35:0:8472

Now execute ubdg:

C:> ubdg 5000#V:E@192.168.150.35:225.1.1.1:8472 5000#V:E@192.168.150.35:0:8472

For the access mode VTEP, just put an asterisk on the local VTEP address parameter. For example, suppose your local PC is now behind a PAT router, and has an internal IP address 10.10.1.63. Suppose the above provider mode VTEP is mapped with a global IP 130.240.65.110 and UDP port 8000. You want to bridge a local loopback interface of your PC to the data center VXLAN. Then create 2 legs:

  • Access mode VXLAN leg: 5000#V:E@10.10.1.63*:130.240.65.110:8000
  • Winpcap leg for your loopback (UBridge will let you to select NIC to be bridged): 5000#W:E

Now execute ubdg:

C:> ubdg 5000#V:E@10.10.1.63*:130.240.65.110:8000 5000#W:E

Select the loopback interface when prompted.


 
Posted By Kepler Lam

As discussed before, original VXLAN standard defines that BUM frames are carried over IP multicast packets. But as many data center network is not multicast enable, so eventually different vendors have enhanced the VXLAN by using unicast mode (head end replication – HER).

UBridge supports both modes at the same time with one single VTEP address, so that you can extend a multicast mode VXLAN with other unicast VTEPs.

Before discuss the configuration of UBridge, lets take a look on the pros and cons of the these 2 modes:

  • Just imagine the overlay IP network that used to carry the Ethernet frames as a very large layer 2 switch. The BUM frames are those that need to be replicated to all outgoing ports in original switch design, then it makes sense to use IP multicast packets to carry those frames to multiple destinations. The pros is that the local VTEP doesn’t need to define all the other remote VTEPs, instead all VTEPs just need to join the same multicast group.
  • On the other hand, for unicast mode, all VTEPs need to know each others in order to replicate the BUM frames to other VTEPs. i.e the VTEPs are need to be fully mesh, which obviously causes scalability issues on numbers of VTEPs.

In order to solve the scalability issue, UBridge can bridge different VXLAN domain together as one single VXLAN. Here the term VXLAN domain refer to a set of VTEPs that either uses multicast mode or in a full mesh unicast configuration. UBridge can act as a relay (just like the route reflector of BGP), so that not all VTEPs need to know each others.

You can indefinitely cascade as many as VXLAN domains by UBridge to form a very large VXLAN.  
 
Now let me discuss the configuration. If you already follow some of my previous blog entries, then you should know that the UBridge uses the concept of session legs. In order to relay several VXLAN domains, you need to configure one leg for each domain.

Example, if your local PC has an IP address 10.10.1.63 which will be the VTEP address connected to the IP network. You want to bridge the following to VXLAN with VNID 5000 using default UDP port number 4789:

  • PC’c local loopback interface
  • A VXLAN that uses standard multicast mode with multicast group address 225.1.1.1.
  • And two other unicast mode VTEPs 10.10.1.33 and 10.80.1.1 which will be in full mesh with your local VTEP.
  • One more standalone VTEP 10.2.1.30 to the VXLAN. The VNID to be used is 5000.

relay2

Then you need to create 4 legs in which 3 of them belong to VXLAN type, one belongs to Winpcap type.

For the 3 different VXLAN legs:

  • Bridge to multicast VXLAN: 5000#V:E@10.10.1.63:225.1.1.1
  • Bridge to 2 full mesh VTEPs: 5000#V:E@10.10.1.63:10.10.1.33+10.80.1.1
  • Bridge to the standalone VTEP: 5000#V:E@10.10.1.63:10.2.1.30

For the Winpcap leg, if you know the Winpcap name of the loopback interface e.g. \Device\NPF_{5F97CBE5-7D16-48FB-BC77-0E0DE084F049}, then the leg will have the syntax:

5000#W:E@\Device\NPF_{5F97CBE5-7D16-48FB-BC77-0E0DE084F049}Or just use: 5000#W:E

Now execute ubdg:
C:> ubdg 5000#V:E@10.10.1.63:225.1.1.1 5000#V:E@10.10.1.63:10.10.1.33+10.80.1.1 5000#V:E@10.10.1.63:10.2.1.30 5000#W:E@\Device\NPF_{5F97CBE5-7D16-48FB-BC77-0E0DE084F049}


 
Posted By Kepler Lam

Currently, VXLAN is normally only used within the Data Center. It is rare to extend the VXLAN over the Internet. Since there are limitations on the original VXLAN specification that makes it hard to implement over the Internet.

However, by using the new released UBridge tool (inside the iptools project of sourceforge) wihich implements some unique enhanced features over the original specification, that let you easily extend the data center VXLAN anywhere, any time to any Windows PC.


anywhere
 

The original specification has few restrictions that haven’t been addressed for extending the VXLAN over the Internet. The restrictions are:

  1. Original VXLAN defines that BUM frames are carried over IP multicast packet. Yet, the Internet is not multicast enable.
  2. Although VXLAN used UDP to carry Ethernet frame over the IP network, original specification requires that all VTEPs must use the same UDP port number within the same VXLAN. This makes it difficult to extend VTEPs that behind a PAT router/firewall to bridge with the data center VTEPs. As the UDP port number may change after the router/firewall.
  3. The other obvious problem is the security issue, as VXLAN doesn’t encrypt the original Ethernet frame, thus it’s not safe to extend VXLAN over Internet.

To address the above issues, UBridge has the following enhancements:

  1. Instead of using multicast, UBridge can use unicast to replicate BUM frames to other VTEPs. Though this is not a new concept, as other venders also have such extension. However, UBridge can use one single VTEP IP address to support both multicast and unicast mode at the same time. It means that you can use the UBridge to relay a VXLAN in data center that uses multicast mode to other VTEPs on the Internet that uses unicast mode.
  2. A unique feature which is called provider (like server) and access (like client) mode VTEPs has been implemented. So that devices behind PAT device can act as access mode VTEP to initiate sending traffic to VTEPs that are in provider mode (usually in data center that need to be mapped with a global IP). Once the provider mode VTEP receives traffic from access mode VTEP, it will use the UDP port number of the access VTEP for returning traffic.
  3. Pre-share key encryption that uses the blowfish cipher is now supported, so that it can safely carry VXLAN traffic over the Internet.

Another important factor is that UBridge can be run in almost all kinds of Windows O.S. such as XP, Win 7/8, Win Server, so you can directly bridge your standalone PC to the VXLAN without using any other VXLAN gateway device. UBridge is open source freeware and execute in user mode. You don’t even need to install it, if you don’t need to bridge local NIC (e.g. just use it as a multicast and unicast relay), you can directly execute it on USB flash. Even if for the local NIC bridging, you need just installing the Winpcap but not the UBridge itself.

The coming blog entries will discuss the above features in detail.

 

 


 
Posted By Kepler Lam

In recent blog entries, I have discussed how to use the UBridge tool to bridge standalone Windows PC to any VXLAN over the IP network. UBridge is a open source tool that can run on most of Intel base Windows system such as XP, Windows 7, Windows 8 and other Windows servers.

You don’t even need to install it, all you need just to install the Winpcap. By using UBridge, you don’t’ need any VXLAN gateway switch or Linux system, as UBridge is like an internal switch that can directly bridge your PC’s NIC to the VXLAN.

As UBridge is implemented according to RFC, it’s fully compatible with the standard multicast transport for BUM frame. So you can use UBridge to integrate with other vender’s VXLAN implementation, such as NSX of VMware, N1000v of Cisco, Arista switch etc.

Besides, inside the release of iptools 0.98, UBridge also supports the Head End Replication (HER) using static configuration of remote VTEPs. It was tested to be compatible with Arista HER implementation.

Just like all other tunneling technology (e.g. GRE or IPsec), as there is additional overhead on the original Ethernet frame, so you may need to adjust the MTU of the NICs. Despite that, I have tested different applications by bridging the PCs using the UBridge. Even without changes any MTU size, most of the applications such as remote desktop, FTP and even TFTP still work fine.

However, that’s not all the case. One of the examples I want to show you is the telnet to the Arista switch over VXLAN. Using the setup as in this blog entry, I can smoothly telnet to the SVI which is actually on the VXLAN of the Arista switch using the Windows interface that being bridged.

To generate a large packet, just issue some commands that will generate a long output. A simple test is just type “show ?”. Now, the telnet just display few lines, then the whole telnet session will hang.

show1
 

Why is it? Most likely because of the MTU issue. As discussed before, VXLAN is a tunneling technology that uses the IP network to carry over the Ethernet frame. Below is a VXLAN packet.

vxlan_frame
 

Lets calculate the overhead. The original Ethernet frame is encapsulated over any frame that have another outer Ethernet header (14 bytes), IP header (20 bytes), UDP header (8 bytes) and VXLAN header (8 bytes). A total of 50 bytes.

Of course, if you can increase the MTU size of the transit IP network for 50 bytes, then that will be the best solution. Yet, that’s not always practical (e.g. due to the hardware limitation of the physical interface). Then the alternation is to decrease the MTU size of the VXLAN interface that being bridged.

So in the Arista switch, I lower the MTU size of the SVI. Lets check the original MTU size as below:

int_mtu

So change it to be 1450 bytes.

chg_mtu
 

Now restart another telnet session, the “show ?” works perfectly.

show2
 


 
Posted By Kepler Lam

In this example, I will demonstrate how to configure VXLAN HER (head end replication) of the UBridge to bridge with the Arista switch.  
The setup is as below:

  1. 2 different standalone Windows machine running the UBridge with physical interface IP (VTEP) address 10.10.1.33/24 and 10.10.1.63 respectively, their loopback interface with IP address 10.20.1.33//24 and 10.20.1.63/24 respectively  are to be bridged on VXLAN 5000.
  2. Arista switch with a routed port (interface E1) using IP address 10.10.1.70, but this address is not for the VTEP, since Arista doesn’t allow physical interface as the source interface of the VTEP. It requires using a loopback interface, so I use 10.80.1.1 on interface loopback 1 as the VTEP. This address needs to be routable among the VTEPs of the 2 Windows PC. A SVI on VLAN 100 with IP address 10.20.1.1/24 will be bridged to the VXLAN 5000.

VXLAN_HER

To summarize:

  • VNID is 5000
  • The VTEPs: 10.10.1.33 and 10.10.1.63 (standalone PC), 10.80.1.1 (Arista)
  • UDP port 8472
  • VXLAN subnet 10.20.1.0/24

Configuration of the Arista switch:

Step 1. Create the loopback interface

interface Loopback1
   ip address 10.80.1.1/32

Step 2. Create the VLAN 100 and SVI

vlan 100
interface Vlan100
   ip address 10.20.1.1/24

Step 3. Enable routing and configure the interface E1 as a routed port

ip routing
!
interface Ethernet1
   no switchport
   ip address 10.10.1.70/24

Step 4. Create the VXLAN and bridge with the VLAN 100

interface Vxlan1
   vxlan source-interface Loopback1
   vxlan udp-port 8472
   vxlan vlan 100 vni 5000
   vxlan flood vtep 10.10.1.33 10.10.1.63

On Windows PC:

Before executing the UBridge, need to make the Windows VTEP routable to the loopback interface of the Arista. To make it simple, just add a static route in 2 of the Windows PC:

C:\> route add 10.80.1.0 mask 255.255.255.0 10.10.1.70

Then execute the UBridge on PC 10.10.1.33 (please refer to my previous blog entry for the explanation of this command):

C:\>ubdg 5000#V:E@10.10.1.33:10.10.1.63+10.80.1.1 5000#W:E

Similarly, for PC 10.10.1.63:

C:\>ubdg 5000#V:E@10.10.1.63:10.10.1.33+10.80.1.1 5000#W:E

Now I can ping between the Windows PCs and the VLAN interface of the Arista switch.

You find that the Arista switch learns the VTEP address of the Windows, also the MAC address of the Windows loopback interfaces in the MAC address table.

Arista_HER
 

Thats not the end, you can follow my next blog entry for the discussion of the MTU size issue of VXLAN.

 


 

 

 
Google

User Profile
Kepler Lam
Hong Kong

 
Category
 
Archives
 
Visitors

You have 135051 hits.

 
Latest Comments