Product Documentation

Parent-Child Topology Deployment Using the MEP Protocol

Dec 26, 2016

NetScaler GSLB provides global server load balancing and disaster recovery by creating mesh connections between all the involved sites and making intelligent load balancing decisions. Each site communicates with the others to exchange server and network metrics through Metric Exchange Protocol (MEP), at regular intervals. However, with the increase in number of peer sites, the volume of MEP traffic increases exponentially because of the mesh topology. To overcome this, you can use a parent-child topology. The parent-child topology also supports larger deployments. In addition to the 32 parent sites, you can configure 1024 child sites.

The GSLB parent-child topology is a two-level hierarchical design with the following characteristics:

  • At the top level are parent sites, which have peer relationships with other parents.
  • Each parent can have multiple child sites.
  • Each parent site exchanges health information with its child sites and with other parent sites.
  • A child site communicates only with its parent site.
  • In a parent-child relationship for GSLB, only the parent site responds to ADNS queries. The child sites act as normal load balancing sites.
  • An ADNS service or DNS load balancing virtual servers should be configured only in the parent site.
  • A parent site can have a normal GSLB configuration, that is, services from local and all remote sites, but a child site can have local services only. Also, only the parent sites have GSLB virtual servers configured.


  • In a parent-child topology, the exchange of site metrics is initiated from the lower of two IP addresses. However, from NetScaler release 11.1 build 51.x, the parent sites initiate connections to the child sites, and not vice versa, because the parent sites have information about all the child sites in the GSLB setup.
  • In a parent-parent connection, the exchange of site metrics is still initiated from the lower IP of two IP addresses.
  • In a parent-child topology, GSLB services are not always required to be configured on a child site. However, if you have additional configuration such as client authentication, client IP address insertion, or other SSL-specific requirement, you must add an explicit GSLB service on the child site and configure it accordingly.
  • In a parent-child topology, the parent site and the child site can be on different NetScaler software versions. However, to use the GSLB automaticConfigSync option to synchronize the configuration across the parent sites, all parent sites must be on the same NetScaler software versions. If you are not using the automaticConfigSync option, then the parent site and the child site can be on different NetScaler software versions but make sure that you are not using any of the new features in the latest release. This is also applicable, in general, to two NetScaler nodes participating in GSLB.

Basic parent-child topology

In the diagram, Site P1 and Site P2 are parent sites in a peer relationship. Site P1C1 and P2C1 are the child sites of P1 and P2 respectively.

localized image

Setting up a parent-child configuration for GSLB

If you have a firewall configured at a GSLB site, make sure that port 3011 is open.

The following diagram displays a sample parent-child configuration.

localized image
  • The configuration of a child site includes the child site and its parent site, but no other parent or child sites.
  • Network metrics, such as RTT and persistence session information, are synchronized only across the parent sites. Therefore, parameters such as nwMetricExchange and sessionExchange are disabled by default on all the child sites.
  • To verify correct parent-child configuration, check the states of all the GSLB services bound to the parent sites.

To set up a parent-child configuration for GSLB by using the NetScaler command line

  1. On each parent site, enter the following command:

          add gslb site <siteName> [<siteType>] <siteIPAddress> [-publicIP <ip_addr|ipv6_addr|*>]


          # add gslb site GSLB_Site1 - publicIP

     2.    On each child site, enter the following command:

          add gslb site <siteName> [<siteType>] <siteIPAddress> [-publicIP <ip_addr|ipv6_addr|*>]

          [-parentSite <string>]


          # add gslb site Site1_child1 1 -publicIP -parentSite GSLB_Site1

For a complete example of a parent-child configuration, using the command line interface, see Example of a Complete Parent-Child Configuration, Using the NetScaler CLI.


If the load balancing virtual server IP address is a private IP address and the public IP address is different from this IP address, you need to configure a GSLB service for the local load balancing virtual server on the child site. This is required for statistics collection between the parent and the child site.

On the child site, at the command prompt, type:

add gslb service <name> <private IP/lb vserver IP> http 80 –sitename <childsite name> -publicip <public IP of LB vserver>


add gslb service Service-GSLB http 80 -GSLB_Site11 site 11_lb1

