I recently have had network issues at one of my customers sites with DHCP, this tool was very useful in the troubleshooting phase of resolving the problem.
http://blog.mir.net/2014/10/rogue-dhcp-server-detection-free-tool.html
Tag Archives: Networking
VMWare Network Performance Checks
If packets are not being dropped and the data receive rate is slow, the host is probably lacking the CPU resources required to handle the load. Check the number of virtual machines assigned to each physical NIC. If necessary, perform load balancing by moving virtual machines to different vSwitches or by adding more NICs to the host. You can also move virtual machines to another host or increase the host CPU or virtual machine CPU.
Verify that VMware Tools is installed on each virtual machine.
If possible, use vmxnet3 NIC drivers, which are available with VMware Tools. They are optimized for high performance.
If virtual machines running on the same ESX/ESXi host communicate with each other, connect them to the same vSwitch to avoid the cost of transferring packets over the physical network.
Assign each physical NIC to a port group and a vSwitch.
Use separate physical NICs to handle the different traffic streams, such as network packets generated by virtual machines, iSCSI protocols, VMotion tasks, and service console activities.
Ensure that the physical NIC capacity is large enough to handle the network traffic on that vSwitch. If the capacity is not enough, consider using a high-bandwidth physical NIC (10Gbps) or moving some virtual machines to a vSwitch with a lighter load or to a new vSwitch.
If packets are being dropped at the vSwitch port, increase the virtual network driver ring buffers where applicable.
Verify that the reported speed and duplex settings for the physical NIC match the hardware expectations and that the hardware is configured to run at its maximum capability. For example, verify that NICs with 1Gbps are not reset to 100Mbps because they are connected to an older switch.
Verify that all NICs are running in full duplex mode. Hardware connectivity issues might result in a NIC resetting itself to a lower speed or half duplex mode.
Use vNICs that are TSO-capable, and verify that TSO-Jumbo Frames are enabled where possible.
Overview of the different network adapters for your VMWare Guests
- Vlance: This is an emulated version of the AMD 79C970 PCnet32- LANCE NIC, and it is an older 10 Mbps NIC with drivers available in most 32-bit guest operating systems except Windows Vista and later. A virtual machine configured with this network adapter can use its network immediately.
- VMXNET: The VMXNET virtual network adapter has no physical counterpart. VMXNET is optimized for performance in a virtual machine. Because operating system vendors do not provide built-in drivers for this card, you must install VMware Tools to have a driver for the VMXNET network adapter available.
- Flexible: The Flexible network adapter identifies itself as a Vlance adapter when a virtual machine boots, but initializes itself and functions as either a Vlance or a VMXNET adapter, depending on which driver initializes it. With VMware Tools installed, the VMXNET driver changes the Vlance adapter to the higher performance VMXNET adapter.
- E1000: An emulated version of the Intel 82545EM Gigabit Ethernet NIC. A driver for this NIC is not included with all guest operating systems. Typically Linux versions 2.4.19 and later, Windows XP Professional x64 Edition and later, and Windows Server 2003 (32-bit) and later include the E1000 driver.
Note: E1000 does not support jumbo frames prior to ESXi/ESX 4.1.
- E1000e: This feature emulates a newer model of Intel Gigabit NIC (number 82574) in the virtual hardware. This is known as the “e1000e” vNIC. e1000e is available only on hardware version 8 (and newer) virtual machines in vSphere 5. It is the default vNIC for Windows 8 and newer (Windows) guest operating systems. For Linux guests, e1000e is not available from the UI (e1000, flexible vmxnet, enhanced vmxnet, and vmxnet3 are available for Linux).
- VMXNET 2 (Enhanced): The VMXNET 2 adapter is based on the VMXNET adapter but provides some high-performance features commonly used on modern networks, such as jumbo frames and hardware offloads. This virtual network adapter is available only for some guest operating systems on ESXi/ESX 3.5 and later. Because operating system vendors do not provide built-in drivers for this card, you must install VMware Tools to have a driver for the VMXNET 2 network adapter available.
VMXNET 2 is supported only for a limited set of guest operating systems.
To determine if the the VMXNET 2 (Enhanced) adapter is supported for your guest operating system and vSphere ESXi version, see the VMware Compatibility Guide.
Notes:- You can use enhanced VMXNET adapters with other versions of the Microsoft Windows 2003 operating system, but a workaround is required to enable the option in the VMware Infrastructure (VI) Client or vSphere Client. If Enhanced VMXNET is not offered as an option, see Enabling enhanced vmxnet adapters for Microsoft Windows Server 2003 (1007195).
- Jumbo frames are not supported in the Solaris Guest OS for VMXNET 2.
- VMXNET 3: The VMXNET 3 adapter is the next generation of a paravirtualized NIC designed for performance, and is not related to VMXNET or VMXNET 2. It offers all the features available in VMXNET 2, and adds several new features like multiqueue support (also known as Receive Side Scaling in Windows), IPv6 offloads, and MSI/MSI-X interrupt delivery. For information about the performance of VMXNET 3, see Performance Evaluation of VMXNET3 Virtual Network Device. Because operating system vendors do not provide built-in drivers for this card, you must install VMware Tools to have a driver for the VMXNET 3 network adapter available.
VMXNET 3 is supported only for virtual machines version 7 and later, with a limited set of guest operating systems.
To determine if the the VMXNET3 adapter is supported for your guest operating system and vSphere ESXi version, see the VMware Compatibility Guide. - Notes:
- In ESXi/ESX 4.1 and earlier releases, jumbo frames are not supported in the Solaris Guest OS for VMXNET 2 and VMXNET 3. The feature is supported starting with ESXi 5.0 for VMXNET 3 only. For more information, see Enabling Jumbo Frames on the Solaris guest operating system (2012445).
- Fault Tolerance is not supported on a virtual machine configured with a VMXNET 3 vNIC in vSphere 4.0, but is fully supported on vSphere 4.1.
- Windows Server 2012 is supported with e1000, e1000e, and VMXNET 3 on ESXi 5.0 Update 1 or higher.
Raspberry PI Goodness
Over the festive season, I was fortunate enough to acquire a Raspberry PI. I have never had the opportunity to play with one of these, I had to do a bit of research into what I needed to do to get this up and running.
To get all the software I needed I went to the following website where you can download all the required “NOOBS” (New Out Of the Box Software) you require.
http://www.raspberrypi.org/downloads/
Once the operation system had been installed I needed to work out how to get access to the PI remotely. The following are the steps I took in order to make this work.
1, Enabling the GUI
Assuming that you are using Raspbian, it is actually rather simple to do this. Simply open the terminal, and type in the following:
sudo raspi-config
The following window should show up
Navigate to
boot_behaviour and click enter. This should make it so that the GUI interface start automatically.2, Configuring a static IP address
A. Checking Set Up
Boot into Raspian and log in (Username. pi, Password. raspberry), this will all be command line stuff, so no need to log in to the GUI.
First, we need to list the network interface we currently have available:
cat /etc/network/interfaces
The line . . . .
iface eth0 inet dhcp
Implies that we’re currently getting out IP address via DHCP, meaning it’s being dynamically registered by the router. This is what we want to change!
B. Gathering Information
Fist of all we need to grab some information from our router and Pi. There’s a couple of command we need to run to get this info. Have a pen and paper handy! . . .
ifconfig
This reveals your router information, the bit you want is after eth0 (the ethernet connection). . . .
eth0 Link encap:Ethernet HWaddr b8:27:eb:b3:fc:2c
inet addr:192.168.1.81 Bcast:192.168.1.255 Mask:255.255.255.0
Write down the following information. . .
inet addr – 192.168.1.81 (Pi’s Current IP Address)
Bcast – 192.168.1.255 (The Broadcast IP Range)
Mask – 255.255.255.0 (Subnet Mask Address)
We need a little more information before we proceed. Use the command. . .
netstat -nr
(route -n will give you the same info.)
We need:
‘Gateway‘ Address – 192.168.1.254
‘Destination‘ Address – 192.168.1.0
C. Editing Network Configuration
We now need to plug this information into the Pi’s network configuration file using a text editor. I always use nano text editor. . .
sudo nano /etc/network/interfaces
Simply change the line that reads:
iface eth0 inet dhcp
to
iface eth0 inet static
Then directly below this line enter the following
address 192.168.1.81
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
gateway 192.168.1.254
To clarify what each part means. . . .
address – The address you want to give your Pi, this can be any IP in the network range, but it’s usually advisable to go higher rather than lower, or you could end up logging different devices to the same IP! I’ve selected 192.168.1.81, as we’re already registered to that address (denoted by ‘inet addr‘), but this can be any IP address from the range192.168.1.1 to 192.168.1.255.
netmask – The ‘Mask‘ address we wrote down earlier.
network – The router IP address, this is the ‘Destination‘ Address was found earlier. You can also grab this off your router, it will say on the side somewhere.
broadcast – The ‘Bcast‘ address we wrote down earlier.
gateway – This is the ‘Gateway‘ address we found earlier.
So, it should look something like the above, but with your values! Remember to save before exit, CTRL+X (exit) then yes to save changes!
D. Re-check Static IP Configuration
Then we’ll need to reboot and check your changes. . .
sudo reboot
Log back in and run
ifconfig
Which should reveal your new settings. .
To double checks all is working as it should, ping your ‘Gateway‘ Address. . .
ping 192.168.1.254 -c 10
(the -c 10 command simply denotes that you want to ping it 10 times, if you forget to add this, it will ping the address continuosly. To stop it press CTRL+C)
This should ping successfully and all packets should be received. If something’s not right double check through all your IP addresses, and make sure you’re pinging the right address too. Remember you can always revert back to DHCP by reversing the steps.
3, Installing PI Software
First you will need to install XRDP server on the Raspberry Pi:
sudo apt-get install xrdp
Once installed reboot your Raspberry Pi. The xrdp process will auto load and start when you boot the Raspberry Pi.
As with SSH, If you want to fiddle (not recommended), you can start and stop different services with the /etc/init.d files. There are a number of commands, start, stop, restart etc. To obtain a list, type:
/etc/init.d/xrdp
For example, to check the current status of ssh:
/etc/init.d/xrdp status
We can currently see that the xrdp service is running, however I’m disconnected.
Malcolm Plested IT Blogs 