Re: [cisco-voip] Expressway cluster algorithm

[Lelio Fulgenzi]

Ah. Yes. That part from the conversation is coming back to me. Geeez.  No real 
way then, I’d there?

-sent from mobile device-

Lelio Fulgenzi, B.A. | Senior Analyst
Computing and Communications Services | University of Guelph
Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON | N1G 
2W1
519-824-4120 Ext. 56354 | 
le...@uoguelph.ca

www.uoguelph.ca/ccs | @UofGCCS on Instagram, 
Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]

On Jan 23, 2019, at 4:52 PM, Ryan Huff 
mailto:ryanh...@outlook.com>> wrote:

SRV weights and priorities do influence the selection, but do not guarantee. 
The accepting peer can pass to the other peer if the other peer is less 
utilized.

Sent from my iPhone

On Jan 23, 2019, at 16:35, Lelio Fulgenzi 
mailto:le...@uoguelph.ca>> wrote:

Gotcha. IIRC, you can’t put weight on traversal neighbours.

So you can use dns srv record weights to pick the C out or the E in, but once 
inside the cluster picking the next hop E (or C) is round robin.

Interested to hear comments.

-sent from mobile device-

Lelio Fulgenzi, B.A. | Senior Analyst
Computing and Communications Services | University of Guelph
Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON | N1G 
2W1
519-824-4120 Ext. 56354 | 
le...@uoguelph.ca

www.uoguelph.ca/ccs
 | @UofGCCS on Instagram, Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]

On Jan 23, 2019, at 4:17 PM, Ryan Huff 
mailto:ryanh...@outlook.com>> wrote:

I’m trying to guarantee an active/passive use case; so maintenance mode would 
achieve that (or shutting one side down), but would require manual 
intervention, and be as clunky of a work-a-round as it gets for a runtime 
solution.

-Ryan

On Jan 23, 2019, at 16:00, Lelio Fulgenzi 
mailto:le...@uoguelph.ca>> wrote:

I’m going to read the responses, but when I opened a TAC case, the engineer 
explained that there were at least two selection processes in play, which C (or 
E) to pick, then which neighbour to pick for the traversal.

She said, if you want to be 100% sure during troubleshooting, that you are 
testing a particular path, you want to put the nodes you don’t want to use into 
maintenance mode.

Made sense to me at the time.

-sent from mobile device-

Lelio Fulgenzi, B.A. | Senior Analyst
Computing and Communications Services | University of Guelph
Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON | N1G 
2W1
519-824-4120 Ext. 56354 | 
le...@uoguelph.ca

www.uoguelph.ca/ccs
 | @UofGCCS on Instagram, Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]

On Jan 23, 2019, at 3:19 PM, Ryan Huff 
mailto:ryanh...@outlook.com>> wrote:

Can anyone explain or cite the documents that define the algorithm used to 
determine which Expressway node in a given cluster is selected to process a 
call.

You can influence the selection with DNS SRV priority and weight, but does not 
appear to guarantee which cluster node is selected each time.

Thanks,

Ryan
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Expressway cluster algorithm

[Ryan Huff]

SRV weights and priorities do influence the selection, but do not guarantee. 
The accepting peer can pass to the other peer if the other peer is less 
utilized.

Sent from my iPhone

On Jan 23, 2019, at 16:35, Lelio Fulgenzi 
mailto:le...@uoguelph.ca>> wrote:

Gotcha. IIRC, you can’t put weight on traversal neighbours.

So you can use dns srv record weights to pick the C out or the E in, but once 
inside the cluster picking the next hop E (or C) is round robin.

Interested to hear comments.

-sent from mobile device-

Lelio Fulgenzi, B.A. | Senior Analyst
Computing and Communications Services | University of Guelph
Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON | N1G 
2W1
519-824-4120 Ext. 56354 | 
le...@uoguelph.ca

www.uoguelph.ca/ccs
 | @UofGCCS on Instagram, Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]

On Jan 23, 2019, at 4:17 PM, Ryan Huff 
mailto:ryanh...@outlook.com>> wrote:

