Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

The DFP makes its connection with BloxOne Cloud based on the following rules and conditions:

  • By default, the DFP has provisioned the following four IPv4 global addresses. The DFP monitors the health status of these addresses and sends DNS requests to the first available and healthy address in the following order. In other words, if the first address (52.119.41.100) is available but has an unhealthy status, it moves on to the second address (103.80.6.100) to establish a connection with BloxOne Cloud, provided that the address is reachable and has a healthy status. Note that the DFP performs health check on these addresses every 30 minutes. 
    1. 52.119.41.100
    2. 103.80.6.100
    3. 52.119.40.100
    4. 103.80.5.100
  • The first two addresses are provisioned under AWS Anycast and GSLB (Global Server Load Balancer), so a DNS client can connect to the nearest AWS entry location. Once a connection is established, the client is routed via AWS GSLB to the nearest PoP (Point of Presence). If the nearest PoP is not reachable, the client is forwarded to another PoP based on the rules described in the first bullet.
  • The last two addresses are routed using Anycast only, and they use a different architecture so the traffic is routed via third-party networks to a PoP.
  • If you have defined a PoP for the DFP, only AWS addresses for that PoP are used while everything else works as described in the previous bullets. This connection creates a fail-open architecture. For example, if the PoP in Tokyo is provisioned for the DFP and it is not available, the traffic will be automatically routed to the next PoP based on the user/DFP location.

The following illustration describes the connection rules for the DFP:



For more information, see the following:

  • No labels