Mailing List Archive

I could be wrong here, but from what was explained to me...

You may be able to control the initial connection from off-prem device to the E of your choosing, but you cannot control which C that E talks to. And vice-versa.

So, you could point people to Ea, but they could easily be sent to Cs. And that traffic back from Cs could easily be sent to Es.

I was told at one time, the only option would be to put hosts in maintenance mode or something like that. But it wasn’t advised.

I’d love to hear other suggestions.

-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<x-apple-data-detectors://1/0>
519-824-4120 Ext. 56354<tel:519-824-4120;56354> | lelio@uoguelph.ca<mailto:lelio@uoguelph.ca>

www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram, Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]

On Jan 28, 2020, at 8:49 PM, Jonathan Charles <jonvoip@gmail.com<mailto:jonvoip@gmail.com>> wrote:

We have two pairs of Expressway clusters (C/E) at two different locations (primary and DR)...

The cluster is up, however, we want to make sure that we are in Active/Standby.

Currently, we have one of our SRV records for collab-edge set at 5 (the backup is at 10) with the same weight.

The clustering guide says we should set the priority and weight on both SRV records the same, which will cause half of the registrations to go to the DR site. It is far away and has less capability.

How do we:

1 - Make sure the primary site handles all MRA registrations and the DR site is only used when the primary is down.
2 = Make sure failover occurs automatically... currently Jabber users have to log out and back in to connect to the DR site.


Thanks!


Jonathan

_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

1.) It used to be in previous versions that all cluster nodes could technically be active at any time and SRV weights and priorities could influence the path selection but not guarantee it end-to-end when all cluster nodes are up and running.

I believe this behavior has changed/improved and I think you are supposed to be able to control that now with SRV weights and priorities, but I could be wrong. I haven’t played with Expressway clustering in a bit.

2.) As far as the Jabber registration goes; what I’ve done before in the edge is have the collab-edge SRV point to the edge cluster FQDN as the target. Then I create round robin A records for the cluster FQDN (one resolving your each edge server). The for the edge certs, just make sure the edge cluster fqdn is in the SAN.

This way if one of the edge server goes down, the Jabber client is ultimately still trying to resolve the same MRA FQDN via SRV lookup (this a key to Jabber client failover for MRA).

Thanks,

Ryan

> On Jan 28, 2020, at 20:50, Jonathan Charles <jonvoip@gmail.com> wrote:
>
> ?
> We have two pairs of Expressway clusters (C/E) at two different locations (primary and DR)...
>
> The cluster is up, however, we want to make sure that we are in Active/Standby.
>
> Currently, we have one of our SRV records for collab-edge set at 5 (the backup is at 10) with the same weight.
>
> The clustering guide says we should set the priority and weight on both SRV records the same, which will cause half of the registrations to go to the DR site. It is far away and has less capability.
>
> How do we:
>
> 1 - Make sure the primary site handles all MRA registrations and the DR site is only used when the primary is down.
> 2 = Make sure failover occurs automatically... currently Jabber users have to log out and back in to connect to the DR site.
>
>
> Thanks!
>
>
> Jonathan
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&amp;data=02%7C01%7C%7C2f536d8162984707853908d7a45d8e24%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637158594035084563&amp;sdata=atRtIR8sWZ60Ja8akD6GjzBIgBNC8GSJjaOmu%2BTxmWw%3D&amp;reserved=0
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

How does no. 2 actually solve the problem of having to log back in?

Is this a supported/suggested deployment method?

It’s been a while since I first looked at things and don’t recall things mentioning using the cluster name in the SRV records.

I’m intrigued. And interested!


-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<x-apple-data-detectors://1/0>
519-824-4120 Ext. 56354<tel:519-824-4120;56354> | lelio@uoguelph.ca<mailto:lelio@uoguelph.ca>

www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram, Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]

On Jan 28, 2020, at 9:03 PM, Ryan Huff <ryanhuff@outlook.com<mailto:ryanhuff@outlook.com>> wrote:

1.) It used to be in previous versions that all cluster nodes could technically be active at any time and SRV weights and priorities could influence the path selection but not guarantee it end-to-end when all cluster nodes are up and running.

I believe this behavior has changed/improved and I think you are supposed to be able to control that now with SRV weights and priorities, but I could be wrong. I haven’t played with Expressway clustering in a bit.

2.) As far as the Jabber registration goes; what I’ve done before in the edge is have the collab-edge SRV point to the edge cluster FQDN as the target. Then I create round robin A records for the cluster FQDN (one resolving your each edge server). The for the edge certs, just make sure the edge cluster fqdn is in the SAN.

This way if one of the edge server goes down, the Jabber client is ultimately still trying to resolve the same MRA FQDN via SRV lookup (this a key to Jabber client failover for MRA).

Thanks,

Ryan

On Jan 28, 2020, at 20:50, Jonathan Charles <jonvoip@gmail.com<mailto:jonvoip@gmail.com>> wrote:

?
We have two pairs of Expressway clusters (C/E) at two different locations (primary and DR)...

The cluster is up, however, we want to make sure that we are in Active/Standby.

Currently, we have one of our SRV records for collab-edge set at 5 (the backup is at 10) with the same weight.

The clustering guide says we should set the priority and weight on both SRV records the same, which will cause half of the registrations to go to the DR site. It is far away and has less capability.

How do we:

1 - Make sure the primary site handles all MRA registrations and the DR site is only used when the primary is down.
2 = Make sure failover occurs automatically... currently Jabber users have to log out and back in to connect to the DR site.


Thanks!


Jonathan

_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&amp;data=02%7C01%7C%7C2f536d8162984707853908d7a45d8e24%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637158594035084563&amp;sdata=atRtIR8sWZ60Ja8akD6GjzBIgBNC8GSJjaOmu%2BTxmWw%3D&amp;reserved=0
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

We've built them as individual pairs (Edge/Core) and then use DNS to
control which one goes where. Without the cluster, we know that Edge1 will
always talk to Core1.