I’m trying to guarantee an active/passive use case; so maintenance mode would 
achieve that (or shutting one side down), but would require manual 
intervention, and be as clunky of a work-a-round as it gets for a runtime 
solution.

-Ryan

On Jan 23, 2019, at 16:00, Lelio Fulgenzi 
mailto:le...@uoguelph.ca>> wrote:

I’m going to read the responses, but when I opened a TAC case, the engineer 
explained that there were at least two selection processes in play, which C (or 
E) to pick, then which neighbour to pick for the traversal.

She said, if you want to be 100% sure during troubleshooting, that you are 
testing a particular path, you want to put the nodes you don’t want to use into 
maintenance mode.

Made sense to me at the time.

-sent from mobile device-

Lelio Fulgenzi, B.A. | Senior Analyst
Computing and Communications Services | University of Guelph
Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON | N1G 
2W1
519-824-4120 Ext. 56354 | 
le...@uoguelph.ca

www.uoguelph.ca/ccs
 | @UofGCCS on Instagram, Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]

On Jan 23, 2019, at 3:19 PM, Ryan Huff 
mailto:ryanh...@outlook.com>> wrote:

Can anyone explain or cite the documents that define the algorithm used to 
determine which Expressway node in a given cluster is selected to process a 
call.

You can influence the selection with DNS SRV priority and weight, but does not 
appear to guarantee which cluster node is selected each time.

Thanks,

Ryan
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Expressway cluster algorithm

[Ryan Huff]

Well, ideally each inbound caller’s endpoint uses the same implementation of 
DNS SRV as defined in RFC2782 and respects priorities and weights (my SIP SRV 
targets the edge cluster FQDN).

And to your point, I can reliably control the edge that accepts the initial 
inbound INVITE with SRV manipulation, but cannot reliably predict which control 
peer is used (though you can usually make a good guess).

Ideally, I am trying to guarantee an active/passive use case in all scenarios, 
ingress and egress.

Sent from my iPhone

On Jan 23, 2019, at 16:32, Brian Meade 
mailto:bmead...@vt.edu>> wrote:

Is this for inbound B2B or for MRA?

If inbound B2B, it's more up to the caller's implementation of DNS.  If the 
caller is Webex, their may be some documented behavior out there somewhere.

On Wed, Jan 23, 2019 at 4:17 PM Ryan Huff 
mailto:ryanh...@outlook.com>> wrote:
I’m trying to guarantee an active/passive use case; so maintenance mode would 
achieve that (or shutting one side down), but would require manual 
intervention, and be as clunky of a work-a-round as it gets for a runtime 
solution.

-Ryan

On Jan 23, 2019, at 16:00, Lelio Fulgenzi 
mailto:le...@uoguelph.ca>> wrote:

I’m going to read the responses, but when I opened a TAC case, the engineer 
explained that there were at least two selection processes in play, which C (or 
E) to pick, then which neighbour to pick for the traversal.

She said, if you want to be 100% sure during troubleshooting, that you are 
testing a particular path, you want to put the nodes you don’t want to use into 
maintenance mode.

Made sense to me at the time.

-sent from mobile device-

Lelio Fulgenzi, B.A. | Senior Analyst
Computing and Communications Services | University of Guelph
Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON | N1G 2W1
519-824-4120 Ext. 56354 | 
le...@uoguelph.ca

www.uoguelph.ca/ccs
 | @UofGCCS on Instagram, Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]

On Jan 23, 2019, at 3:19 PM, Ryan Huff 
mailto:ryanh...@outlook.com>> wrote:

Can anyone explain or cite the documents that define the algorithm used to 
determine which Expressway node in a given cluster is selected to process a 
call.

You can influence the selection with DNS SRV priority and weight, but does not 
appear to guarantee which cluster node is selected each time.

Thanks,

Ryan
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Expressway cluster algorithm

[Lelio Fulgenzi]

Gotcha. IIRC, you can’t put weight on traversal neighbours.

So you can use dns srv record weights to pick the C out or the E in, but once 
inside the cluster picking the next hop E (or C) is round robin.

Interested to hear comments.

-sent from mobile device-

