Question about multiple peer addresses on a VCS neighbour zone

[Nick Halbert-Lillyman]

If we configure a neighbour zone on a VCS to point to multiple IP addresses (Peer 1, Peer 2 etc), will it always try to use Peer 1 first or will it be round-robin?

We have a secondary path at a remote site with lower WAN bandwidth, so we only want to direct calls to the Peer 2 IP address when Peer 1 is unreachable.

[cfiestas · Accepted solution]

Nick,

Zone peers are searched done doing round robin, for example, if we have 2 peers in one zone, then the first message will go to the first peer then the next message witl go to the second peer then back to the first peer. Thanks

Cesar

[Martin Koch · Accepted solution]

Hi Nick!

In addition its not only doing RR but its also blacklisting hosts which are not reachable.

But for your scenario:

first of all as you talk about two path, what kind of device do you have on the other site,

how do you differentiate if it shall take path 1 or 2.

Like on a VCS you would need either two VCS-C for the remote site to get two ip addresses

or a VCS-E with the dual network option. NAT would not work to get a second IP.

If NAT is involved it would bring in additional issues, ...

Besides that why don't you just define two neighbor zones towards independent destinations/ips

Match with a higher priority on the first one and a lower priority (=higher number) on the second zone.

An other option could be to use CPLs, but that's more complex.

Cesar: I assume that the zone peers which are down are automatically black listed from the RR if its down

How about resource limitations on h323 if the first peer signals that its unavailable, would

the vcs directly assume the complete zone failed or would try the other peer?

It would be nice if the VCS would support SRV records instead of a single

address line per peer, then the VCS could even do failover on a second link or do load balancing

with a defined value, ...

Martin

Nick: Please rate the answers using the stars below the messages.

[Nick Halbert-Lillyman]

Thanks Martin - no NAT or anything like that, this is all in private IP space.  I am looking to apply this to a few different remote peers including VCS-C, VCS-E and CUBE, all of which I want to use *ONLY* when the primary is unreachable.

So just so I'm clear on what you are suggesting;

Make two search rules that match the same dialled string, one with a better priority, pointing to different zones.  The search rule with the better priority will point to the primary site.

The less preffered search rule will only be triggered if the first search rule's zone is unreachable?

[Martin Koch]

Be aware that you can generate search / call loops, the VCS has a loop detection mechanism,

not sure if the cube would break that, ...

And I am not sure if you would be happy with the cube in the middle anyhow. I heard about some people trying

but got no real reports of real success, ...

An advantage with two neighbor zones can also be that you can define different links / pipes

and then say a call the new link has only 2mbit and max 512kbit calls are allowed over it.

Here is an example of a CPL, this points to an ISDN gw but you might get the point:

http://www.cisco.com/en/US/docs/telepresence/infrastructure/vcs/config_guide/Cisco_VCS_ISDN_Overflow_Using_CPL_Script_Application_Note.pdf

An other option could be to look on the ip level if you can have some redundancy on the wan link.

Thx for rating (+5 for you!)

[Nick Halbert-Lillyman]

While CUBE wouldn't be my first choice, it belongs to another organisation we peer with so it's out of my control.  It's actually working pretty well for video (CTS, TP server, E20s and C-Series) but audio-only gives us some issues.

Your intial siggestion of multiple zones + search rules should work pretty well for us.  The whole idea is that if our entire primary data centre is offline, everything (other than what's in the primary DC) still works via a secondary site, so just having redundant WAN links isn't really enough - everything must be duplicated.  We just don't want to start using the secondary site's bandwidth unless we have to.