Browsed by
Tag: network

Part 2 – How to list vSwitch “MAC Address table” on ESXi host?

Part 2 – How to list vSwitch “MAC Address table” on ESXi host?

Comments 0 Comment

The other way to list MAC addresses of open ports on vSwitches on the ESXi host is based on net-stats tool.

Use this one-liner.

		
for VSWITCH in $(vsish -e ls /net/portsets/ | cut -c 1-8); do net-stats -S $VSWITCH | grep \{\"name | sed 's/[{,"]//g' | awk '{$9=$10=$11=$12=""; print $0}'; done

This is not a final word. 🙂

Part 1 – How to list vSwitch “MAC Address table” on ESXi host?

Part 1 – How to list vSwitch “MAC Address table” on ESXi host?

Comments 1 comment

Sometimes You need to list MAC addresses loged on host’s vSwitches to eliminate VM’s MAC address duplicates.

  1. Create a shell script:
    2. vi mac_address_list.sh
  2. Copy and past the code listed below:
    3. 
#!/bin/sh
#vmrale
for VSWITCH in `vsish -e ls /net/portsets/ | cut -c 1-8`
do
        echo $VSWITCH
        for PORT in `vsish -e ls /net/portsets/$VSWITCH/ports | cut -c 1-8`
        do
                CLIENT_NAME=`vsish -e get /net/portsets/$VSWITCH/ports/$PORT/status | grep clientName | uniq`
                ADDRESS=`vsish -e get /net/portsets/$VSWITCH/ports/$PORT/status | grep unicastAdd | uniq`
                echo -e "\t$PORT\t$CLIENT_NAME\t$ADDRESS"
        done
done
  3. Change the file’s permissions
    4. chmod 755 mac_address_list.sh
  4. Run the script
    5. ./mac_address_list.sh

Simple, but useful! 🙂

… but this is not the only one possible method 🙂

vSphere 6.5 – What’s new in networking  

vSphere 6.5 – What’s new in networking  

Comments 2 comments

 

In this article I will try to review all new network features.

1. vmknic gateway

  • Each VMKERNEL port can have its own Gateway.
  • This will make it easy for vSphere features to function seamlessly.
  • This eliminates the need for adding and maintaining static routes.

network1

Before vSphere 6.5 there was only one default gateway allowed for all VMKernel ports in an ESXi host. vSphere features such as DRS , iSCSI, vMotion, etc. leverage  that use VMKERNEL ports are constrained by this limitation. Many of the VMKERNEL ports were not routable without the use of static routes unless they belonged to a subnet other than the one with the default gateway. These static routes had to be manually created and were hard to maintain.

vSphere 6.5 provides the capability to have separate  default Gateways for every VMKernel port. This simplifies management of VMKernel ports and eliminates the need for static routes.

Prior to vSphere 6.5, VMware services like DRS, iSCSI, vMotion & provisioning leverage a single gateway. This has been an impediment as one needed to  add static routes on all hosts to get around the problem. Managing these routes could be cumbersome process and not scalable.

vSphere 6.5 provides capabilities, where different services use different default gateways. It will make it easy for end users to consume these feature without the need to add static routes. vSphere 6.5 completely eliminates the need for static routes for all VMKernel based services making it simpler and more scalable.

 

2.SR-IOV provisioning:

VM provisioning workflow prior to vSphere 6.5, for SR-IOV devices required the user to manually assign the SR-IOV NIC.  This resulted in VM provisioning operations being inflexible and not amenable to automation at scale. In vSphere 6.5 SR-IOV devices can be added to virtual machines like any other device making it easier to manage and automate.

 

3.Support for ERSPAN:

ERSPAN mirrors traffic on one or more “source” ports and delivers the mirrored traffic to one or more “destination” ports on another switch. vSphere 6.5 includes support for the ERSPAN protocol.

network2

 

4.Improvements in DATAPATH:

 vSphere 6.5 has data path improvements to handle heavy load. In order to process large numbers of packets, CPU needs to be performing optimally, in 6.5 ESXi hosts leverage CPU resources in order to maximize the packet rate of VMs.

network3

Where are the improvements being made ?

  1. VMXNET 3 optimization
    1. Using copy TX for small messages size (<=256B)
    2. Optimized usage of pinned memory
  2. Physical NIC improvements
    1. Native driver support for Intel cards (removes overhead of translating from VMkernel to VMKLinux data structures)
  3. CPU Scheduling Improvements
    1. Up to 8 separate threads can be created per vNIC
      • To enable on VM level add:

ethernetX.ctxPerDev = “3” to vmx file

 

Summary:

  • Optimizing code to improve efficiency
  • Allowing the ability to increase thread count for networking
  • Introducing support for more native drivers (Intel)
  • VMXNET3 enhancements

 

How to monitor virtual network – story about netflow in vSphere environment.

How to monitor virtual network – story about netflow in vSphere environment.

Comments 0 Comment