Lelio Fulgenzi, B.A. | Senior Analyst
Computing and Communications Services | University of Guelph
Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON | N1G 
2W1
519-824-4120 Ext. 56354 | 
le...@uoguelph.ca

www.uoguelph.ca/ccs | @UofGCCS on Instagram, 
Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]

On Jan 23, 2019, at 4:17 PM, Ryan Huff 
mailto:ryanh...@outlook.com>> wrote:

I’m trying to guarantee an active/passive use case; so maintenance mode would 
achieve that (or shutting one side down), but would require manual 
intervention, and be as clunky of a work-a-round as it gets for a runtime 
solution.

-Ryan

On Jan 23, 2019, at 16:00, Lelio Fulgenzi 
mailto:le...@uoguelph.ca>> wrote:

I’m going to read the responses, but when I opened a TAC case, the engineer 
explained that there were at least two selection processes in play, which C (or 
E) to pick, then which neighbour to pick for the traversal.

She said, if you want to be 100% sure during troubleshooting, that you are 
testing a particular path, you want to put the nodes you don’t want to use into 
maintenance mode.

Made sense to me at the time.

-sent from mobile device-

Lelio Fulgenzi, B.A. | Senior Analyst
Computing and Communications Services | University of Guelph
Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON | N1G 
2W1
519-824-4120 Ext. 56354 | 
le...@uoguelph.ca

www.uoguelph.ca/ccs
 | @UofGCCS on Instagram, Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]

On Jan 23, 2019, at 3:19 PM, Ryan Huff 
mailto:ryanh...@outlook.com>> wrote:

Can anyone explain or cite the documents that define the algorithm used to 
determine which Expressway node in a given cluster is selected to process a 
call.

You can influence the selection with DNS SRV priority and weight, but does not 
appear to guarantee which cluster node is selected each time.

Thanks,

Ryan
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Expressway cluster algorithm

[Brian Meade]

Is this for inbound B2B or for MRA?

If inbound B2B, it's more up to the caller's implementation of DNS.  If the
caller is Webex, their may be some documented behavior out there somewhere.

On Wed, Jan 23, 2019 at 4:17 PM Ryan Huff  wrote:

> I’m trying to guarantee an active/passive use case; so maintenance mode
> would achieve that (or shutting one side down), but would require manual
> intervention, and be as clunky of a work-a-round as it gets for a runtime
> solution.
>
> -Ryan
>
> On Jan 23, 2019, at 16:00, Lelio Fulgenzi  wrote:
>
> I’m going to read the responses, but when I opened a TAC case, the
> engineer explained that there were at least two selection processes in
> play, which C (or E) to pick, then which neighbour to pick for the
> traversal.
>
> She said, if you want to be 100% sure during troubleshooting, that you are
> testing a particular path, you want to put the nodes you don’t want to use
> into maintenance mode.
>
> Made sense to me at the time.
>
> *-sent from mobile device-*
>
>
> *Lelio Fulgenzi, B.A.* | Senior Analyst
>
> Computing and Communications Services | University of Guelph
>
> Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON |
> N1G 2W1
>
> 519-824-4120 Ext. 56354 <519-824-4120;56354> | le...@uoguelph.ca
>
>
>
> www.uoguelph.ca/ccs
> 
>  |
> @UofGCCS on Instagram, Twitter and Facebook
>
>
>
> [image: University of Guelph Cornerstone with Improve Life tagline]
>
> On Jan 23, 2019, at 3:19 PM, Ryan Huff  wrote:
>
> Can anyone explain or cite the documents that define the algorithm used to
> determine which Expressway node in a given cluster is selected to process a
> call.
>
> You can influence the selection with DNS SRV priority and weight, but does
> not appear to guarantee which cluster node is selected each time.
>
> Thanks,
>
> Ryan
> ___
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
> 
>
> ___
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Expressway cluster algorithm

[Ryan Huff]

I’m trying to guarantee an active/passive use case; so maintenance mode would 
achieve that (or shutting one side down), but would require manual 
intervention, and be as clunky of a work-a-round as it gets for a runtime 
solution.

-Ryan

On Jan 23, 2019, at 16:00, Lelio Fulgenzi 
mailto:le...@uoguelph.ca>> wrote:

I’m going to read the responses, but when I opened a TAC case, the engineer 
explained that there were at least two selection processes in play, which C (or 
E) to pick, then which neighbour to pick for the traversal.

She said, if you want to be 100% sure during troubleshooting, that you are 
testing a particular path, you want to put the nodes you don’t want to use into 
maintenance mode.

Made sense to me at the time.

-sent from mobile device-

Lelio Fulgenzi, B.A. | Senior Analyst
Computing and Communications Services | University of Guelph
Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON | N1G 
2W1
519-824-4120 Ext. 56354 | 
le...@uoguelph.ca

www.uoguelph.ca/ccs
 | @UofGCCS on Instagram, Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]

On Jan 23, 2019, at 3:19 PM, Ryan Huff 
mailto:ryanh...@outlook.com>> wrote:

Can anyone explain or cite the documents that define the algorithm used to 
determine which Expressway node in a given cluster is selected to process a 
call.

You can influence the selection with DNS SRV priority and weight, but does not 
appear to guarantee which cluster node is selected each time.

Thanks,

Ryan
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Expressway cluster algorithm

[Lelio Fulgenzi]

I’m going to read the responses, but when I opened a TAC case, the engineer 
explained that there were at least two selection processes in play, which C (or 
E) to pick, then which neighbour to pick for the traversal.

She said, if you want to be 100% sure during troubleshooting, that you are 
testing a particular path, you want to put the nodes you don’t want to use into 
maintenance mode.

Made sense to me at the time.

-sent from mobile device-

Lelio Fulgenzi, B.A. | Senior Analyst
Computing and Communications Services | University of Guelph
Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON | N1G 
2W1
519-824-4120 Ext. 56354 | 
le...@uoguelph.ca

www.uoguelph.ca/ccs | @UofGCCS on Instagram, 
Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]

On Jan 23, 2019, at 3:19 PM, Ryan Huff 
mailto:ryanh...@outlook.com>> wrote:

Can anyone explain or cite the documents that define the algorithm used to 
determine which Expressway node in a given cluster is selected to process a 
call.

You can influence the selection with DNS SRV priority and weight, but does not 
appear to guarantee which cluster node is selected each time.

Thanks,

Ryan
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Expressway cluster algorithm

[Patrick Robitaille]

I am also curious if there is any documentation for this.  When I asked Cisco 
HTTS support recently they said it is round robin.  In my environment though I 
see inbound B2B calls from Webex hitting the same CUCM Sub.


-Original Message-
From: cisco-voip  On Behalf Of Ryan Huff
Sent: Wednesday, January 23, 2019 3:19 PM
To: cisco-voip@puck.nether.net
Subject: [cisco-voip] Expressway cluster algorithm

Can anyone explain or cite the documents that define the algorithm used to 
determine which Expressway node in a given cluster is selected to process a 
call.

You can influence the selection with DNS SRV priority and weight, but does not 
appear to guarantee which cluster node is selected each time.

Thanks,

Ryan
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip



Disclaimer: This e-mail may contain confidential and/or privileged information. 
If you are not the intended recipient or have received this e-mail in error, 
please notify the sender immediately and destroy/delete this e-mail. You are 
hereby notified that any unauthorized copying, disclosure or distribution of 
the material in this e-mail is strictly prohibited.

AQR Capital Management, LLC, along with its affiliates (collectively "AQR") may 
collect certain personal information from you. AQR operates pursuant to a 
Global Privacy Policy which describes the types of personal information we 
obtain, how we use the information, with whom we share it and the choices 
available to you regarding our use of the information. We also describe the 
measures we take to protect the security of the information and how you can 
contact us about our privacy practices. By providing your personal information 
you agree to do so pursuant to the Global Privacy Policy. For a copy of the 
Global Privacy Policy please click here.

This communication is for informational purposes only. It is not intended as an 
offer or solicitation for the purchase or sale of any financial instrument or 
as an official confirmation of any transaction. All information contained in 
this communication is not warranted as to completeness or accuracy and is 
subject to change without notice. Any comments or statements made in this 
communication do not necessarily reflect those of AQR Capital Management, LLC 
and its affiliates.
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip