CDN 52000 0001 GUENC - Technote UseOfAnycastInVelocixCDN

Velocix Media Delivery
Platform
Use of Anycast in a Velocix

CDN
Document ID: CDN-52000-0001-GUENC
Version 49.0-1 | Release 5.2
Issue Date: April 2020
Velocix - Proprietary and confidential.

Use pursuant to applicable agreements
Use of Anycast in a Velocix CDN Version 49.0-1
Copyright and Confidentiality

The contents of this document are proprietary and confidential property of Velocix
l This document is provided subject to confidentiality obligations of the applicable
agreement(s).
l This document is intended for use by Velocix customers and collaborators only for the
purpose for which this document is submitted by Velocix. No part of this document may
be reproduced or made available to the public or to any third party in any form or means
without the prior written permission of Velocix. This document is to be used by properly
trained professional personnel. Any use of the contents in this document is limited strictly
to the use(s) specifically created in the applicable agreement(s) under which the
document is submitted. The user of this document may voluntarily provide suggestions,
comments or other feedback to Velocix in respect to the contents of this document
("Feedback"). Such Feedback may be used in Velocix products and related
specifications or other documentation. Accordingly, if the user of this document gives
Velocix Feedback on the contents of this document, Velocix may freely use, disclose,
reproduce, license, distribute and otherwise commercialize the feedback in any Velocix
product, technology, service, specification or other documentation.
l Velocix operates a policy of ongoing development. Velocix reserves the right to make
changes and improvements to any of the products and/or services described in this
document or withdraw this document at any time without prior notice.
l The contents of this document are provided "as is". Except as required by applicable law,
no warranties of any kind, either express or implied, including, but not limited to, the
implied warranties of merchantability and fitness for a particular purpose, are made in
relation to the accuracy, reliability or contents of this document.
l VELOCIX SHALL NOT BE RESPONSIBLE IN ANY EVENT FOR ERRORS IN THIS
DOCUMENT or for any loss of data or income or any special, incidental, consequential,
indirect or direct damages howsoever caused, that might arise from the use of this
document or any contents of this document.
l This document and the product(s) it describes are protected by copyright according to
the applicable laws.
l Velocix is a registered trademark of Velocix Solutions. Other product and company
names mentioned herein may be trademarks or trade names of their respective owners.
Release 5.2 Velocix - Proprietary & Confidential Page 2

Contents
1 What's in this document 4
1.1 What's not in this document 4
2 Use of Anycast in a Velocix CDN 5
3 Anycast in an ISP network 7
4 Route Withdrawal 9
4.1 Link-state 9
4.2 HTTP Probe 9
5 Anycast vs. HA in DNS-based Redirection 10
5.1 Anycast in DNS-based Redirection 10
5.2 HA in DNS-based Redirection 12
5.3 Comparison 13
6 Anycast vs. HA in HTTP-based Redirection 15
6.1 Anycast in HTTP-based Redirection 15
6.2 HA in HTTP-based Redirection 17
6.3 Comparison 18
7 Anycast vs. HA in Console (Web Portal) 19
7.1 Anycast in Console (Web Portal) 19
7.2 HA in Console (Web Portal) 19
7.3 Multiple HA in Console (Web Portal) 19
7.4 Externally Load-Balanced Console (Web Portal) 20
7.5 Comparison 20
8 Conclusion 21

1 What's in this document

This documents covers the various options for making a Velocix CDN survive the highly
unlikely event of a complete Service Node failure. It covers the use of Anycast and High
Availability IP addresses, and the advantages and disadvantages of each approach, in
various uses of the CDN.
1.1 What's not in this document

This document does not cover any of the following topics:
l How an ISP manages their dynamic routing cloud

2 Use of Anycast in a Velocix CDN

In a typical Velocix CDN configuration, there would be four classes of addresses:
l The Anycast Address - served by any Routing Application in the CDN
l High Availability (HA) Service Node Address - served by any Routing Application in a
Service Node
l Unicast Service Address - served by a single Routing Application
l Delivery Address - served by a single Delivery Application
You do not have to use Anycast in your Velocix CDN; but the pros and cons should be
carefully considered. There are three places where Anycast can help your CDNs
availability:
l DNS-based Redirection
l HTTP-based Redirection
l The Asset Control Portal (Console)
You can use Anycast for all, none, or some of the above.

