Mailing List Archive

Re: [EXT] Re: Expressway Cluster failover for MRA...
This has some failover info it:
https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X12-5/exwy_b_mra-expressway-deployment-guide/exwy_b_mra-expressway-deployment-guide_chapter_01.html

I think it’s fairly new for expressway 12.5.x guides, I don’t remember seeing it in 8.11 guides


Jeffrey McHugh | Practice Manager, Collaboration Services

[cid:Fidelus_3c42e82e-9666-4571-9a52-153c0a95720c.png]<http://www.fidelus.com/>
Fidelus Technologies, LLC
Named Best UC Provider in the USA<http://www.fidelus.com/fidelus-technologies-named-best-unified-communications-provider-in-the-usa/>
240 West 35th Street, 6th Floor, New York, NY 10001
+1-212-616-7801 office | +1-212-616-7850 fax | www.fidelus.com<http://www.fidelus.com/>
[cid:LinkedIn_bb1846fd-fe30-4493-adae-437fc220210d.png]<http://www.linkedin.com/company/fidelus-technologies/products>[cid:Twitter_4a5902fd-a650-4f4b-924a-b72459df5b8e.png]<http://www.twitter.com/FidelusUCC>[cid:Facebook_f02c6893-c48c-4d43-a030-92362ae2bdb3.png]<http://www.facebook.com/FidelusUCC>[cid:YouTube_e6262ffc-4cc2-4a50-8967-15cb4475a956.png]<http://www.youtube.com/FidelusTraining>

Disclaimer - This email and any files transmitted with it are confidential and intended solely for the person(s) addressed to. If you are not the named addressee you should not disseminate, distribute, copy or alter this email. Any views or opinions presented in this email are solely those of the author and might not represent those of Fidelus Technologies, LLC. Warning: Although Fidelus Technologies, LLC has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments.
From: cisco-voip <cisco-voip-bounces@puck.nether.net> On Behalf Of Jonathan Charles
Sent: Friday, February 7, 2020 11:22 PM
To: Ryan Huff <ryanhuff@outlook.com>
Cc: cisco-voip@puck.nether.net
Subject: [EXT] Re: [cisco-voip] Expressway Cluster failover for MRA...

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<mailto: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<mailto: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<mailto: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


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<mailto: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
Re: [EXT] Re: Expressway Cluster failover for MRA... [ In reply to ]
And what exactly is this note supposed to mean?

[image1.png]

Sent from my iPhone

On Feb 8, 2020, at 8:56 AM, Jeffrey McHugh <jmchugh@fidelus.com<mailto:jmchugh@fidelus.com>> wrote:

This has some failover info it:
https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X12-5/exwy_b_mra-expressway-deployment-guide/exwy_b_mra-expressway-deployment-guide_chapter_01.html

I think it’s fairly new for expressway 12.5.x guides, I don’t remember seeing it in 8.11 guides


Jeffrey McHugh | Practice Manager, Collaboration Services

<Fidelus_3c42e82e-9666-4571-9a52-153c0a95720c.png><http://www.fidelus.com/>
Fidelus Technologies, LLC
Named Best UC Provider in the USA<http://www.fidelus.com/fidelus-technologies-named-best-unified-communications-provider-in-the-usa/>
240 West 35th Street, 6th Floor, New York, NY 10001
+1-212-616-7801 office | +1-212-616-7850 fax | www.fidelus.com<http://www.fidelus.com/>
<LinkedIn_bb1846fd-fe30-4493-adae-437fc220210d.png><http://www.linkedin.com/company/fidelus-technologies/products><Twitter_4a5902fd-a650-4f4b-924a-b72459df5b8e.png><http://www.twitter.com/FidelusUCC><Facebook_f02c6893-c48c-4d43-a030-92362ae2bdb3.png><http://www.facebook.com/FidelusUCC><YouTube_e6262ffc-4cc2-4a50-8967-15cb4475a956.png><http://www.youtube.com/FidelusTraining>

