The Blue Leader is a feature of StifleR Enterprise. On each Subnet the Red Leader is responsible for downloading the content across the WAN. On that and all the other subnets at the Location, Blue Leaders are automatically assigned. These Blue leaders are able to communicate with the other Leaders at the Location to facilitate the sharing of cached content between Peers across subnet boundaries at the local level.
A Blue Leader is basically a Red Leader (Assigned using the same selection process) but stripped of allowed WAN bandwidth consumption.
This feature requires Port 3703 (UDP) to be open for Multicast communication from Blue Leaders to
Clients on the local network segment. All leaders communicate with other leaders on ports 3704 and 3705 (UDP). Also check that the Microsoft BranchCache port is reachable and also the Blue Leader BranchCache port, which is typically assigned to the port one above the Microsoft BranchCache port number.
Note: At the time of writing the Leader communication Ports mentioned above are hard coded into the current version.
Note: BranchCache operates on port 80 by default, so the InterVLAN transfer will be handled on port 80 + 1 = 81. Both of these ports can be used by other applications so please ensure that this is configured properly. To avoid such issues our best practice recommendation is to use a custom port for BranchCache e.g. 1337 which would mean that you would then configure the InterVLAN port to be 1338 (default).
Blue Leaders do not generate V1 Content, only the Red Leaders make these hash calculations.
A subnet is an IPv4 network range that is calculated by the client using the IP Gateway and Subnet information from the network interface used to access the source data.
NOTE The code does include support for IPv6. However this has not been fully tested or enabled by default. If you require IPv6 support in your environment then please contact the 2Pint Support team and we can give you some specific advice around this functionality.
The correct adapter and path to use are calculated using the Windows API’s. StifleR is able to identify which gateway is the best one to use in order to access the data. StifleR is then able to calculate the subnet based on the first IP address configured on the adapter which is in the same network segment as the gateway that the client is configured to use. The reason for this complexity is that Issues arise as a NIC can have multiple IP addresses on different subnets. Confused? The following may help:
Consider a client machine that has both a Wireless 3G Card and a Cable plugged into a physical Ethernet Port. StifleR provides Windows with the IP address of the source host, and Windows returns the best interface to access the data. An inquiry is then made on that interface which is the best route (gateway) to the source. The best gateway that should be used to access the source data is then returned,. We then iterate through all the available IP Addresses on that interface and identify the first one that has the gateway set to the same as that previously identified. This is then used to calculate the network ID using the IP address and the subnet information. This is the network segment ID that is then send up to the StifleR Server. This should be the correct network ID to use, unless the network segment is broken and clients have switched over to 3G connections or other data networks.
A Location in StifleR management and configuration terms is a physical site that consists of two or more subnets that should be managed as a single entity for the purpose of bandwidth control. These subnets can be defined in many different ways, as VLAN tagging or just a different subnet network IDs. The concept of a Location is then used to group together those subnets into a single management unit. Typical use case would be a remote Location that has several network segments that are logically best managed together due to the fact that they share the same WAN connectivity back to the main Location where the source servers are located.
Creating a Location is as simple as linking together two or more network segments (subnets). This creates a Parent-Child relationship where the Parent subnet string is the identifying item for the Location.
A Location can be used as an administrative container to set a bandwidth limit for an entire remote site. Rather than having to set limits per subnet you can set a limit for all segments that share the same network infrastructure and WAN connection. These settings are configured via the ParentLocation class in WMI. StifleR will calculate the portion of bandwidth for each active Red Leader to use at any time according to the number of active Red Leaders in each Location. For example, if you have 3 network segments at a location but only 2 are actively downloading, the total allowed bandwidth for the Location will be split 50/50 between the two active segments. If another segment becomes active then each would receive 1/3 of the configured bandwidth for that location.
Without Locations configured the Server effectively treats each subnet as a Location which leads to each separate Red Leader trying to use the full link bandwidth.
In StifleR Enterprise each subnet not only has a Red leader assigned for each subnet, but StifleR also assigns a Blue Leader for each subnet. The Blue Leaders are able to facilitate BranchCache data to be shared across segment boundaries which further greatly reduces WAN traffic.
DO groups are set up through WMI by grouping clients together using the DO Group ID. You can set this using a generated GUID (PowerShell can do this for you) or you could use the Location IDs that you are already using in StifleR (these will be unique in your environment). StifleR will check to see if the client is DO capable (Windows Build 14393/Version 1607 and above), DO enabled (Download mode is not set to ”0”) and then check if a DO Group ID is present in the LocationData.xml file. Once StifleR has all of this information DO group membership can be ascertained and the DO group is then managed in the same manner as a location. Note that as the DO group is meant to be well connected and used specifically for P2P file sharing there is no Blue Leader functionality as all members should be local.
As mentioned in the Location segment above, several subnets can be bundled together into a single Location. This creates a many to one relationship between the Child subnet(s) and the Parent subnet. A Parent Location cannot (currently) be set to be a Child of another Location, which logically means that a Child cannot be made Parent for another Location. The “Parent” is simply used for management identification purposes. The Parent subnet is treated equally in all respects to any Child subnets at the Location.
It is suggested for logical tracking purposes that the lowest network ID be set as the Parent network ID. For instance: 10.1.1.0 should be configured as the Parent for 10.1.2.0 and 10.1.3.0.
As an example, we have three network segments, each a standard C class network with a 24 bit subnet mask:
Subnet A: 192.168.1.0/24
Subnet B: 192.168.2.0/24
Subnet C: 192.168.3.0/24
Once you configure Network A to be the Parent of Network B and C the following Location structure would be created:
Parent: Subnet A – 192.168.1.0
Child: Subnet B – 192.168.2.0
Child: Subnet C – 192.168.3.0
Typically, most configuration is still performed on a per subnet basis, and only a few changes are performed on the Location level, primarily the Target Bandwidth setting for the location. In the example above you would set a Target Bandwidth limit of 4096Kbits/s for the Location by setting the a limit on Subnet A (the Parent Subnet and therefore the Location Identifier for management purposes) StifleR will then dynamically apportion the bandwidth for each active Red Leader. If there is an active download current in each Subnet the StifleR Server service would automatically calculate and set a Target Bandwidth of 1365 (4096 / 3) for each of the Red Leaders at that location.
One Red Leader is assigned for each subnet unless StifleR Enterprise is used in which case each subnet is also assigned a Blue Leader which extends P2P functionality across subnet boundaries. It’s a 100% dynamic, automatic process which may change at any time during a download in order to optimize performance.
The figure below shows a StifleR Enterprise environment of 3 subnets, grouped into a Location, each with Leaders assigned.
The Red Leader assignment is completely dynamic and may switch several times during downloads in order to ensure the most efficient usage of WAN and LAN infrastructure.
Typically, the first machine in a subnet that connects to the StifleR Server will be assigned as the Red Leader. That Red Leader then remains as Red Leader until a more suitable candidate connects in which case the new Red Leader is assigned and the old Red Leader gracefully retires into network obscurity.
The following visualization depicts the flow between Server and Client.
StifleR checks and compares the following for each client as part of the assignment process:
If the current Red Leader has not responded to the Server within the configured threshold value
This typically occurs where there is a communication breakdown between a nominated Red Leader and the StifleR Server. The Server sends a message to appoint the Red Leader and the Red Leader must confirm the appointment within the threshold time. In the case a client cannot be assigned for a Location a Warning will be recorded in the Windows Event Log and the Server will move on to the next best nominee
If the Current Red Leader has been marked with the “NotLeaderMaterial” flag set to true
It may be undesirable for certain clients to become Red Leaders and in such cases this can be configured on the client (by setting the NotLeaderMaterial setting value to 1 (in the StifleR.ClientApp.exe.config file) or scripted on the Server by setting the NotLeaderMaterial WMI property on the Client instance
A Client with a higher priority job starts
The higher priority job Client will become Red Leader
A Client with the same priority but a higher BranchCache version connects to the Server
Higher BranchCache version Clients will be a preferred Red Leader as a V2 capable system Is able to utilize Deduplication during the download and can also provide a V1 hash to Windows 7 clients.(StifleR Enterprise feature only)
If a client connects that has downloaded more than the other clients over a configured threshold (10% more)
If the newly connected client holds more than 10% of the download in it’s cache than the current Red Leader it will become the preferred nominee and be appointed Red Leader
If we have more data transferred (10% more) and priority is same or higher and BranchCache version is same or higher but uptime is higher
As most machines at the start of a job ends up within the same range, this is the most common rule that applies. Most Red Leaders have a high uptime
Machine1 connects and the StifleR server detects that no other clients are online for that segment. The client is not marked with NotLeaderMaterial so it will be selected as Red Leader. Machine1 is not currently transferring any active jobs. (Windows Service Mode)
Machine4 connects on the same segment. It is transferring a Low priority job and will be assigned as Red Leader. Server Assigns Machine4 to be Leader and retires Machine1
Machine5 connects and is transferring the same job as Machine4. Machine5 has a higher uptime, which will rank it higher than Machine4, but it has also transferred more or less as much as Machine4. Machine4 stays as Red Leader but Machine5 gets a BITS policy that stops it from actively transferring any large amount of data. Machine4 gets the high bandwidth transfer throttle value defined for that subnet
Machine6 comes online and is transferring a high priority job. Machine6 becomes the new Red Leader and the downloads for Machine4 and 5 is then stopped as both receive a low BITS policy value
Machine7 comes online and is a higher BranchCache version (Windows 10=V2) than the others (Windows 7=V1). As Machine7 is also downloading this high priority job, even though it has transferred less than Machine6 it is assigned Red Leader
After Machine6 and 7 complete their downloads Machine 5 becomes Red Leader
As soon as Machine4 and 5 complete their downloads Machine7 becomes the Red Leader as it has the highest BranchCache version
No client is actively transferring any data and Machine7 stays the Red Leader
The following section shows a high level overview of how a Red Leader is used to transfer data and bandwidth throttling.
First off, for example a BITS job is started:
When the BITS job starts the StifleR clients send up statistics to the StifleR server. This provides the server with the information needed to select the best candidate to be Red Leader. In this case Client 1. As Client 1 downloads it will share content with the peer clients on the LAN. At the same time the peer clients 2 and 3 are automatically configured to throttle down their WAN BITS download speed leaving maximum bandwidth to the Content Server available for the Red Leader.
Once a Leader has been selected the StifleR server starts to send regular configuration messages to the Leader every x (configurable) seconds. The new leader uses these messages to set the (centrally configured) maximum bandwidth through an installed (Microsoft signed) filter driver. The message also includes flags that change other features such as InterVLAN transfers, BranchCache V1 content generation etc.
Each Leader reports up to the StifleR server at a regular interval (tracked as LastCheckIn Value). In the event that this communication stops for a period the StifleR server will automatically mark the failed Red Leader as NotLeaderMaterial and assign a new Red Leader to take over the WAN download.
Seamlessly the other peers will swap sources to continue the download from the new Red Leader.