Some Definitions:
l A consumer is a human. They wish to consume some content off the CDN
l A client is a piece of software. The consumer interacts with the client
l A user is an authorised individual, either from the ISP, or a content-providing customer
of the ISP

3 Anycast in an ISP network

The Anycast address is advertised by the router(s) upstream of each Service Node. The
ISPs network core would normally have two competing routes for this address - to each
Service Node. Usually this results in some parts of the ISP network routing to SN1, and
others to SN2.
In some cases the ISP network may not have sufficient metrics to determine the "best"
route from everywhere in the network, and always prefer one SN over the other - until the
preferred route is withdrawn. The mechanism is the same as if there were multiple paths
through the ISP network to the same physical location.
Anycast routing, with split horizon

Anycast routing, without split horizon

4 Route Withdrawal
It is important to ensure that if a Service Node fails, the router upstream of it withdraws its
advertisement promptly - and re-advertises it on recovery. For this to work, the router must
have a mechanism whereby it can know if the Service Node is properly operational.
For a Service Node to be "failed" it must have lost all of its Routing Applications (usually
there are two) in that node. This would usually be due to a large-scale failure such as loss of
power to the Service Node, or a network failure isolating the Service Node (which would
presumably isolate the upstream router, automatically withdrawing the Anycast route).
The Velocix CDN supports two mechanisms to detect Service Node failure. It is possible to
change mechanisms on a live system, if you are careful.
4.1 Link-state
This method is very simple, and may not work with all routers. Most routers will, if link is lost
on a port, withdraw any routes that go via that port (assuming they don't have another path
to it). Should power fail to a Service Node, or the Ethernet cables get accidentally removed,
etc., then there would be no link on the cable coming out of the Service Node chassis. If that
were directly connected to the router, the router would then see the loss of link.
This method is not appropriate if the link remains up at the router (maybe because of
switching infrastructure between the Service Node and its router) or if the router does not
automatically withdraw the route on link failure.
Link-state detection is usually the least-preferred method.
4.2 HTTP Probe

If the upstream router supports conditional route advertisement based on tests, then it can
be configured to probe the Routing Applications via HTTP. There is a specific request that
the router (if in the whitelist) can make, that will return a "200 OK" message if the Service
Node believes itself to be operational, and "503 Unavailable" or fail to establish the TCP
session, if not operational.

5 Anycast vs. HA in DNS-based

Redirection
DNS-based redirection is used when the client is sent to the appropriate Delivery
Application based on the result of a DNS request. That is, the client will receive a DNS
response for the requested hostname, which will contain the IP addresses of a number of
(usually two) Delivery Applications. For more information about DNS-based Redirection,
see the Routing Requests to Delivery Applications technical note.
DNS-based redirection can use the Anycast address as the first point-of-entry, or it can use
the High Availability Service Node Address of each Service Node.
For the following examples, assume:
l There is a Velocix CDN with two Service Nodes
o It is "cdn.example.net"
o There is a website object called www.example.com, which is identified as "wp-1234"
l The first Service Node has a public IP address range of 192.0.2.0/28

o Of which, 192.0.2.4 is the High Availability Service Node Address
o 192.0.2.5 is the Unicast Service Address of the first Routing Application
o 192.0.2.6 is the Unicast Service Address of the second Routing Application
l The second Service Node has a public IP address range of 198.51.100.0/28

l The Anycast address, if used, is 203.0.113.1

o When referred to as a network, it is 203.0.113.1/32
5.1 Anycast in DNS-based Redirection

When using Anycast for DNS-based Redirection, the DNS is configured like:
l In example.com:
www IN CNAME wp-1234.id.cdn.example.net.
l In example.net:
ns0.cdn IN A 203.0.113.1
cdn IN NS ns0.cdn
Here, when a consumer wishes to browse to www.example.com (or otherwise use it):
l The client sends a DNS request for www.example.com to its upstream DNS Server (1)
l The consumers' upstream DNS Server (the recursive server) checks with the root
servers to find out which DNS Server(s) are responsible for example.com (2a and 2b)
l The consumers upstream DNS Server asks the example.com DNS Server(s) for
www.example.com (3)
l The example.com DNS Servers respond saying look at wp-1234.id.cdn.example.net
instead (4)

