Difference between revisions of "Multicasting"
m (→STP/Portfast/RSTP/MSTPt) |
m (→STP/Portfast/RSTP/MSTPt) |
||
Line 52: | Line 52: | ||
* If the clients start imaging then it seems that all of your multicast settings are correct and the problem may lie within fog configuration if it doesn't work then you need to check your router settings | * If the clients start imaging then it seems that all of your multicast settings are correct and the problem may lie within fog configuration if it doesn't work then you need to check your router settings | ||
− | ===STP/Portfast/RSTP/ | + | ===STP/Portfast/RSTP/MSTP=== |
{{:STP/Portfast/RSTP/FMSTP}} | {{:STP/Portfast/RSTP/FMSTP}} | ||
Revision as of 19:47, 15 January 2015
- Multicasting in FOG uses UDPcast to send a single image to multiple computers using only slightly more bandwidth than sending the image to a single computer or unicast. Multicasting in FOG may require special switch configuration. A multicast will not begin until all members are ready to begin by default. This can be changed by editing UDPSENDER_MAXWAIT in /opt/fog/service/etc/config.php which is in seconds.
Contents
Queuing
- FOG uses a simple queuing system to prevent its storage servers from being overworked. If you have a single FOG storage node in FOG with a queue size of 10, then this means that if you unicast an image to 30 computers, only the first 10 computers will be imaged. The other 20 computers will be waiting "in queue" for an open slot. What will be seen on the client side is the following:
- This queue system allows for the IT staff to start tasks for hundreds or thousands of computers and let FOG manage the clients so the servers don't get overwhelmed with client requests.
Test Multicasting
- Environment:
- FOG server
- Two or more identical computers
- Ethernet hub or FastEthernet switch in same VLAN.
- View Multicast status on server use tty2 or /opt/fog/log/multicast.log
- Overall image time will be slower than unicast on same hardware and same image because unicast is gunzip(unzip) at client level, multicast in gunzip at server level.
- If errors persist in test environment post log in forum.
Device Configurations
Troubleshooting
- Taken from this forum thread.
- On your server open up terminal and kill any running udpcasts by typing
#* hi sudo killall udp-sender
- now run this command
udp-sender --file /opt/fog/log/multicast.log --ttl 1
- you should see broadcasting control to: and it should be the highest address of the subnet your fogserver is on
- the line before that should say your fogserver ipaddress and the interface
- Now boot up 1 client go to your pxe menu and select debug mode. Do this on the same subnet if possible. Type in:
udp-receiver --mcast-rdv-address yourfogserver
- On your server you should see that 1 client connected and then you can press any key to start the transfer
- On your client you should see the contents of your multicast log file scrolling by the screen. You can press ctrl-C to stop it.
Hopefully that worked. Now we need to test 2 clients.
- Run the command on your server again but this time change the --ttl 1 to --ttl 32
- You will see that this time your broadcast control is 224.0.0.1 this is the multicast address
- Boot both clients in debug mode and run the client command on each. Once you see that both clients have connected to the server press any key and see if the log file transfers again to both machines this time. If it does not then chances are something is not setup properly in your router possibly routing tables or multicast settings.
If it does work then good lets try one more step
- On your server run this:
gunzip -c "/images/anyimagename" | /usr/local/sbin/udp-sender --min-receivers 2 --portbase 9000 --interface yourInterface --half-duplex --ttl 32
- Now boot up 2 clients in debug mode and enter
udp-receiver --portbase 9000 --mcast-rdv-address fogserverIP | partimage -f3 -b restore /dev/sda stdin
you might need to change /dev/sda to your correct harddrive if it's different use fdisk -l to find out
- If the clients start imaging then it seems that all of your multicast settings are correct and the problem may lie within fog configuration if it doesn't work then you need to check your router settings
STP/Portfast/RSTP/MSTP
STP
- What is STP?
- The Spanning Tree Protocol (STP) is a network protocol that ensures a loop-free topology for any bridged Ethernet local area network. The basic function of STP is to prevent bridge loops and the broadcast radiation that results from them. Spanning tree also allows a network design to include spare (redundant) links to provide automatic backup paths if an active link fails, without the danger of bridge loops, or the need for manual enabling/disabling of these backup links.
Port Fast
- What is Portfast?
- The time Spanning Tree Protocol (STP) takes to transition ports over to the Forwarding state can cause problems. PortFast is a Cisco network function which can be configured to resolve this problem. This factor of time is not an issue for many people, but it can cause problems for some. (i.e. Fog imaging) You may see this issue is with Pre-Boot Execution (PXE) devices, such as Windows Deployment Services. PortFast is the solution to this problem of delays when client computers are connecting to switches. PortFast is not enabled by default. With PortFast enabled on a port, you effectively take the port and tell spanning tree not to implement STP on that port.
RSTP
- What is Rapid STP(RSTP)?
- The 802.1D Spanning Tree Protocol (STP) standard was designed at a time when the recovery of connectivity after an outage within a minute or so was considered adequate performance. With the advent of Layer 3 switching in LAN environments, bridging now competes with routed solutions where protocols, such as Open Shortest Path First (OSPF) and Enhanced Interior Gateway Routing Protocol (EIGRP), are able to provide an alternate path in less time. Cisco enhanced the original 802.1D specification with features such as Uplink Fast, Backbone Fast, and Port Fast to speed up the convergence time of a bridged network. The drawback is that these mechanisms are proprietary and need additional configuration. Rapid Spanning Tree Protocol (RSTP; IEEE 802.1w) can be seen as an evolution of the 802.1D standard more than a revolution. The 802.1D terminology remains primarily the same. Most parameters have been left unchanged so users familiar with 802.1D can rapidly configure the new protocol comfortably. In most cases, RSTP performs better than proprietary extensions of Cisco without any additional configuration. 802.1w can also revert back to 802.1D in order to interoperate with legacy bridges on a per-port basis. This drops the benefits it introduces.
MSTP
- What is Multiple STP (MSTP)?
- The Multiple Spanning Tree Protocol (MSTP), originally defined in IEEE 802.1s and later merged into IEEE 802.1Q-2005, defines an extension to RSTP to further develop the usefulness of virtual LANs (VLANs). This Multiple Spanning Tree Protocol configures a separate Spanning Tree for each VLAN group and blocks all but one of the possible alternate paths within each Spanning Tree. If there is only one Virtual LAN (VLAN) in the network, single (traditional) STP works appropriately. If the network contains more than one VLAN, the logical network configured by single STP would work, but it is possible to make better use of the alternate paths available by using an alternate spanning tree for different VLANs or groups of VLANs.
What do I enable and disable?
- If you don't need STP all these options should be disabled already and nothing should need to be done. (DISABLE ALL)
- If you have to use STP, to get (ipxe/dhcp) Fog (v1.x.x) working correctly you will need to ENABLE PORTFAST OR ENABLE RSTP.
- Currently MSTP is untested with Fog but may be useful for networks with multiple VLANS.
More information on Spanning Tree Protocol
http://en.wikipedia.org/wiki/Spanning_Tree_Protocol#Multiple_Spanning_Tree_Protocol
Please Wait
- Hang at the "Please Wait" screen:
- Verify the host name (without dns suffix) is listed in the /etc/hosts file to the actual IP address (not 127.0.0.1)
example: "192.168.0.77 myfogserver"
- Check the MySQL details in "/opt/fog/service/etc/config.php" are correct.
- If not, correct them (they should be the same as in /var/www/fog/commons/config.php) and restart the service
$sudo /etc/init.d/FOGMulticastManager restart
Kill Multitasking
- If you wish to force kill all the multicasting sessions please do BOTH the following
- Remove any sessions running in the sql database
mysql -u root <-p password> fog truncate table multicastSessions; truncate table multicastSessionsAssoc; exit;
- Stop any udp senders that may be running on the server
sudo service FOGMulticastManager stop sudo killall udp-sender sudo killall udp-sender sudo killall udp-sender sudo service FOGMulticastManager start