I get the feeling that clustering was always meant to be in the same DC,
and for redundancy purposes in the same DC.

If you have two DC's, either a cluster at each DC, or just a pair at each
DC, depending on the business needs.

On Tue, Jan 28, 2020 at 8:11 PM Lelio Fulgenzi <lelio@uoguelph.ca> wrote:

>
> How does no. 2 actually solve the problem of having to log back in?
>
> Is this a supported/suggested deployment method?
>
> It’s been a while since I first looked at things and don’t recall things
> mentioning using the cluster name in the SRV records.
>
> I’m intrigued. And interested!
>
>
> *-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> | lelio@uoguelph.ca
>
>
>
> www.uoguelph.ca/ccs | @UofGCCS on Instagram, Twitter and Facebook
>
>
>
> [image: University of Guelph Cornerstone with Improve Life tagline]
>
> On Jan 28, 2020, at 9:03 PM, Ryan Huff <ryanhuff@outlook.com> wrote:
>
> 1.) It used to be in previous versions that all cluster nodes could
> technically be active at any time and SRV weights and priorities could
> influence the path selection but not guarantee it end-to-end when all
> cluster nodes are up and running.
>
> I believe this behavior has changed/improved and I think you are supposed
> to be able to control that now with SRV weights and priorities, but I could
> be wrong. I haven’t played with Expressway clustering in a bit.
>
> 2.) As far as the Jabber registration goes; what I’ve done before in the
> edge is have the collab-edge SRV point to the edge cluster FQDN as the
> target. Then I create round robin A records for the cluster FQDN (one
> resolving your each edge server). The for the edge certs, just make sure
> the edge cluster fqdn is in the SAN.
>
> This way if one of the edge server goes down, the Jabber client is
> ultimately still trying to resolve the same MRA FQDN via SRV lookup (this a
> key to Jabber client failover for MRA).
>
> Thanks,
>
> Ryan
>
> On Jan 28, 2020, at 20:50, Jonathan Charles <jonvoip@gmail.com> wrote:
>
>
> ?
>
> We have two pairs of Expressway clusters (C/E) at two different locations
> (primary and DR)...
>
>
> The cluster is up, however, we want to make sure that we are in
> Active/Standby.
>
>
> Currently, we have one of our SRV records for collab-edge set at 5 (the
> backup is at 10) with the same weight.
>
>
> The clustering guide says we should set the priority and weight on both
> SRV records the same, which will cause half of the registrations to go to
> the DR site. It is far away and has less capability.
>
>
> How do we:
>
>
> 1 - Make sure the primary site handles all MRA registrations and the DR
> site is only used when the primary is down.
>
> 2 = Make sure failover occurs automatically... currently Jabber users have
> to log out and back in to connect to the DR site.
>
>
>
> Thanks!
>
>
>
> Jonathan
>
>
> _______________________________________________
>
> cisco-voip mailing list
>
> cisco-voip@puck.nether.net
>
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&amp;data=02%7C01%7C%7C2f536d8162984707853908d7a45d8e24%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637158594035084563&amp;sdata=atRtIR8sWZ60Ja8akD6GjzBIgBNC8GSJjaOmu%2BTxmWw%3D&amp;reserved=0
>
> _______________________________________________
> 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
>

Is that A record needed for some function or another of Jabber to operate?

We have two equally weighted SRV to our E and it will fail over to the other host when it's not available, depending on the service, if it chooses to operate. The client periodically re-looks up the SRV record anyways in my experience. The failover scenario isn't instant/clean anyways with Jabber but if it does improve timing on something that would be good to know.

Adam



> -----Original Message-----
> From: cisco-voip <cisco-voip-bounces@puck.nether.net> On Behalf Of Ryan
> Huff
> Sent: Tuesday, January 28, 2020 9:04 PM
> To: Jonathan Charles <jonvoip@gmail.com>
> Cc: cisco-voip@puck.nether.net
> Subject: Re: [cisco-voip] Expressway Cluster failover for MRA...
>
> 1.) It used to be in previous versions that all cluster nodes could technically be
> active at any time and SRV weights and priorities could influence the path
> selection but not guarantee it end-to-end when all cluster nodes are up and
> running.
>
> I believe this behavior has changed/improved and I think you are supposed to
> be able to control that now with SRV weights and priorities, but I could be
> wrong. I haven’t played with Expressway clustering in a bit.
>
> 2.) As far as the Jabber registration goes; what I’ve done before in the edge is
> have the collab-edge SRV point to the edge cluster FQDN as the target. Then I
> create round robin A records for the cluster FQDN (one resolving your each
> edge server). The for the edge certs, just make sure the edge cluster fqdn is in
> the SAN.
>
> This way if one of the edge server goes down, the Jabber client is ultimately
> still trying to resolve the same MRA FQDN via SRV lookup (this a key to Jabber
> client failover for MRA).
>
> Thanks,
>
> Ryan
>
> > On Jan 28, 2020, at 20:50, Jonathan Charles <jonvoip@gmail.com> wrote:
> >
> >
> > We have two pairs of Expressway clusters (C/E) at two different locations
> (primary and DR)...
> >
> > The cluster is up, however, we want to make sure that we are in
> Active/Standby.
> >
> > Currently, we have one of our SRV records for collab-edge set at 5 (the
> backup is at 10) with the same weight.
> >
> > The clustering guide says we should set the priority and weight on both SRV
> records the same, which will cause half of the registrations to go to the DR site.
> It is far away and has less capability.
> >
> > How do we:
> >
> > 1 - Make sure the primary site handles all MRA registrations and the DR site
> is only used when the primary is down.
> > 2 = Make sure failover occurs automatically... currently Jabber users have to
> log out and back in to connect to the DR site.
> >
> >
> > Thanks!
> >
> >
> > Jonathan
> >
> > _______________________________________________
> > cisco-voip mailing list
> > cisco-voip@puck.nether.net
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.net
> her.net%2Fmailman%2Flistinfo%2Fcisco-
> voip&amp;data=02%7C01%7C%7C2f536d8162984707853908d7a45d8e24%7C8
> 4df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637158594035084563&am
> p;sdata=atRtIR8sWZ60Ja8akD6GjzBIgBNC8GSJjaOmu%2BTxmWw%3D&amp;res
> erved=0
> _______________________________________________
> 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