Disclaimer - This email and any files transmitted with it are confidential and intended solely for the person(s) addressed to. If you are not the named addressee you should not disseminate, distribute, copy or alter this email. Any views or opinions presented in this email are solely those of the author and might not represent those of Fidelus Technologies, LLC. Warning: Although Fidelus Technologies, LLC has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments.
From: cisco-voip <cisco-voip-bounces@puck.nether.net<mailto:cisco-voip-bounces@puck.nether.net>> On Behalf Of Jonathan Charles
Sent: Friday, February 7, 2020 11:22 PM
To: Ryan Huff <ryanhuff@outlook.com<mailto:ryanhuff@outlook.com>>
Cc: cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
Subject: [EXT] Re: [cisco-voip] Expressway Cluster failover for MRA...

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<mailto: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<mailto: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<mailto: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


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<mailto: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
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
Re: [EXT] Re: Expressway Cluster failover for MRA... [ In reply to ]
I think your red boxed note may be specifically apply to the part about UDS.

Sent from my iPhone

On Feb 8, 2020, at 09:16, Lelio Fulgenzi <lelio@uoguelph.ca> wrote:

?

And what exactly is this note supposed to mean?

<image1.png>


Sent from my iPhone

On Feb 8, 2020, at 8:56 AM, Jeffrey McHugh <jmchugh@fidelus.com<mailto:jmchugh@fidelus.com>> wrote:

This has some failover info it:
https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X12-5/exwy_b_mra-expressway-deployment-guide/exwy_b_mra-expressway-deployment-guide_chapter_01.html<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.cisco.com%2Fc%2Fen%2Fus%2Ftd%2Fdocs%2Fvoice_ip_comm%2Fexpressway%2Fconfig_guide%2FX12-5%2Fexwy_b_mra-expressway-deployment-guide%2Fexwy_b_mra-expressway-deployment-guide_chapter_01.html&data=02%7C01%7C%7C200453c8a19f42b080ab08d7aca179b8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637167681839179756&sdata=Scz9wNxzK%2Fe2l7kF0c2t3tXoGiwhKjWOL2XFyzNixbs%3D&reserved=0>

I think it’s fairly new for expressway 12.5.x guides, I don’t remember seeing it in 8.11 guides


Jeffrey McHugh | Practice Manager, Collaboration Services

<Fidelus_3c42e82e-9666-4571-9a52-153c0a95720c.png><https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.fidelus.com%2F&data=02%7C01%7C%7C200453c8a19f42b080ab08d7aca179b8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637167681839189761&sdata=EvoTYq9gcLoOouos1wsBrudNdPzCwq4R1ptWcy3%2FyP0%3D&reserved=0>
Fidelus Technologies, LLC
Named Best UC Provider in the USA<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.fidelus.com%2Ffidelus-technologies-named-best-unified-communications-provider-in-the-usa%2F&data=02%7C01%7C%7C200453c8a19f42b080ab08d7aca179b8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637167681839199772&sdata=qvr3y%2B5oo480%2BDZOpukY7QoLpQw%2BnK9uJGdygxOYLHw%3D&reserved=0>
240 West 35th Street, 6th Floor, New York, NY 10001
+1-212-616-7801 office | +1-212-616-7850 fax | www.fidelus.com<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.fidelus.com%2F&data=02%7C01%7C%7C200453c8a19f42b080ab08d7aca179b8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637167681839209777&sdata=05jMnpShRx6cEDx%2BR6LIGYwupJoLMpdNvOvbne9kuSc%3D&reserved=0>
<LinkedIn_bb1846fd-fe30-4493-adae-437fc220210d.png><https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.linkedin.com%2Fcompany%2Ffidelus-technologies%2Fproducts&data=02%7C01%7C%7C200453c8a19f42b080ab08d7aca179b8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637167681839219788&sdata=U1xsznxGJ5XI1CtCcvThGUGWBrGhvq4jg365D3sZBxo%3D&reserved=0><Twitter_4a5902fd-a650-4f4b-924a-b72459df5b8e.png><https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.twitter.com%2FFidelusUCC&data=02%7C01%7C%7C200453c8a19f42b080ab08d7aca179b8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637167681839229794&sdata=nKhb1r%2BFgDsYNQk40yO6Zc3DW%2B2hHfFjgx7nUylH0wI%3D&reserved=0><Facebook_f02c6893-c48c-4d43-a030-92362ae2bdb3.png><https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.facebook.com%2FFidelusUCC&data=02%7C01%7C%7C200453c8a19f42b080ab08d7aca179b8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637167681839239805&sdata=4GOab7TD1QRMowLu%2FpzpDcjrANtje%2FDtV1VhO1lddy4%3D&reserved=0><YouTube_e6262ffc-4cc2-4a50-8967-15cb4475a956.png><https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.youtube.com%2FFidelusTraining&data=02%7C01%7C%7C200453c8a19f42b080ab08d7aca179b8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637167681839249810&sdata=G7zGZmjbjeXSLMHOcmQ8xVzSq%2BOyI2sP5fEui1zrcfk%3D&reserved=0>

Disclaimer - This email and any files transmitted with it are confidential and intended solely for the person(s) addressed to. If you are not the named addressee you should not disseminate, distribute, copy or alter this email. Any views or opinions presented in this email are solely those of the author and might not represent those of Fidelus Technologies, LLC. Warning: Although Fidelus Technologies, LLC has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments.
From: cisco-voip <cisco-voip-bounces@puck.nether.net<mailto:cisco-voip-bounces@puck.nether.net>> On Behalf Of Jonathan Charles
Sent: Friday, February 7, 2020 11:22 PM
To: Ryan Huff <ryanhuff@outlook.com<mailto:ryanhuff@outlook.com>>
Cc: cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
Subject: [EXT] Re: [cisco-voip] Expressway Cluster failover for MRA...

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<mailto: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<mailto: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<mailto: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://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.uoguelph.ca%2Fccs&data=02%7C01%7C%7C200453c8a19f42b080ab08d7aca179b8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637167681839249810&sdata=%2B7Y40lDahZR4SEm6LbfNZxtSbkc5IueBXm5HyRUg08I%3D&reserved=0> | @UofGCCS on Instagram, Twitter and Facebook


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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7C%7C200453c8a19f42b080ab08d7aca179b8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637167681839259821&sdata=FW6y9dxw%2BRhnqISwPIuUJEk8yASnZyZsm%2FT6%2BwRv3Sg%3D&reserved=0>
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto: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<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7C%7C200453c8a19f42b080ab08d7aca179b8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637167681839269826&sdata=gGzkrtQvvRBqQm7VH%2BzimGgDWSZaNQHHhM2iDb1nWZs%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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7C%7C200453c8a19f42b080ab08d7aca179b8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637167681839279837&sdata=kR3opDoQbOVWl2JLRb5gT1BqE97054MitN1OxeKox%2BU%3D&reserved=0>
Re: [EXT] Re: Expressway Cluster failover for MRA... [ In reply to ]
In our experience, CE endpoints and jabber failover to other call manager
nodes fine if the primary pair fails but 8865 phones don’t register to
other call managers (only first ccm in their ucm group). We tested this
several ways with TAC and BU. A few bug IDs filed for documentation
improvement and feature requests.


On Sat, Feb 8, 2020 at 7:59 AM Ryan Huff <ryanhuff@outlook.com> wrote:

> I think your red boxed note may be specifically apply to the part about
> UDS.
>
> Sent from my iPhone
>
> On Feb 8, 2020, at 09:16, Lelio Fulgenzi <lelio@uoguelph.ca> wrote:
>
> ?
>
>
> And what exactly is this note supposed to mean?
>
> <image1.png>
>
>
> Sent from my iPhone
>
> On Feb 8, 2020, at 8:56 AM, Jeffrey McHugh <jmchugh@fidelus.com> wrote:
>
> This has some failover info it:
>
>
> https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X12-5/exwy_b_mra-expressway-deployment-guide/exwy_b_mra-expressway-deployment-guide_chapter_01.html
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.cisco.com%2Fc%2Fen%2Fus%2Ftd%2Fdocs%2Fvoice_ip_comm%2Fexpressway%2Fconfig_guide%2FX12-5%2Fexwy_b_mra-expressway-deployment-guide%2Fexwy_b_mra-expressway-deployment-guide_chapter_01.html&data=02%7C01%7C%7C200453c8a19f42b080ab08d7aca179b8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637167681839179756&sdata=Scz9wNxzK%2Fe2l7kF0c2t3tXoGiwhKjWOL2XFyzNixbs%3D&reserved=0>
>
>
>
> I think it’s fairly new for expressway 12.5.x guides, I don’t remember
> seeing it in 8.11 guides
>
>
>
> *Jeffrey McHugh* | Practice Manager, Collaboration Services
> <Fidelus_3c42e82e-9666-4571-9a52-153c0a95720c.png>
> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.fidelus.com%2F&data=02%7C01%7C%7C200453c8a19f42b080ab08d7aca179b8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637167681839189761&sdata=EvoTYq9gcLoOouos1wsBrudNdPzCwq4R1ptWcy3%2FyP0%3D&reserved=0>
> *Fidelus Technologies, LLC*
> Named Best UC Provider in the USA
> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.fidelus.com%2Ffidelus-technologies-named-best-unified-communications-provider-in-the-usa%2F&data=02%7C01%7C%7C200453c8a19f42b080ab08d7aca179b8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637167681839199772&sdata=qvr3y%2B5oo480%2BDZOpukY7QoLpQw%2BnK9uJGdygxOYLHw%3D&reserved=0>
> 240 West 35th Street, 6th Floor, New York, NY 10001
> <https://www.google.com/maps/search/240%0D%0A+West+35th+Street,+6th+Floor,+New+York,+NY+10001?entry=gmail&source=g>
> *+1-212-616-7801* office | *+1-212-616-7850 *fax | www.fidelus.com
> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.fidelus.com%2F&data=02%7C01%7C%7C200453c8a19f42b080ab08d7aca179b8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637167681839209777&sdata=05jMnpShRx6cEDx%2BR6LIGYwupJoLMpdNvOvbne9kuSc%3D&reserved=0>
> <LinkedIn_bb1846fd-fe30-4493-adae-437fc220210d.png>
> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.linkedin.com%2Fcompany%2Ffidelus-technologies%2Fproducts&data=02%7C01%7C%7C200453c8a19f42b080ab08d7aca179b8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637167681839219788&sdata=U1xsznxGJ5XI1CtCcvThGUGWBrGhvq4jg365D3sZBxo%3D&reserved=0>
> <Twitter_4a5902fd-a650-4f4b-924a-b72459df5b8e.png>
> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.twitter.com%2FFidelusUCC&data=02%7C01%7C%7C200453c8a19f42b080ab08d7aca179b8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637167681839229794&sdata=nKhb1r%2BFgDsYNQk40yO6Zc3DW%2B2hHfFjgx7nUylH0wI%3D&reserved=0>
> <Facebook_f02c6893-c48c-4d43-a030-92362ae2bdb3.png>
> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.facebook.com%2FFidelusUCC&data=02%7C01%7C%7C200453c8a19f42b080ab08d7aca179b8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637167681839239805&sdata=4GOab7TD1QRMowLu%2FpzpDcjrANtje%2FDtV1VhO1lddy4%3D&reserved=0>
> <YouTube_e6262ffc-4cc2-4a50-8967-15cb4475a956.png>
> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.youtube.com%2FFidelusTraining&data=02%7C01%7C%7C200453c8a19f42b080ab08d7aca179b8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637167681839249810&sdata=G7zGZmjbjeXSLMHOcmQ8xVzSq%2BOyI2sP5fEui1zrcfk%3D&reserved=0>
>
> Disclaimer - This email and any files transmitted with it are confidential
> and intended solely for the person(s) addressed to. If you are not the
> named addressee you should not disseminate, distribute, copy or alter this
> email. Any views or opinions presented in this email are solely those of
> the author and might not represent those of Fidelus Technologies, LLC.
> Warning: Although Fidelus Technologies, LLC has taken reasonable
> precautions to ensure no viruses are present in this email, the company
> cannot accept responsibility for any loss or damage arising from the use of
> this email or attachments.
>
> *From:* cisco-voip <cisco-voip-bounces@puck.nether.net> *On Behalf Of *Jonathan
> Charles
> *Sent:* Friday, February 7, 2020 11:22 PM
> *To:* Ryan Huff <ryanhuff@outlook.com>
> *Cc:* cisco-voip@puck.nether.net
> *Subject:* [EXT] Re: [cisco-voip] Expressway Cluster failover for MRA...
>
>
>
> 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
> <https://www.google.com/maps/search/50+Stone+Rd+E+%7C+Guelph,+ON+%7C+N1G+2W1?entry=gmail&source=g>
>
> 519-824-4120 Ext. 56354 <519-824-4120;56354> | lelio@uoguelph.ca
>
>
>
> www.uoguelph.ca/ccs
> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.uoguelph.ca%2Fccs&data=02%7C01%7C%7C200453c8a19f42b080ab08d7aca179b8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637167681839249810&sdata=%2B7Y40lDahZR4SEm6LbfNZxtSbkc5IueBXm5HyRUg08I%3D&reserved=0> |
> @UofGCCS on Instagram, Twitter and Facebook
>
>
>
>
> 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7C%7C200453c8a19f42b080ab08d7aca179b8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637167681839259821&sdata=FW6y9dxw%2BRhnqISwPIuUJEk8yASnZyZsm%2FT6%2BwRv3Sg%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
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7C%7C200453c8a19f42b080ab08d7aca179b8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637167681839269826&sdata=gGzkrtQvvRBqQm7VH%2BzimGgDWSZaNQHHhM2iDb1nWZs%3D&reserved=0>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7C%7C200453c8a19f42b080ab08d7aca179b8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637167681839279837&sdata=kR3opDoQbOVWl2JLRb5gT1BqE97054MitN1OxeKox%2BU%3D&reserved=0>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
Re: [EXT] Re: Expressway Cluster failover for MRA... [ In reply to ]
:O

Do you have some bugs to share?

We’re looking at a fleet of 8851s.

Not registering to secondary CCMs is huge.

Sent from my iPhone

On Feb 8, 2020, at 3:40 PM, Erick Bergquist <erickbee@gmail.com<mailto:erickbee@gmail.com>> wrote:

In our experience, CE endpoints and jabber failover to other call manager nodes fine if the primary pair fails but 8865 phones don’t register to other call managers (only first ccm in their ucm group). We tested this several ways with TAC and BU. A few bug IDs filed for documentation improvement and feature requests.


On Sat, Feb 8, 2020 at 7:59 AM Ryan Huff <ryanhuff@outlook.com<mailto:ryanhuff@outlook.com>> wrote:
I think your red boxed note may be specifically apply to the part about UDS.

Sent from my iPhone

On Feb 8, 2020, at 09:16, Lelio Fulgenzi <lelio@uoguelph.ca<mailto:lelio@uoguelph.ca>> wrote:

?

And what exactly is this note supposed to mean?

<image1.png>


Sent from my iPhone

On Feb 8, 2020, at 8:56 AM, Jeffrey McHugh <jmchugh@fidelus.com<mailto:jmchugh@fidelus.com>> wrote:

This has some failover info it:
https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X12-5/exwy_b_mra-expressway-deployment-guide/exwy_b_mra-expressway-deployment-guide_chapter_01.html<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.cisco.com%2Fc%2Fen%2Fus%2Ftd%2Fdocs%2Fvoice_ip_comm%2Fexpressway%2Fconfig_guide%2FX12-5%2Fexwy_b_mra-expressway-deployment-guide%2Fexwy_b_mra-expressway-deployment-guide_chapter_01.html&data=02%7C01%7C%7C200453c8a19f42b080ab08d7aca179b8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637167681839179756&sdata=Scz9wNxzK%2Fe2l7kF0c2t3tXoGiwhKjWOL2XFyzNixbs%3D&reserved=0>

I think it’s fairly new for expressway 12.5.x guides, I don’t remember seeing it in 8.11 guides


Jeffrey McHugh | Practice Manager, Collaboration Services

<Fidelus_3c42e82e-9666-4571-9a52-153c0a95720c.png><https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.fidelus.com%2F&data=02%7C01%7C%7C200453c8a19f42b080ab08d7aca179b8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637167681839189761&sdata=EvoTYq9gcLoOouos1wsBrudNdPzCwq4R1ptWcy3%2FyP0%3D&reserved=0>
Fidelus Technologies, LLC
Named Best UC Provider in the USA<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.fidelus.com%2Ffidelus-technologies-named-best-unified-communications-provider-in-the-usa%2F&data=02%7C01%7C%7C200453c8a19f42b080ab08d7aca179b8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637167681839199772&sdata=qvr3y%2B5oo480%2BDZOpukY7QoLpQw%2BnK9uJGdygxOYLHw%3D&reserved=0>
240 West 35th Street, 6th Floor, New York, NY 10001<https://www.google.com/maps/search/240%0D%0A+West+35th+Street,+6th+Floor,+New+York,+NY+10001?entry=gmail&source=g>
+1-212-616-7801 office | +1-212-616-7850 fax | www.fidelus.com<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.fidelus.com%2F&data=02%7C01%7C%7C200453c8a19f42b080ab08d7aca179b8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637167681839209777&sdata=05jMnpShRx6cEDx%2BR6LIGYwupJoLMpdNvOvbne9kuSc%3D&reserved=0>
<LinkedIn_bb1846fd-fe30-4493-adae-437fc220210d.png><https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.linkedin.com%2Fcompany%2Ffidelus-technologies%2Fproducts&data=02%7C01%7C%7C200453c8a19f42b080ab08d7aca179b8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637167681839219788&sdata=U1xsznxGJ5XI1CtCcvThGUGWBrGhvq4jg365D3sZBxo%3D&reserved=0><Twitter_4a5902fd-a650-4f4b-924a-b72459df5b8e.png><https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.twitter.com%2FFidelusUCC&data=02%7C01%7C%7C200453c8a19f42b080ab08d7aca179b8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637167681839229794&sdata=nKhb1r%2BFgDsYNQk40yO6Zc3DW%2B2hHfFjgx7nUylH0wI%3D&reserved=0><Facebook_f02c6893-c48c-4d43-a030-92362ae2bdb3.png><https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.facebook.com%2FFidelusUCC&data=02%7C01%7C%7C200453c8a19f42b080ab08d7aca179b8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637167681839239805&sdata=4GOab7TD1QRMowLu%2FpzpDcjrANtje%2FDtV1VhO1lddy4%3D&reserved=0><YouTube_e6262ffc-4cc2-4a50-8967-15cb4475a956.png><https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.youtube.com%2FFidelusTraining&data=02%7C01%7C%7C200453c8a19f42b080ab08d7aca179b8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637167681839249810&sdata=G7zGZmjbjeXSLMHOcmQ8xVzSq%2BOyI2sP5fEui1zrcfk%3D&reserved=0>

Disclaimer - This email and any files transmitted with it are confidential and intended solely for the person(s) addressed to. If you are not the named addressee you should not disseminate, distribute, copy or alter this email. Any views or opinions presented in this email are solely those of the author and might not represent those of Fidelus Technologies, LLC. Warning: Although Fidelus Technologies, LLC has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments.
From: cisco-voip <cisco-voip-bounces@puck.nether.net<mailto:cisco-voip-bounces@puck.nether.net>> On Behalf Of Jonathan Charles
Sent: Friday, February 7, 2020 11:22 PM
To: Ryan Huff <ryanhuff@outlook.com<mailto:ryanhuff@outlook.com>>
Cc: cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
Subject: [EXT] Re: [cisco-voip] Expressway Cluster failover for MRA...

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<mailto: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<mailto: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<mailto: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<https://www.google.com/maps/search/50+Stone+Rd+E+%7C+Guelph,+ON+%7C+N1G+2W1?entry=gmail&source=g>
519-824-4120 Ext. 56354<tel:519-824-4120;56354> | lelio@uoguelph.ca<mailto:lelio@uoguelph.ca>

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


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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7C%7C200453c8a19f42b080ab08d7aca179b8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637167681839259821&sdata=FW6y9dxw%2BRhnqISwPIuUJEk8yASnZyZsm%2FT6%2BwRv3Sg%3D&reserved=0>
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto: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<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7C%7C200453c8a19f42b080ab08d7aca179b8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637167681839269826&sdata=gGzkrtQvvRBqQm7VH%2BzimGgDWSZaNQHHhM2iDb1nWZs%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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7C%7C200453c8a19f42b080ab08d7aca179b8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637167681839279837&sdata=kR3opDoQbOVWl2JLRb5gT1BqE97054MitN1OxeKox%2BU%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
Re: [EXT] Re: Expressway Cluster failover for MRA... [ In reply to ]
CSCvs31577 - 8800 Series phones to try all possible path for UCM
failover over MRA