l The consumers upstream DNS Server checks with the root servers to find out which
DNS Server(s) are responsible for example.net (5a and 5b)
l The consumers upstream DNS Server asks the example.net DNS Server(s) for wp-
1234.id.cdn.example.net (6)
l The example.com DNS Server(s) say to check with ns0.cdn.example.net (203.0.113.1)
(7)
l The consumers upstream DNS Server asks 203.0.113.1 for wp-
l The Velocix CDN responds with the IP addresses of some appropriate Delivery
Applications, and that the information can be used for sixty seconds (9)
l The consumers upstream DNS Server tells the client to use the provided Delivery
Application addresses (10)
l The client connects to one of the Delivery Applications, and requests the content (11)
DNS-based Routing with Anycast

During normal operation, the Service Node a particular request is routed to is decided by
the ISP network structure.
If a Service Node should fail, there are four possibilities:
l A client using a consumer DNS Server may get a cached result, or
l The Anycast address may still be (erroneously) still advertised (probably due to
convergence delay) as via the failed Service Node, and there is no response. The
recursive DNS server tries again a couple of seconds later, and if the erroneous route
has disappeared, the request goes to the other (available) Service Node. The client will
see a small (~2s, usually) delay. Or,
l As previously, but the erroneous Anycast address route stays active for long enough for
the recursive DNS server to give up on the request. The client gets a DNS error - the
consumer may need to press reload. Or,

l The Anycast address route to the failed Service Node has been withdrawn, and the
request goes to the remaining Service Node.
The DNS messages involved are very small, so they will not cause a transition from UDP
DNS to TCP DNS. As such, there is no problem with the Anycast route changing from one
active Service Node to another during active requests.
5.2 HA in DNS-based Redirection

When using HA for DNS-based Redirection, the DNS is configured like:
l In example.com:
www IN CNAME wp-1234.id.cdn.example.net.
l In example.net:
ns1.cdn IN A 192.0.2.4
ns2.cdn IN A 198.51.100.4
cdn IN NS ns1.cdn
cdn IN NS ns2.cdn
Here, when a consumer wishes to browse to www.example.com (or otherwise use it):
l The client sends a DNS request for www.example.com to its upstream DNS Server (1)
l The consumers' upstream DNS Server (the recursive server) checks with the root
servers to find out which DNS Server(s) are responsible for example.com (2a and 2b)
l The consumers upstream DNS Server asks the example.com DNS Server(s) for
www.example.com (3)
l The example.com DNS Servers respond saying look at wp-1234.id.cdn.example.net
instead (4)
l The consumers upstream DNS Server checks with the root servers to find out which
DNS Server(s) are responsible for example.net (5a and 5b)
l The consumers upstream DNS Server asks the example.net DNS Server(s) for wp-
l The example.com DNS Server(s) say to check with ns1.cdn.example.net (192.0.2.4) or
ns2.cdn.example.net (198.51.100.4) (7)
l The consumers upstream DNS Server asks either 192.0.2.4 or 198.51.100.4 for wp-
l The Velocix CDN responds with the IP addresses of some appropriate Delivery
Applications, and that the information can be used for sixty seconds (9)
l The consumers upstream DNS Server tells the client to use the provided Delivery
Application addresses (10)
l The client connects to one of the Delivery Applications, and requests the content (11)

DNS-based Routing with HA

Some recursive DNS Serves may ask both the addresses at the same time.
During normal operation, the Service Node a particular request turns up at is random. If the
Service Nodes are very far apart (i.e. on different continents) then the difference in latency
to each Service Node may be any issue. This will not be a problem in most ISP networks.
If a Service Node should fail, there are five possibilities:
l A client using a consumer DNS Server may get a cached result, or,
l The recursive DNS server happens to try the node that is up, and gets a response, or
l The recursive DNS server may be configured to try multiple servers at the same time - in
which case it will get a response from the node that is up, or
l The recursive DNS server happens to try the node that is down, doesn't get a response,
and tries the other node ~2 seconds later. The client will see a small (~2s) delay. Or,
l The recursive DNS server has already tried this recently, and knows that one of the
nodes is down, so uses the one it knows is up (If it supports this)
5.3 Comparison
A failure of a Service Node sufficiently problematic as to impact delivery is a highly unlikely
event - a single blade failure inside a Service Node is not enough; there must be a complete
networking failure, loss of power, or multiple failures.
In the Anycast case, the worst-case scenario is a persistent, erroneous advertisement of
the Anycast address will isolate clients who get routed to that node, and they will become
unable to use the CDN at all. This failure mode can be mitigated by making the
advertisement of the route dependent on one of the monitoring techniques discussed in the
section on advertisement withdrawal. When using one of those methods effectively, this
failure mode is exceedingly unlikely