But without clustering, if Core1 fails, Edge1 will still be active and Jabber clients will still see Edge1 running and attempt to connect through it!

De: cisco-voip <cisco-voip-bounces@puck.nether.net> En nombre de Charles Goldsmith
Enviado el: martes, 28 de enero de 2020 23:18
Para: Lelio Fulgenzi <lelio@uoguelph.ca>
CC: cisco-voip@puck.nether.net
Asunto: Re: [cisco-voip] Expressway Cluster failover for MRA...

We've built them as individual pairs (Edge/Core) and then use DNS to control which one goes where. Without the cluster, we know that Edge1 will always talk to Core1.

I get the feeling that clustering was always meant to be in the same DC, and for redundancy purposes in the same DC.

If you have two DC's, either a cluster at each DC, or just a pair at each DC, depending on the business needs.

On Tue, Jan 28, 2020 at 8:11 PM Lelio Fulgenzi <lelio@uoguelph.ca<mailto:lelio@uoguelph.ca>> wrote:

How does no. 2 actually solve the problem of having to log back in?

Is this a supported/suggested deployment method?

It’s been a while since I first looked at things and don’t recall things mentioning using the cluster name in the SRV records.

I’m intrigued. And interested!


-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<tel:519-824-4120;56354> | lelio@uoguelph.ca<mailto:lelio@uoguelph.ca>

www.uoguelph.ca/ccs<https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.uoguelph.ca%2Fccs&data=02%7C01%7Cariel.roza%40la.logicalis.com%7Cc0d1c180d7f641ba09fb08d7a461a4bb%7C2e3290cb8d404058abe502c4f58b87e3%7C0%7C0%7C637158611596247024&sdata=tcEox%2FkkBKTgCYb4MyUOvCU4nl%2Bb9teAf7ijtXlv5lE%3D&reserved=0> | @UofGCCS on Instagram, Twitter and Facebook


On Jan 28, 2020, at 9:03 PM, Ryan Huff <ryanhuff@outlook.com<mailto:ryanhuff@outlook.com>> wrote:
1.) It used to be in previous versions that all cluster nodes could technically be active at any time and SRV weights and priorities could influence the path selection but not guarantee it end-to-end when all cluster nodes are up and running.

I believe this behavior has changed/improved and I think you are supposed to be able to control that now with SRV weights and priorities, but I could be wrong. I haven’t played with Expressway clustering in a bit.

2.) As far as the Jabber registration goes; what I’ve done before in the edge is have the collab-edge SRV point to the edge cluster FQDN as the target. Then I create round robin A records for the cluster FQDN (one resolving your each edge server). The for the edge certs, just make sure the edge cluster fqdn is in the SAN.

This way if one of the edge server goes down, the Jabber client is ultimately still trying to resolve the same MRA FQDN via SRV lookup (this a key to Jabber client failover for MRA).

Thanks,

Ryan


On Jan 28, 2020, at 20:50, Jonathan Charles <jonvoip@gmail.com<mailto:jonvoip@gmail.com>> wrote:

?
We have two pairs of Expressway clusters (C/E) at two different locations (primary and DR)...

The cluster is up, however, we want to make sure that we are in Active/Standby.

Currently, we have one of our SRV records for collab-edge set at 5 (the backup is at 10) with the same weight.

The clustering guide says we should set the priority and weight on both SRV records the same, which will cause half of the registrations to go to the DR site. It is far away and has less capability.

How do we:

1 - Make sure the primary site handles all MRA registrations and the DR site is only used when the primary is down.
2 = Make sure failover occurs automatically... currently Jabber users have to log out and back in to connect to the DR site.


Thanks!


Jonathan

_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&amp;data=02%7C01%7C%7C2f536d8162984707853908d7a45d8e24%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637158594035084563&amp;sdata=atRtIR8sWZ60Ja8akD6GjzBIgBNC8GSJjaOmu%2BTxmWw%3D&amp;reserved=0<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7Cariel.roza%40la.logicalis.com%7Cc0d1c180d7f641ba09fb08d7a461a4bb%7C2e3290cb8d404058abe502c4f58b87e3%7C0%7C0%7C637158611596257016&sdata=wuwlprtfvvr5RlI9gqrM4CU7hu4D4XUDxfGgghf8JEc%3D&reserved=0>
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7Cariel.roza%40la.logicalis.com%7Cc0d1c180d7f641ba09fb08d7a461a4bb%7C2e3290cb8d404058abe502c4f58b87e3%7C0%7C0%7C637158611596257016&sdata=wuwlprtfvvr5RlI9gqrM4CU7hu4D4XUDxfGgghf8JEc%3D&reserved=0>
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7Cariel.roza%40la.logicalis.com%7Cc0d1c180d7f641ba09fb08d7a461a4bb%7C2e3290cb8d404058abe502c4f58b87e3%7C0%7C0%7C637158611596267015&sdata=Bp9L1yT5L%2BOU0zeCCkcK3AInjLT8yraIb8DO9mEDheI%3D&reserved=0>

Correct, the edge cluster and the control cluster are very much separate entities apart from themselves and load balance within their own respective clusters.

As long as clustering has been implemented correctly, in that scenario, the edge cluster would still be able to load balance and distribute resources within its own cluster (edge 1 answered the request but edge two transported the request to control 2 because control 1 was unreachable).

In that type of a degraded “brown out” scenario, you should manually put edge 1 in maintenance mode. Not sure if you could trigger maintenance mode via API but if you could, then its conceivable that one could write a polling “heart beat” script to detect those unique “brown out” states and then automatically make edge 1 unserviceable by placing it into maintenance mode.

