Each OTV node provides multicast send capability by replicating at the head-end itself. Each OTV node that sends a multicast
packet on a nonmulticast-capable network will unicast replicate the packet. Each OTV node takes a multicast packet that is
originated by the upper layers and makes a copy to send to each OTV neighbor that is interested in the multicast packet.
To be able to unicast replicate, each OTV node must know a list of neighbors to replicate to. Rather than configuring the
list of all neighbors in each OTV node, you can dynamically identify the neighbors. The set of OTV neighbors might be different
for different multicast groups, but the mechanism supports a unicast-replication-list (URL) per multicast group address.
The OTV does not use a replication server, so there are no choke points or longer path delays due to the lack of multicast
capability. The multicast data packets, even though they are sent as a unicast message, travel on the same path from the source
OTV edge device to each interested party for the group address the multicast is sent to. The only difference is that there
are multiple copies being sent from the OTV edge device source.
You must configure which OTV edge device acts as an adjacency server. The OTV edge devices are configured with the IPv4 or
IPv6 address of the adjacency server. All other adjacency addresses are discovered dynamically.
When a new site is added, you must configure only the OTV edge devices for the new site with the adjacency server addresses.
No other sites in this VPN or other VPNs need additional configuration.
You can have more than one adjacency server per virtual private network (VPN). An adjacency server can serve multiple VPNs.
When an OTV edge device is configured with one or more adjacency server addresses, they are added to the unicast-replication-list
(URL). An OTV edge device does not process an alternate server's type length value (TLV) until it believes the primary adjacency
server has timed out. The primary and secondary adjacency servers are configured in each OTV edge device. An adjacency server
can also be an OTV edge device that connects an OTV site to one or more VPNs.
OTV pushes the secondary adjacency server in the replication list based on the configuration with the primary server.
When you gracefully deconfigure an adjacency server, the client starts using the replication list from the secondary adjacency
server and pushes the difference to OTV. If you also deconfigure the secondary adjacency server, the client deletes the replication
list entries from OTV immediately.
If you reboot the primary adjacency server, the client starts using the replication list from the secondary adjacency server
and pushes the difference to OTV. If the secondary and the primary adjacency servers crash or rebooted, the client makes the
replication list entries stale with a timer of 10 minutes. The replication list entries are deleted after 10 minutes in case
there is no adjacency server in the network that is advertising the same entries in the replication list.
If you deconfigure or reboot the adjacency server client, the client stops sending hellos to the adjacency server. Consequently,
the adjacency server deletes the replication list entry for that client and advertises the deletion to all client nodes. All
the nodes delete the adjacency to that client immediately.
If the OTV adjacency is lost with a unicast-only adjacency server client, but the adjacency server continues to advertise
the unicast-only node, the other nodes continue to send hellos to that node until the adjacency server specifically deletes
it from its own list.