In the Anycast case, the second-worst-case scenario is the failure of a Service Node, which
then takes a long convergence time to effect the routing change - long enough for the
recursive DNS Server to give up. The route change convergence time is something only the
ISP can quantify - but ten seconds would normally be considered a very long time. This
could result in a period of no service - possibly resulting in the consumer having to perform a
"reload" operation (when using their client).
In the HA case, the worst-case scenario is that there are periodic ~2s delays while one
node is failed. It will not be every request that is delayed - due to the fact that 50% of
requests the recursive DNS server makes will go to the up node, and that it will cache
responses. In an extended or scheduled outage, the ISP can change the NS records in
example.net, to remove the failed node.
The client may disguise the ~2s delays from the consumer. For example, a video streaming
application may have a video buffer of more than two seconds.
We normally recommend the use of HA for the DNS-based redirection, rather than
Anycast, due to the better reliability during failure.

6 Anycast vs. HA in HTTP-based

Redirection
HTTP-based Redirection results in the client software talking to the Service Node directly,
by HTTP, and receiving a "302 Found" message, or a playlist, which redirects the client to
an appropriate Delivery Application. For more information about HTTP-based Redirection,
see the Routing Requests to Delivery Applications technical note.
HTTP-based redirection can use the Anycast address as the first point-of-entry, or it can
use the High Availability Service Node Address of either Service Node.
For the following examples, assume:
l There is a Velocix CDN with two Service Nodes
o It is "cdn.example.net"
l The first Service Node has a public IP address range of 192.0.2.0/28

l The second Service Node has a public IP address range of 198.51.100.0/28

l The Anycast address, if used, is 203.0.113.1

o When referred to as a network, it is 203.0.113.1/32
6.1 Anycast in HTTP-based Redirection

With Anycast for HTTP-based Redirection, the "front-end" names (such as
download.cdn.example.net) point to the Anycast address. HTTP Requests to this address
will get an HTTP redirect to an appropriate Delivery Application.
This technique requires that the Anycast address will not be load-balanced - that is that
from a single point in the network, outside of any convergence period, the route will always
be the same.
In the unlikely event that a Service Node fails, there are four possibilities:
convergence delay) as via the failed Service Node, and there is no response. The client
keeps trying the TCP session, which eventually succeeds (before the TCP handshake
timeout) as the route has been withdrawn in this period. The client sees a delay. Or,
the client to give up on the request. The client automatically retries, as it is configured to
do. This second request succeeds, as the route has been withdrawn in this period. This
results in a significant (many seconds) delay. Or,
the client to give up on the request, and either the client is not configured to retry, or it has
retried too many times. The client returns an error to the consumer. Or,

If the Anycast route switches from one active Service Node to another active Service Node
in the middle of an HTTP request, but before the "GET" has arrived at the Service Node,
the connection may break and need to be retried, or timed out. Once the "GET" (the third
packet the client will send) gets to the Service Node, it does not matter if the route changes,
as the reply is so short that it will not require any ACKs to be received before it is finished.
So, if the SYN goes to one Service Node, and the ACK to a different one; or the ACK to one
and the "GET" to another, then the request may fail or be delayed. Most clients will disguise
this behaviour by retrying. The following four diagrams show the possible combinations.
TCP Call Flow 1
TCP Call Flow 2

TCP Call Flow 3
TCP Call Flow 4

This is a small time window, which generally would only occur during network "flaps" (which
will cause other problems) or when bringing a Service Node online. In the latter case, there
are steps that can be taken to prevent the problem - by temporarily changing the A records
to use the HA address shortly before the route change, and then returning it to the Anycast
address later.
6.2 HA in HTTP-based Redirection

With HA for HTTP-based Redirection, the front-end names (such as
download.cdn.example.net) point to both the HA addresses (192.0.2.4 and 198.51.100.4).
HTTP Requests to either address will get an HTTP redirect to an appropriate Delivery
Application.
For the purposes of this discussion, there are two types of client. A badly-behaved client
will try to connect only once, or - if given multiple IP addresses in its DNS request - will retry
only the same address. A well-behaved client will try to connect multiple times, and will try
different IP addresses, if given multiple ones. Most modern browsers are well-behaved.
Proprietary embedded clients tend to be more likely to be badly-behaved.