Thanks,

Ryan

On Jan 29, 2020, at 12:59, ROZA, Ariel <Ariel.ROZA@la.logicalis.com> wrote:

?
But without clustering, if Core1 fails, Edge1 will still be active and Jabber clients will still see Edge1 running and attempt to connect through it!

De: cisco-voip <cisco-voip-bounces@puck.nether.net> En nombre de Charles Goldsmith
Enviado el: martes, 28 de enero de 2020 23:18
Para: Lelio Fulgenzi <lelio@uoguelph.ca>
CC: cisco-voip@puck.nether.net
Asunto: Re: [cisco-voip] Expressway Cluster failover for MRA...

We've built them as individual pairs (Edge/Core) and then use DNS to control which one goes where. Without the cluster, we know that Edge1 will always talk to Core1.

I get the feeling that clustering was always meant to be in the same DC, and for redundancy purposes in the same DC.

If you have two DC's, either a cluster at each DC, or just a pair at each DC, depending on the business needs.

On Tue, Jan 28, 2020 at 8:11 PM Lelio Fulgenzi <lelio@uoguelph.ca<mailto:lelio@uoguelph.ca>> wrote:

How does no. 2 actually solve the problem of having to log back in?

Is this a supported/suggested deployment method?

It’s been a while since I first looked at things and don’t recall things mentioning using the cluster name in the SRV records.

I’m intrigued. And interested!


-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<tel:519-824-4120;56354> | lelio@uoguelph.ca<mailto:lelio@uoguelph.ca>

www.uoguelph.ca/ccs<https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.uoguelph.ca%2Fccs&data=02%7C01%7C%7C28abee85602c4394504a08d7a4e5024d%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637159175814864913&sdata=4Ty7ZYZ77QBJ6FCaao%2FQOZRlnNj7Oi4y%2BOBQzilxEIA%3D&reserved=0> | @UofGCCS on Instagram, Twitter and Facebook


On Jan 28, 2020, at 9:03 PM, Ryan Huff <ryanhuff@outlook.com<mailto:ryanhuff@outlook.com>> wrote:
1.) It used to be in previous versions that all cluster nodes could technically be active at any time and SRV weights and priorities could influence the path selection but not guarantee it end-to-end when all cluster nodes are up and running.

I believe this behavior has changed/improved and I think you are supposed to be able to control that now with SRV weights and priorities, but I could be wrong. I haven’t played with Expressway clustering in a bit.

2.) As far as the Jabber registration goes; what I’ve done before in the edge is have the collab-edge SRV point to the edge cluster FQDN as the target. Then I create round robin A records for the cluster FQDN (one resolving your each edge server). The for the edge certs, just make sure the edge cluster fqdn is in the SAN.

This way if one of the edge server goes down, the Jabber client is ultimately still trying to resolve the same MRA FQDN via SRV lookup (this a key to Jabber client failover for MRA).

Thanks,

Ryan


On Jan 28, 2020, at 20:50, Jonathan Charles <jonvoip@gmail.com<mailto:jonvoip@gmail.com>> wrote:

?
We have two pairs of Expressway clusters (C/E) at two different locations (primary and DR)...

The cluster is up, however, we want to make sure that we are in Active/Standby.

Currently, we have one of our SRV records for collab-edge set at 5 (the backup is at 10) with the same weight.

The clustering guide says we should set the priority and weight on both SRV records the same, which will cause half of the registrations to go to the DR site. It is far away and has less capability.

How do we:

1 - Make sure the primary site handles all MRA registrations and the DR site is only used when the primary is down.
2 = Make sure failover occurs automatically... currently Jabber users have to log out and back in to connect to the DR site.


Thanks!


Jonathan

_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&amp;data=02%7C01%7C%7C2f536d8162984707853908d7a45d8e24%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637158594035084563&amp;sdata=atRtIR8sWZ60Ja8akD6GjzBIgBNC8GSJjaOmu%2BTxmWw%3D&amp;reserved=0<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7C%7C28abee85602c4394504a08d7a4e5024d%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637159175814874918&sdata=2ULQiab5aIZYA90C1VDgpALdcRZjlsP1Vwx%2FCAam4Qs%3D&reserved=0>
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7C%7C28abee85602c4394504a08d7a4e5024d%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637159175814885738&sdata=IjY%2FpOIyx%2FZzOTxUuruUDEx9UHH%2Bl0QvfLsf8K2nqQI%3D&reserved=0>
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7C%7C28abee85602c4394504a08d7a4e5024d%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637159175814894934&sdata=VNEu5UEe0dooSVh63Wbxx4xQope8qS0oV5xlDOZat%2FA%3D&reserved=0>
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net
https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&amp;data=02%7C01%7C%7C28abee85602c4394504a08d7a4e5024d%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637159175814944977&amp;sdata=8geL2Lp2ksdsbzZ0lppv5z6Eub6QbdAGjiAjtsTshNY%3D&amp;reserved=0

