iPerf is a small, open-source, cli app designed to run on Linux (but has been ported to Windows) which is very useful in measuring throughput on a network.
It runs between two machines on a network, and has various options and features viewable on the man pages (or --help for Windows).
One machine acts as the server;
iperf -s
And the other machine acts as the client;
iperf -c [server ip]
Some useful options :
-t x : This sets the time (in seconds) to run the test for, default is 10 sec
-P x : The number of parallel transfers to run, this will generally increase throughput
-w xKB : TCP window size, increasing this will generally increase throughput as well
Example:
iperf -c 192.168.0.2 -t 30 -P 10 -w 256KB
Thursday 23 August 2012
Tuesday 14 August 2012
Cloning Linux VMs
The mac address in the system is tied to eth0, so we need to remove the mapping as when we clone the VM a new mac is generated.
- Edit /etc/udev/rules.d/70-persistent-net.rules to eth0 and correct MAC
- Reboot
- vi /etc/sysconfig/network-scripts/ifcfg-eth*
- onboot=yes
- NM_CONTROLLED=no
- BOOTPROTO=static
- IP address etc
- rename ifcfg-eth* to eth0 and ensure mac matches VMWare hardware ID and also the mac in persistent-net.rules
Cisco stack - rebooting/losing the master consequences
In a Cisco StackWise stack, you can have up to 9 switches connected together to create one logical switch. This gives 32Gbps bandwidth, and whilst this is cabled in a ring topology, it is essentially one large switch so STP does not come into effect.
A master switch is elected to manage the stack, this is done by various criteria (scroll to bottom), but generally a priority is set by the admin as to which, under normal circumstances, will become the master. Boot order is one to pay attention to, if you boot another switch before your prioritised master, this will take over as obviously the first to boot will take control.
The stack master's mac address also becomes the overall Stack Mac Address (Bridge ID), which has some considerations (show switch).
If you lose, or need to reboot the stack master, another switch will have to take over. This is again decided by priority primarily. When this happens, by default the mac address of the switch taking over, then becomes the overall stack mac address.
If you are using LACP etherchannels in your configuration, bear in mind the System ID (show lacp internal detail) is generated from the Stack Mac Address. If that Stack Mac changes, it will change the LACP System ID, which will cause the etherchannel(s) to reconverge, resulting in your etherchannels flapping and the devices in those etherchans losing connectivity. If you have a Windows cluster connected for example with teamed LACP interfaces, the duration of the reconvergance will result in the cluster failing.
To avoid this situation, you can instruct the stack not to change the Stack Mac Address if the master goes offline. The command in global config is stack-mac persistent timer 0
Setting the timer to 0 will keep the MAC indefinitely (or until the stack reboots), alternatively you can set a time in minutes, for example 10 minutes to allow a reboot of the master.
The only caveat to this would be if you were to reuse the master elsewhere in your network, ie. you took it offline for a reason, the duplicate MAC on the network could result in lost traffic.
A master switch is elected to manage the stack, this is done by various criteria (scroll to bottom), but generally a priority is set by the admin as to which, under normal circumstances, will become the master. Boot order is one to pay attention to, if you boot another switch before your prioritised master, this will take over as obviously the first to boot will take control.
The stack master's mac address also becomes the overall Stack Mac Address (Bridge ID), which has some considerations (show switch).
If you lose, or need to reboot the stack master, another switch will have to take over. This is again decided by priority primarily. When this happens, by default the mac address of the switch taking over, then becomes the overall stack mac address.
If you are using LACP etherchannels in your configuration, bear in mind the System ID (show lacp internal detail) is generated from the Stack Mac Address. If that Stack Mac changes, it will change the LACP System ID, which will cause the etherchannel(s) to reconverge, resulting in your etherchannels flapping and the devices in those etherchans losing connectivity. If you have a Windows cluster connected for example with teamed LACP interfaces, the duration of the reconvergance will result in the cluster failing.
To avoid this situation, you can instruct the stack not to change the Stack Mac Address if the master goes offline. The command in global config is stack-mac persistent timer 0
Setting the timer to 0 will keep the MAC indefinitely (or until the stack reboots), alternatively you can set a time in minutes, for example 10 minutes to allow a reboot of the master.
The only caveat to this would be if you were to reuse the master elsewhere in your network, ie. you took it offline for a reason, the duplicate MAC on the network could result in lost traffic.
Cisco StackWise election process
- User priority - The network manager can select a switch to be master.
- Hardware and software priority - This will default to the unit with the most extensive feature set. The Cisco Catalyst 3750 IP Services (IPS) image has the highest priority, followed by Cisco Catalyst 3750 switches with IP Base Software Image (IPB). Catalyst 3750-E and Catalyst 3750-X run the Universal Image. The feature set on the universal image is determined by the purchased license. The "show version" command will list operating license level for each switch member in the stack.
- Default configuration - If a switch has preexisting configuration information, it will take precedence over switches that have not been configured.
- Uptime - The switch that has been running the longest is selected.
- MAC address - Each switch reports its MAC address to all its neighbors for comparison. The switch with the lowest MAC address is selected.
Subscribe to:
Posts (Atom)