In the following scenarios, I have ignored the possibility of the Service Node that has failed,
managed to be recovered and put back in service, during the lifetime of this process.
If a Service Node should fail, and the client is badly-behaved, there are three possibilities:
l The client happens to connect to the node that is up, and succeeds. Or,
l The client happens to connect to the node that is down. The request times-out. This
client gives up. This results in a delay, then an error to the consumer. Or,
l The client happens to connect to the node that is down. The request times-out. The
client tries the same Service Node again - repeatedly. This results in a long delay, then
an error to the consumer.
In the unlikely event that a Service Node fails, and the client is well-behaved, there are three
possibilities:
l The client happens to connect to the node that is up, and succeeds. Or,
l The client happens to connect to the node that is down. The request times out. The client
tries the other address. This results in a delay. Or,
l The client remembers that one of the addresses was unavailable, and so prefers the
other address.
6.3 Comparison
In the Anycast case, the worst-case scenario is again the persistent, erroneous
advertisement to a failed Service Node - as in the DNS-based Redirection case. It is still
highly unlikely.
In the Anycast case, the second-worst-case scenario is the failure of a Service Node, which
then takes a long convergence time to effect the routing change - long enough for the client
to give up. The route change convergence time is something only the ISP can quantify - but
ten seconds would normally be considered a very long time. This could result in a period of
no service - possibly resulting in the consumer having to perform a "reload" operation
(whatever that may mean, when using their client).
In the HA case, the worst-case scenario is that a badly-behaved client will consistently try
the same failed Service Node, over and over again - including on a "reload" operation.
In the HA case, the worst-case scenario with a well-behaved client is that there are periodic
~15s delays while one node is failed. It will not be every request that is delayed - due to the
fact that some of requests the client makes will go to the up node, and that it will re-use a
successful address many times. In an extended or scheduled outage, the ISP can change
the A records in cdn.example.net, to remove the failed node.
We normally recommend the use of Anycast for the HTTP-based redirection, rather than
HA, unless the client base is a closed set of clients, which are known to be well-behaved.

7 Anycast vs. HA in Console (Web

Portal)
The Console is an HTTPS interface for customer management and reporting. Users such
as the CDN owner, and those authorised to publish content to or through the CDN.
Consumers will never use this interface, and it is not in the download path.
7.1 Anycast in Console (Web Portal)

In the case of using Anycast for Console, the name console.cdn.example.net resolves to
the Anycast address, 203.0.113.1.
If a Service Node should fail, there are four possibilities:
convergence delay) as via the failed Service Node, and there is no response. The users
client keeps trying the TCP session, which eventually succeeds (before the TCP
handshake timeout) as the route has been withdrawn in this period. The users client
sees a delay. Or,
the users client to give up on the request. The users client automatically retries, as it is
configured to do. This second request succeeds, as the route has been withdrawn in this
period. This results in a significant delay. Or,
the users client to give up on the request, and either the users client is not configured to
retry, or it has retried too many times. The users client returns an error to the user. Or,
If the failure results in a particular users client going to a different Service Node than they
were previously using, they will automatically be logged out - as their session authentication
cookie is stored only on one Service Node.
If the Anycast route changes from one active Service Node to another active Service Node
in the middle of an HTTPS request, the connection may break, resulting in a failure or a
delay. Most clients will disguise this behaviour by retrying.
7.2 HA in Console (Web Portal)

In this case, the hostname console.cdn.example.net points to two different IPs - 192.0.2.4
and 198.51.100.4.
This scenario is effectively unusable; as users clients will periodically switch which Service
Node they are connected to. This will result in the user being logged out each time.
7.3 Multiple HA in Console (Web Portal)

In this case, two hostnames are defined, for example:
l console1.cdn.example.net -> 192.0.2.4
l console2.cdn.example.net -> 198.51.100.4

In this scenario, a user would specify which Service Node they wished to use. If it failed,
they would try the other.
This is only really practical if there are no external content-providing customers, and the ISP
would otherwise not have to deploy Anycast at all. That is, that only the ISP and Velocix
themselves would be using the Console, as the experience (manually selecting a Service
Node) is rather ugly.
7.4 Externally Load-Balanced Console (Web Portal)