Yes, but when installing distributed systems (across geographically diverse
DC's), this is better than having Core1 talk to Edge2 scenario all the time.

Hopefully this is resolved soon and we can go back to clustering.


On Wed, Jan 29, 2020 at 11:59 AM ROZA, Ariel <Ariel.ROZA@la.logicalis.com>
wrote:

> But without clustering, if Core1 fails, Edge1 will still be active and
> Jabber clients will still see Edge1 running and attempt to connect through
> it!
>
>
>
> *De:* cisco-voip <cisco-voip-bounces@puck.nether.net> *En nombre de *Charles
> Goldsmith
> *Enviado el:* martes, 28 de enero de 2020 23:18
> *Para:* Lelio Fulgenzi <lelio@uoguelph.ca>
> *CC:* cisco-voip@puck.nether.net
> *Asunto:* Re: [cisco-voip] Expressway Cluster failover for MRA...
>
>
>
> We've built them as individual pairs (Edge/Core) and then use DNS to
> control which one goes where. Without the cluster, we know that Edge1 will
> always talk to Core1.
>
>
>
> I get the feeling that clustering was always meant to be in the same DC,
> and for redundancy purposes in the same DC.
>
>
>
> If you have two DC's, either a cluster at each DC, or just a pair at each
> DC, depending on the business needs.
>
>
>
> On Tue, Jan 28, 2020 at 8:11 PM Lelio Fulgenzi <lelio@uoguelph.ca> wrote:
>
>
>
> How does no. 2 actually solve the problem of having to log back in?
>
>
>
> Is this a supported/suggested deployment method?
>
>
>
> It’s been a while since I first looked at things and don’t recall things
> mentioning using the cluster name in the SRV records.
>
>
>
> I’m intrigued. And interested!
>
>
>
>
>
> *-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> | lelio@uoguelph.ca
>
>
>
> www.uoguelph.ca/ccs
> <https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.uoguelph.ca%2Fccs&data=02%7C01%7Cariel.roza%40la.logicalis.com%7Cc0d1c180d7f641ba09fb08d7a461a4bb%7C2e3290cb8d404058abe502c4f58b87e3%7C0%7C0%7C637158611596247024&sdata=tcEox%2FkkBKTgCYb4MyUOvCU4nl%2Bb9teAf7ijtXlv5lE%3D&reserved=0> |
> @UofGCCS on Instagram, Twitter and Facebook
>
>
>
>
> On Jan 28, 2020, at 9:03 PM, Ryan Huff <ryanhuff@outlook.com> wrote:
>
> 1.) It used to be in previous versions that all cluster nodes could
> technically be active at any time and SRV weights and priorities could
> influence the path selection but not guarantee it end-to-end when all
> cluster nodes are up and running.
>
> I believe this behavior has changed/improved and I think you are supposed
> to be able to control that now with SRV weights and priorities, but I could
> be wrong. I haven’t played with Expressway clustering in a bit.
>
> 2.) As far as the Jabber registration goes; what I’ve done before in the
> edge is have the collab-edge SRV point to the edge cluster FQDN as the
> target. Then I create round robin A records for the cluster FQDN (one
> resolving your each edge server). The for the edge certs, just make sure
> the edge cluster fqdn is in the SAN.
>
> This way if one of the edge server goes down, the Jabber client is
> ultimately still trying to resolve the same MRA FQDN via SRV lookup (this a
> key to Jabber client failover for MRA).
>
> Thanks,
>
> Ryan
>
>
> On Jan 28, 2020, at 20:50, Jonathan Charles <jonvoip@gmail.com> wrote:
>
>
>
> ?
>
> We have two pairs of Expressway clusters (C/E) at two different locations
> (primary and DR)...
>
>
>
> The cluster is up, however, we want to make sure that we are in
> Active/Standby.
>
>
>
> Currently, we have one of our SRV records for collab-edge set at 5 (the
> backup is at 10) with the same weight.
>
>
>
> The clustering guide says we should set the priority and weight on both
> SRV records the same, which will cause half of the registrations to go to
> the DR site. It is far away and has less capability.
>
>
>
> How do we:
>
>
>
> 1 - Make sure the primary site handles all MRA registrations and the DR
> site is only used when the primary is down.
>
> 2 = Make sure failover occurs automatically... currently Jabber users have
> to log out and back in to connect to the DR site.
>
>
>
>
>
> Thanks!
>
>
>
>
>
> Jonathan
>
>
>
> _______________________________________________
>
> cisco-voip mailing list
>
> cisco-voip@puck.nether.net
>
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&amp;data=02%7C01%7C%7C2f536d8162984707853908d7a45d8e24%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637158594035084563&amp;sdata=atRtIR8sWZ60Ja8akD6GjzBIgBNC8GSJjaOmu%2BTxmWw%3D&amp;reserved=0
> <https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7Cariel.roza%40la.logicalis.com%7Cc0d1c180d7f641ba09fb08d7a461a4bb%7C2e3290cb8d404058abe502c4f58b87e3%7C0%7C0%7C637158611596257016&sdata=wuwlprtfvvr5RlI9gqrM4CU7hu4D4XUDxfGgghf8JEc%3D&reserved=0>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
> <https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7Cariel.roza%40la.logicalis.com%7Cc0d1c180d7f641ba09fb08d7a461a4bb%7C2e3290cb8d404058abe502c4f58b87e3%7C0%7C0%7C637158611596257016&sdata=wuwlprtfvvr5RlI9gqrM4CU7hu4D4XUDxfGgghf8JEc%3D&reserved=0>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
> <https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7Cariel.roza%40la.logicalis.com%7Cc0d1c180d7f641ba09fb08d7a461a4bb%7C2e3290cb8d404058abe502c4f58b87e3%7C0%7C0%7C637158611596267015&sdata=Bp9L1yT5L%2BOU0zeCCkcK3AInjLT8yraIb8DO9mEDheI%3D&reserved=0>
>
>

Well at least the docs bumped the WAN tolerances to 80Ms instead of the 30Ms it used to be... so... progress? Lol

Honestly, I don’t see them changing intra-clustering communications anymore than it is today.

Sent from my iPhone

On Jan 29, 2020, at 13:28, Charles Goldsmith <w@woka.us> wrote:

?
Yes, but when installing distributed systems (across geographically diverse DC's), this is better than having Core1 talk to Edge2 scenario all the time.

Hopefully this is resolved soon and we can go back to clustering.


On Wed, Jan 29, 2020 at 11:59 AM ROZA, Ariel <Ariel.ROZA@la.logicalis.com<mailto:Ariel.ROZA@la.logicalis.com>> wrote:
But without clustering, if Core1 fails, Edge1 will still be active and Jabber clients will still see Edge1 running and attempt to connect through it!

De: cisco-voip <cisco-voip-bounces@puck.nether.net<mailto:cisco-voip-bounces@puck.nether.net>> En nombre de Charles Goldsmith
Enviado el: martes, 28 de enero de 2020 23:18
Para: Lelio Fulgenzi <lelio@uoguelph.ca<mailto:lelio@uoguelph.ca>>
CC: cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
Asunto: Re: [cisco-voip] Expressway Cluster failover for MRA...

We've built them as individual pairs (Edge/Core) and then use DNS to control which one goes where. Without the cluster, we know that Edge1 will always talk to Core1.

I get the feeling that clustering was always meant to be in the same DC, and for redundancy purposes in the same DC.

If you have two DC's, either a cluster at each DC, or just a pair at each DC, depending on the business needs.

On Tue, Jan 28, 2020 at 8:11 PM Lelio Fulgenzi <lelio@uoguelph.ca<mailto:lelio@uoguelph.ca>> wrote:

How does no. 2 actually solve the problem of having to log back in?

Is this a supported/suggested deployment method?

It’s been a while since I first looked at things and don’t recall things mentioning using the cluster name in the SRV records.

I’m intrigued. And interested!


-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<tel:519-824-4120;56354> | lelio@uoguelph.ca<mailto:lelio@uoguelph.ca>

www.uoguelph.ca/ccs<https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.uoguelph.ca%2Fccs&data=02%7C01%7C%7C35f7cedb152248125f4208d7a4e906ec%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637159193060423489&sdata=38rrvBTpkfDz6yh1PDl6tp6fIVqwrbe3CGG%2BuavwjIY%3D&reserved=0> | @UofGCCS on Instagram, Twitter and Facebook


On Jan 28, 2020, at 9:03 PM, Ryan Huff <ryanhuff@outlook.com<mailto:ryanhuff@outlook.com>> wrote:
1.) It used to be in previous versions that all cluster nodes could technically be active at any time and SRV weights and priorities could influence the path selection but not guarantee it end-to-end when all cluster nodes are up and running.

I believe this behavior has changed/improved and I think you are supposed to be able to control that now with SRV weights and priorities, but I could be wrong. I haven’t played with Expressway clustering in a bit.

2.) As far as the Jabber registration goes; what I’ve done before in the edge is have the collab-edge SRV point to the edge cluster FQDN as the target. Then I create round robin A records for the cluster FQDN (one resolving your each edge server). The for the edge certs, just make sure the edge cluster fqdn is in the SAN.

This way if one of the edge server goes down, the Jabber client is ultimately still trying to resolve the same MRA FQDN via SRV lookup (this a key to Jabber client failover for MRA).

Thanks,

Ryan


On Jan 28, 2020, at 20:50, Jonathan Charles <jonvoip@gmail.com<mailto:jonvoip@gmail.com>> wrote:

?
We have two pairs of Expressway clusters (C/E) at two different locations (primary and DR)...

The cluster is up, however, we want to make sure that we are in Active/Standby.

Currently, we have one of our SRV records for collab-edge set at 5 (the backup is at 10) with the same weight.

The clustering guide says we should set the priority and weight on both SRV records the same, which will cause half of the registrations to go to the DR site. It is far away and has less capability.

How do we:

1 - Make sure the primary site handles all MRA registrations and the DR site is only used when the primary is down.
2 = Make sure failover occurs automatically... currently Jabber users have to log out and back in to connect to the DR site.


Thanks!


Jonathan

_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&amp;data=02%7C01%7C%7C2f536d8162984707853908d7a45d8e24%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637158594035084563&amp;sdata=atRtIR8sWZ60Ja8akD6GjzBIgBNC8GSJjaOmu%2BTxmWw%3D&amp;reserved=0<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7C%7C35f7cedb152248125f4208d7a4e906ec%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637159193060433500&sdata=7s%2FjS%2BEENAWy8oEweyh9GW3wQIfyyZ%2FiHmw7umbIKoM%3D&reserved=0>
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7C%7C35f7cedb152248125f4208d7a4e906ec%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637159193060443499&sdata=M0AwdZi5TgCAX1IsHIeO6uaghdGcqxyTsbInfWxp6a4%3D&reserved=0>
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7C%7C35f7cedb152248125f4208d7a4e906ec%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637159193060453510&sdata=JwzTTPmKVvLakn%2FDP%2FXLUd0SSYSI8fHdJec5MO%2ByTGk%3D&reserved=0>
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net
https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&amp;data=02%7C01%7C%7C35f7cedb152248125f4208d7a4e906ec%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637159193060493542&amp;sdata=3VK8%2Fkbl24XEiqsT%2FgPOQJywpgali457PnQ6ZcjSd%2FM%3D&amp;reserved=0

OK, maybe I am misunderstanding... I have th E's paired together as a
cluster and the C's paired together as a cluster... I have the C's
initiating a UCM traversal client to both E's... is this not correct?


Jonathan

On Tue, Jan 28, 2020 at 7:59 PM Lelio Fulgenzi <lelio@uoguelph.ca> wrote:

> I could be wrong here, but from what was explained to me...
>
> You may be able to control the initial connection from off-prem device to
> the E of your choosing, but you cannot control which C that E talks to. And
> vice-versa.
>
> So, you could point people to Ea, but they could easily be sent to Cs. And
> that traffic back from Cs could easily be sent to Es.
>
> I was told at one time, the only option would be to put hosts in
> maintenance mode or something like that. But it wasn’t advised.
>
> I’d love to hear other suggestions.
>
> *-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> | lelio@uoguelph.ca
>
>
>
> www.uoguelph.ca/ccs | @UofGCCS on Instagram, Twitter and Facebook
>
>
>
> [image: University of Guelph Cornerstone with Improve Life tagline]
>
> On Jan 28, 2020, at 8:49 PM, Jonathan Charles <jonvoip@gmail.com> wrote:
>
> We have two pairs of Expressway clusters (C/E) at two different locations
> (primary and DR)...
>
> The cluster is up, however, we want to make sure that we are in
> Active/Standby.
>
> Currently, we have one of our SRV records for collab-edge set at 5 (the
> backup is at 10) with the same weight.
>
> The clustering guide says we should set the priority and weight on both
> SRV records the same, which will cause half of the registrations to go to
> the DR site. It is far away and has less capability.
>
> How do we:
>
> 1 - Make sure the primary site handles all MRA registrations and the DR
> site is only used when the primary is down.
> 2 = Make sure failover occurs automatically... currently Jabber users have
> to log out and back in to connect to the DR site.
>
>
> Thanks!
>
>
> Jonathan
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>