Where is a private IP address of the load balancing virtual server and is a public IP address of the load balancing virtual server.    

Backing UP a Parent Site

Note: This feature was introduced in NetScaler release 11.1 build 51.x.

The backup parent site topology is useful in scenarios wherein a large number of child sites are associated with a parent site. If this parent site goes DOWN, all of its child sites become unavailable. To prevent this, you can now configure a backup parent site to which the child sites can connect if the original parent site is DOWN.

When a parent site goes DOWN, the other parent sites in the GSLB setup look up the backup chain of the peer parent. The parent site with the highest preference adopts the child sites of the parent that went DOWN. The new parent then initiates a connection with the child site. A child site can accept or reject the connection after evaluating its existing connections and the information in a backup list.

When the original parent site is back UP, it tries to establish connections with its child sites that have migrated to a different parent. When a connection attempt is successful, the child site is reassigned to its original parent site.

Note: Only parent sites can be configured as backups, and this configuration can only be done at the parent site.

Consider the configuration shown in the following figure, in which:

  • SiteP1, SiteP2, and SiteP3 are the parent sites.
  • Child_site1, Child_site2, and Child_site3 are the child sites of SiteP1, SiteP2, and Site P3 respectively.
  • Backup parent sites;
    • SiteP1 backup parents - SiteP2 (higher preference) and Site P3
    • SiteP2 backup parents – SiteP3 (higher preference) and Site P1
    • SiteP3 backup parents – SiteP1 (higher preference) and Site P2

Note: For illustration purposes, the figure shows only one backup parent for each parent site.

localized image

The following list summarizes the behavior of the parent and child sites under various scenarios:

  • Scenario 1: SiteP1 goes DOWN.
    • SiteP2 and SiteP3 detect that SiteP1's MEP connection is DOWN. SiteP2 is higher in the preference list of backup parents for SiteP1, so it tries to initiate a connection to Child_site1. SiteP3 assumes that Child_site1 is now the child site of parent SiteP2.
    • SiteP2 sends Child_Site1 the list of SiteP1’s backup parents (SiteP2 and SiteP3) to Child_site1. Child_site1 uses the list to decide whether to accept or reject the connection from SiteP2. It accepts the connection and becomes a child of SiteP2.
    • When SiteP1 is back UP, it sends Child_site1 a connection request. The new request takes precedence and Child_site 1 migrates to SiteP1.
  • Scenario 2:  Only the MEP connection between SiteP1 and SiteP2 has gone DOWN. Child_site1 rejects SiteP2's connection request, because its parent, SiteP1, is still UP.
  • Scenario 3: SiteP3 and Child_Site1 detect that SiteP1 is DOWN, and the MEP connection between SiteP3 and SiteP2 is also DOWN. However, Site P2 detects that SiteP1 is UP, and the MEP connection between SiteP1 and SiteP2 is UP.
    • SiteP2 does not take any action.
    • SiteP3 checks SiteP1’s backup list and finds that SiteP2 has a higher preference than SiteP3. But SiteP2 is DOWN, so SiteP3 tries to establish a connection with Child_site1. Child_site1 has detected that SiteP1 is DOWN, so it accepts SiteP3's connection request.
    • Now the connection between SiteP1 and SiteP2 goes DOWN. SiteP2 checks SiteP1’s backup list and finds itself as the most preferred backup, so it tries to connect to Child_site1. Child_site1 evaluates the new connection request based on SiteP1’s list and finds SiteP2 as the most preferred backup, so it migrates to SiteP2 from SiteP3.

To configure a backup parent site by using the command line interface

At the command prompt type:

set gslb site <sitename> -backupParentlist <bkp_site1> <bkp_site2> …<bkp_site5>


  • You cannot add a new site as a backup parent. You must first add all the sites, and then configure the site as a backup parent.
  • To remove a backup parent, you must use the unset command, which unsets all the sites that were previously configured as backup parent sites.

To configure a backup parent site by using the NetScaler GUI

  1. Navigate to ConfigurationTraffic Management > GSLB > Sites.
  2. Add a new site or select an existing site.
  3. Choose the Backup Parent Sites option box while creating or configuring the GSLB site.