If the ISP wishes to deploy an external Load Balancer for HTTPS, they can choose
another, separate address, which the Load Balancer balances (by proxying, so the source
address is the Load Balancer) across the HA addresses for HTTPS only.
The Load Balancer would not be used to support either redirection method - just the
console.
The Load Balancer could use the HTTP Probe method from the Route Withdrawal section
to determine which Service Node to use.
The Load Balancer must support "sticky" sessions for HTTPS, so that an individual client is
consistently directed to the same Service Node.
7.5 Comparison
Here, Anycast is usually the simplest solution that works well. HA does not work, Multiple
HA is a poor solution (as it requires the user to switch between Service Nodes), and an
External Load Balancer requires an external system.
We would normally recommend Anycast for the Console (Web Portal).

8 Conclusion
The ISP can choose between using Anycast or HA, for three different use-cases
independently. Additionally, the Web Portal has two extra options - Multi-HA, and a Load
Balancer. The use-cases are:
l DNS-based Redirection, where we generally recommend HA,
l HTTP-based Redirection, where we generally recommend Anycast, and
l The Web Portal (Console), where we generally recommend Anycast


CDN 52000 0001 GUENC - Technote UseOfAnycastInVelocixCDN

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CDN 52000 0001 GUENC - Technote UseOfAnycastInVelocixCDN

Uploaded by

Copyright:

Available Formats

Velocix Media Delivery

Use of Anycast in a Velocix

Document ID: CDN-52000-0001-GUENC

Version 49.0-1 | Release 5.2

Issue Date: April 2020

Velocix - Proprietary and confidential.

Copyright and Confidentiality

Release 5.2 Velocix - Proprietary & Confidential Page 2

Release 5.2 Velocix - Proprietary & Confidential Page 3

1 What's in this document

1.1 What's not in this document

Release 5.2 Velocix - Proprietary & Confidential Page 4

2 Use of Anycast in a Velocix CDN

Release 5.2 Velocix - Proprietary & Confidential Page 5

l A client is a piece of software. The consumer interacts with the client

l A user is an authorised individual, either from the ISP, or a content-providing customer

Release 5.2 Velocix - Proprietary & Confidential Page 6

3 Anycast in an ISP network

Anycast routing, with split horizon

Release 5.2 Velocix - Proprietary & Confidential Page 7

Anycast routing, without split horizon

Release 5.2 Velocix - Proprietary & Confidential Page 8

4.2 HTTP Probe

Release 5.2 Velocix - Proprietary & Confidential Page 9

5 Anycast vs. HA in DNS-based

l The first Service Node has a public IP address range of 192.0.2.0/28

l The second Service Node has a public IP address range of 198.51.100.0/28

l The Anycast address, if used, is 203.0.113.1

5.1 Anycast in DNS-based Redirection

Release 5.2 Velocix - Proprietary & Confidential Page 10

DNS-based Routing with Anycast

Release 5.2 Velocix - Proprietary & Confidential Page 11

5.2 HA in DNS-based Redirection

Release 5.2 Velocix - Proprietary & Confidential Page 12

DNS-based Routing with HA

Release 5.2 Velocix - Proprietary & Confidential Page 13

Release 5.2 Velocix - Proprietary & Confidential Page 14

6 Anycast vs. HA in HTTP-based

l The first Service Node has a public IP address range of 192.0.2.0/28

l The second Service Node has a public IP address range of 198.51.100.0/28

l The Anycast address, if used, is 203.0.113.1

6.1 Anycast in HTTP-based Redirection

Release 5.2 Velocix - Proprietary & Confidential Page 15

TCP Call Flow 1

TCP Call Flow 2

Release 5.2 Velocix - Proprietary & Confidential Page 16

TCP Call Flow 3

TCP Call Flow 4

6.2 HA in HTTP-based Redirection

Release 5.2 Velocix - Proprietary & Confidential Page 17

Release 5.2 Velocix - Proprietary & Confidential Page 18

7 Anycast vs. HA in Console (Web

7.1 Anycast in Console (Web Portal)

7.2 HA in Console (Web Portal)

7.3 Multiple HA in Console (Web Portal)

Release 5.2 Velocix - Proprietary & Confidential Page 19

7.4 Externally Load-Balanced Console (Web Portal)

Release 5.2 Velocix - Proprietary & Confidential Page 20

Release 5.2 Velocix - Proprietary & Confidential Page 21

You might also like