That seems correct. It seems like you’re speaking about an outbound flow and Lelio is speaking about an inbound flow.

The traversal client cluster (the CS) should know about all the peers in the traversal server cluster (the Es).

Sent from my iPhone

On Jan 29, 2020, at 15:21, Jonathan Charles <jonvoip@gmail.com> wrote:

?
OK, maybe I am misunderstanding... I have th E's paired together as a cluster and the C's paired together as a cluster... I have the C's initiating a UCM traversal client to both E's... is this not correct?


Jonathan

On Tue, Jan 28, 2020 at 7:59 PM Lelio Fulgenzi <lelio@uoguelph.ca<mailto:lelio@uoguelph.ca>> wrote:
I could be wrong here, but from what was explained to me...

You may be able to control the initial connection from off-prem device to the E of your choosing, but you cannot control which C that E talks to. And vice-versa.

So, you could point people to Ea, but they could easily be sent to Cs. And that traffic back from Cs could easily be sent to Es.

I was told at one time, the only option would be to put hosts in maintenance mode or something like that. But it wasn’t advised.

I’d love to hear other suggestions.

-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<tel:519-824-4120;56354> | lelio@uoguelph.ca<mailto:lelio@uoguelph.ca>

www.uoguelph.ca/ccs<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.uoguelph.ca%2Fccs&data=02%7C01%7C%7C990b53ac7bf74dc9f6d908d7a4f8d85e%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637159260995053342&sdata=N%2F%2FyzmALTugonxBWql9Ed1RU91GlfciMVacel%2FTm6nU%3D&reserved=0> | @UofGCCS on Instagram, Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]

On Jan 28, 2020, at 8:49 PM, Jonathan Charles <jonvoip@gmail.com<mailto:jonvoip@gmail.com>> wrote:

We have two pairs of Expressway clusters (C/E) at two different locations (primary and DR)...

The cluster is up, however, we want to make sure that we are in Active/Standby.

Currently, we have one of our SRV records for collab-edge set at 5 (the backup is at 10) with the same weight.

The clustering guide says we should set the priority and weight on both SRV records the same, which will cause half of the registrations to go to the DR site. It is far away and has less capability.

How do we:

1 - Make sure the primary site handles all MRA registrations and the DR site is only used when the primary is down.
2 = Make sure failover occurs automatically... currently Jabber users have to log out and back in to connect to the DR site.


Thanks!


Jonathan

_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7C%7C990b53ac7bf74dc9f6d908d7a4f8d85e%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637159260995053342&sdata=Uc0yDIk78tTL3s3jGUD8YOn1BTAz8BQfsQn1IcmFsoY%3D&reserved=0>
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&amp;data=02%7C01%7C%7C990b53ac7bf74dc9f6d908d7a4f8d85e%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637159260995073329&amp;sdata=FiPM638B7JKc3x9OhTq2s9Tf1hqWUQ9chaJfw13bxkk%3D&amp;reserved=0

I mean an outbound flow... offnet Jabber calls PSTN... I need it to go to
primary DC... the only way I can force that is by lowering priority of the
collab-edge SRV record.

To force a failover, I put the primary in maintenance mode, then Jabber
times out and dies... log out, log back in and it connects to the DR.

If I set the SRVs to the same priority, it seems to connect thru the DR
site (out of spite).


Jonathan

On Wed, Jan 29, 2020 at 2:59 PM Ryan Huff <ryanhuff@outlook.com> wrote:

> That seems correct. It seems like you’re speaking about an outbound flow
> and Lelio is speaking about an inbound flow.
>
> The traversal client cluster (the CS) should know about all the peers in
> the traversal server cluster (the Es).
>
> Sent from my iPhone
>
> On Jan 29, 2020, at 15:21, Jonathan Charles <jonvoip@gmail.com> wrote:
>
> ?
> OK, maybe I am misunderstanding... I have th E's paired together as a
> cluster and the C's paired together as a cluster... I have the C's
> initiating a UCM traversal client to both E's... is this not correct?
>
>
> Jonathan
>
> On Tue, Jan 28, 2020 at 7:59 PM Lelio Fulgenzi <lelio@uoguelph.ca> wrote:
>
>> I could be wrong here, but from what was explained to me...
>>
>> You may be able to control the initial connection from off-prem device to
>> the E of your choosing, but you cannot control which C that E talks to. And
>> vice-versa.
>>
>> So, you could point people to Ea, but they could easily be sent to Cs.
>> And that traffic back from Cs could easily be sent to Es.
>>
>> I was told at one time, the only option would be to put hosts in
>> maintenance mode or something like that. But it wasn’t advised.
>>
>> I’d love to hear other suggestions.
>>
>> *-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> | lelio@uoguelph.ca
>>
>>
>>
>> www.uoguelph.ca/ccs
>> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.uoguelph.ca%2Fccs&data=02%7C01%7C%7C990b53ac7bf74dc9f6d908d7a4f8d85e%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637159260995053342&sdata=N%2F%2FyzmALTugonxBWql9Ed1RU91GlfciMVacel%2FTm6nU%3D&reserved=0> |
>> @UofGCCS on Instagram, Twitter and Facebook
>>
>>
>>
>> [image: University of Guelph Cornerstone with Improve Life tagline]
>>
>> On Jan 28, 2020, at 8:49 PM, Jonathan Charles <jonvoip@gmail.com> wrote:
>>
>> We have two pairs of Expressway clusters (C/E) at two different locations
>> (primary and DR)...
>>
>> The cluster is up, however, we want to make sure that we are in
>> Active/Standby.
>>
>> Currently, we have one of our SRV records for collab-edge set at 5 (the
>> backup is at 10) with the same weight.
>>
>> The clustering guide says we should set the priority and weight on both
>> SRV records the same, which will cause half of the registrations to go to
>> the DR site. It is far away and has less capability.
>>
>> How do we:
>>
>> 1 - Make sure the primary site handles all MRA registrations and the DR
>> site is only used when the primary is down.
>> 2 = Make sure failover occurs automatically... currently Jabber users
>> have to log out and back in to connect to the DR site.
>>
>>
>> Thanks!
>>
>>
>> Jonathan
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7C%7C990b53ac7bf74dc9f6d908d7a4f8d85e%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637159260995053342&sdata=Uc0yDIk78tTL3s3jGUD8YOn1BTAz8BQfsQn1IcmFsoY%3D&reserved=0>
>>
>> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&amp;data=02%7C01%7C%7C990b53ac7bf74dc9f6d908d7a4f8d85e%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637159260995073329&amp;sdata=FiPM638B7JKc3x9OhTq2s9Tf1hqWUQ9chaJfw13bxkk%3D&amp;reserved=0
>
>