Before we start talking about NetFlow configuration on VMware vSphere let’s back to basics and review protocol itself. NetFlow was originally developed by Cisco and has become a reasonably standard mechanism to perform network analysis. NetFlow collect network traffic statistics on designated interfaces. Commonly used in the physical world to help gain visibility into traffic and understanding just who is sending what and to where.

NetFlow comes in a variety of versions, from v1 to v10. VMware uses the IPFIX version

of NetFlow, which is version 10. Each NetFlow monitoring environment need to have exporter ( device carrying  netflow flow’s) , collector (main component ) and of course some network to monitor and analyze 😉

Below You can see basic environment diagram:

netflow1

We can describe flow as tcp/ip packets sequence (without direction) that have common:

  • Input interface
  • Source IP
  • Destination IP
  • TCP/IP Protocol
  • Source Port (TCP/UDP)
  • Destination Port (TCP/UDP)
  • ToS IP

Note. vSphere 5.0 uses NetFlow version 5, while vSphere 5.1 and beyond uses IPFIX (version 10).

Ok, we know that distributed virtual is needed to configure NetFlow on vSphere but what about main component NetFlow collector – as usual we have couple options that we can simply divide in commercial software with fancy graphical interfaces and open source staff for admins that still like old good cli 😉

Below I will show simple implementation steps describing examples from both approach :

Manage engine NetFlow analyzer v12.2, more about software on https://www.manageengine.com/products/netflow/?gclid=CP3HlJbyv9ACFSQz0wod_UcDCw my lab VM setup:

  • Guest OS:Windows 2008R2
  • 4GB RAM
  • 2vCPU
  • 60 GB HDD
  • vNIC interface connected to ESXi management network

Installation (using embedded database just for demo purpose) is really simple and straight forward. Let’s start from starting the installer:

netflow2

 

  1. accept license agreements

netflow3

  1. choose installation folder on vm hdd

netflow4

  1. choose installation component option – for this demo purpose we go with simple environment with only one collector server, central reporting is not necessary

netflow5

  1. choose web server and collector services TCP/IP ports

netflow6

  1. provide communication details – again in this demo we have all components on one server and we can simply go with localhost

netflow7

 

  1. optional – configuration proxy server details

netflow8

  1. select database – on this demo i used embedded Postgresql , but if You choose MS database remember about ODBC config.

netflow9

  1. installation is quite fast – couple more minutes and solution will be ready and available to start work:

netflow10

 

… Web client like in VMware need couple CPU cycles to start 😉

netflow11

.. and finally we can see fancy ManageEngine NetFlow collector

netflow12

II) Open-Source netdump tool  – nfdump is distributed under the BSD license, and can be downloaded at: http://sourceforge.net/projects/nfdump/ my lab VM steup:

  • GOS: Debian 8.6
  • 4GB RAM
  • 2vCPU
  • 60 HDD
  • vNIC interface connected to ESXi management network

 

  1. We need to start from adding some sources to our debian distribution:

netflow13

  1. CLI Installation nfdump packet:

netflow15

netflow14

  1. Run simple flow capture to verify if collector is running and creating output flow statictics files (you can see that i use same tcp port 9995 and folder on my desktop as output destination):

netflow16

 

Ok, now it is time to back to vSphere and configure DVS to send network traffic to collector:

netflow17

 

  • IP Address: This is the IP of the NetFlow Collector
  • Port: This is the port used by the NetFlow Collector.
  • Switch IP Address: This one can be confusing – by assigning an IP address of here, the NetFlow Collector will treat the VDS as one single entity. It does not need to be a valid, routable IP, but is merely used as an identifier.
  • Active flow export timeout in seconds: The amount of time that must pass before
  • the switch fragments the flow and ships it off to the collector.
  • Idle flow export timeout in seconds: Similar to the active flow timeout, but for flows
  • that have entered an idle state.
  • Sampling rate: This determines the interval packet to collect. By default, the value is 0,
  • meaning to collect all packets. If you set the value to something other than 0, it will
  • collect every X packet.
  • Process internal flows only: Enabling ensures that the only flows collected are ones that occur between VMs on the same host.

And enable it at designated port group level:

netflow18

Finally we can create simple lab scenario and capture some ftp flow statistics between two vm’s on different ESXi :

netflow19

VM’s are running in dedicated vlan on the same DVS port group, collector is running on management network to communicate with vCenter and ESXi hosts. I used ftp connection to generate traffic between vm’s below examples output from two collectors (test ran separate as collector share the same ip)  :

 

ftp client on first vm:

netflow20

ftp server on second vm:

netflow21

flow statistics example from netdump:

netflow22

flow statistics from ManageEngine

netflow23

 

Network virtualization for Dummies – from VMware

Network virtualization for Dummies – from VMware

Comments 0 Comment

VMware shared a free ebook – Network Virtualization for Dummies. It’s the next book from seriers “for Dummies”. The main goal of the series is to describe technical aspects in the most clear and easy way as possible. I haven’t read this one yet but “Virtualization for Dummies” was quite good in my opinion.

If you are keen on network virtualization topic, I strongly encourage you to download it here.