CSCvs31556 -- Documentation updates regarding failover support


On Sat, Feb 8, 2020 at 2:47 PM Lelio Fulgenzi <lelio@uoguelph.ca> wrote:
>
>
> :O
>
> Do you have some bugs to share?
>
> We’re looking at a fleet of 8851s.
>
> Not registering to secondary CCMs is huge.
>
> Sent from my iPhone
>
> On Feb 8, 2020, at 3:40 PM, Erick Bergquist <erickbee@gmail.com> wrote:
>
> In our experience, CE endpoints and jabber failover to other call manager nodes fine if the primary pair fails but 8865 phones don’t register to other call managers (only first ccm in their ucm group). We tested this several ways with TAC and BU. A few bug IDs filed for documentation improvement and feature requests.
>
>
> On Sat, Feb 8, 2020 at 7:59 AM Ryan Huff <ryanhuff@outlook.com> wrote:
>>
>> I think your red boxed note may be specifically apply to the part about UDS.
>>
>> Sent from my iPhone
>>
>> On Feb 8, 2020, at 09:16, Lelio Fulgenzi <lelio@uoguelph.ca> wrote:
>>
>> ?
>>
>>
>> And what exactly is this note supposed to mean?
>>
>> <image1.png>
>>
>>
>> Sent from my iPhone
>>
>> On Feb 8, 2020, at 8:56 AM, Jeffrey McHugh <jmchugh@fidelus.com> wrote:
>>
>> This has some failover info it:
>>
>> https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X12-5/exwy_b_mra-expressway-deployment-guide/exwy_b_mra-expressway-deployment-guide_chapter_01.html
>>
>>
>>
>> I think it’s fairly new for expressway 12.5.x guides, I don’t remember seeing it in 8.11 guides
>>
>>
>>
>> Jeffrey McHugh | Practice Manager, Collaboration Services
>>
>> <Fidelus_3c42e82e-9666-4571-9a52-153c0a95720c.png>
>> Fidelus Technologies, LLC
>> Named Best UC Provider in the USA
>> 240 West 35th Street, 6th Floor, New York, NY 10001
>> +1-212-616-7801 office | +1-212-616-7850 fax | www.fidelus.com
>> <LinkedIn_bb1846fd-fe30-4493-adae-437fc220210d.png><Twitter_4a5902fd-a650-4f4b-924a-b72459df5b8e.png><Facebook_f02c6893-c48c-4d43-a030-92362ae2bdb3.png><YouTube_e6262ffc-4cc2-4a50-8967-15cb4475a956.png>
>>
>> Disclaimer - This email and any files transmitted with it are confidential and intended solely for the person(s) addressed to. If you are not the named addressee you should not disseminate, distribute, copy or alter this email. Any views or opinions presented in this email are solely those of the author and might not represent those of Fidelus Technologies, LLC. Warning: Although Fidelus Technologies, LLC has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments.
>>
>> From: cisco-voip <cisco-voip-bounces@puck.nether.net> On Behalf Of Jonathan Charles
>> Sent: Friday, February 7, 2020 11:22 PM
>> To: Ryan Huff <ryanhuff@outlook.com>
>> Cc: cisco-voip@puck.nether.net
>> Subject: [EXT] Re: [cisco-voip] Expressway Cluster failover for MRA...
>>
>>
>>
>> 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 | lelio@uoguelph.ca
>>
>>
>>
>> www.uoguelph.ca/ccs | @UofGCCS on Instagram, Twitter and Facebook
>>
>>
>>
>>
>> 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
>>
>> _______________________________________________
>> 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
>>
>> _______________________________________________
>> 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