So I changed the SRV records to be equal priority and weight... and
everything works fine.

If I put a C & E pair at a site in maintenance mode, we do NOT see
automatic reregistration of phone services to the other C/E pair at the
other site.

If you log out and back in, it does automatically reregister.

If we put one of the 4 Expressways in maintenance mode, it fails over
automatically.

How do we achieve automatic failover for MRA?


Jonathan


On Wed, Jan 29, 2020 at 3:17 PM Jonathan Charles <jonvoip@gmail.com> wrote:

> I mean an outbound flow... offnet Jabber calls PSTN... I need it to go to
> primary DC... the only way I can force that is by lowering priority of the
> collab-edge SRV record.
>
> To force a failover, I put the primary in maintenance mode, then Jabber
> times out and dies... log out, log back in and it connects to the DR.
>
> If I set the SRVs to the same priority, it seems to connect thru the DR
> site (out of spite).
>
>
> Jonathan
>
> On Wed, Jan 29, 2020 at 2:59 PM Ryan Huff <ryanhuff@outlook.com> wrote:
>
>> That seems correct. It seems like you’re speaking about an outbound flow
>> and Lelio is speaking about an inbound flow.
>>
>> The traversal client cluster (the CS) should know about all the peers in
>> the traversal server cluster (the Es).
>>
>> Sent from my iPhone
>>
>> On Jan 29, 2020, at 15:21, Jonathan Charles <jonvoip@gmail.com> wrote:
>>
>> ?
>> OK, maybe I am misunderstanding... I have th E's paired together as a
>> cluster and the C's paired together as a cluster... I have the C's
>> initiating a UCM traversal client to both E's... is this not correct?
>>
>>
>> Jonathan
>>
>> On Tue, Jan 28, 2020 at 7:59 PM Lelio Fulgenzi <lelio@uoguelph.ca> wrote:
>>
>>> I could be wrong here, but from what was explained to me...
>>>
>>> You may be able to control the initial connection from off-prem device
>>> to the E of your choosing, but you cannot control which C that E talks to.
>>> And vice-versa.
>>>
>>> So, you could point people to Ea, but they could easily be sent to Cs.
>>> And that traffic back from Cs could easily be sent to Es.
>>>
>>> I was told at one time, the only option would be to put hosts in
>>> maintenance mode or something like that. But it wasn’t advised.
>>>
>>> I’d love to hear other suggestions.
>>>
>>> *-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> | lelio@uoguelph.ca
>>>
>>>
>>>
>>> www.uoguelph.ca/ccs
>>> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.uoguelph.ca%2Fccs&data=02%7C01%7C%7C990b53ac7bf74dc9f6d908d7a4f8d85e%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637159260995053342&sdata=N%2F%2FyzmALTugonxBWql9Ed1RU91GlfciMVacel%2FTm6nU%3D&reserved=0> |
>>> @UofGCCS on Instagram, Twitter and Facebook
>>>
>>>
>>>
>>> [image: University of Guelph Cornerstone with Improve Life tagline]
>>>
>>> On Jan 28, 2020, at 8:49 PM, Jonathan Charles <jonvoip@gmail.com> wrote:
>>>
>>> We have two pairs of Expressway clusters (C/E) at two different
>>> locations (primary and DR)...
>>>
>>> The cluster is up, however, we want to make sure that we are in
>>> Active/Standby.
>>>
>>> Currently, we have one of our SRV records for collab-edge set at 5 (the
>>> backup is at 10) with the same weight.
>>>
>>> The clustering guide says we should set the priority and weight on both
>>> SRV records the same, which will cause half of the registrations to go to
>>> the DR site. It is far away and has less capability.
>>>
>>> How do we:
>>>
>>> 1 - Make sure the primary site handles all MRA registrations and the DR
>>> site is only used when the primary is down.
>>> 2 = Make sure failover occurs automatically... currently Jabber users
>>> have to log out and back in to connect to the DR site.
>>>
>>>
>>> Thanks!
>>>
>>>
>>> Jonathan
>>>
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7C%7C990b53ac7bf74dc9f6d908d7a4f8d85e%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637159260995053342&sdata=Uc0yDIk78tTL3s3jGUD8YOn1BTAz8BQfsQn1IcmFsoY%3D&reserved=0>
>>>
>>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip@puck.nether.net
>>
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&amp;data=02%7C01%7C%7C990b53ac7bf74dc9f6d908d7a4f8d85e%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637159260995073329&amp;sdata=FiPM638B7JKc3x9OhTq2s9Tf1hqWUQ9chaJfw13bxkk%3D&amp;reserved=0
>>
>>