PM
> *To:* Mark H. Turpin
> *Cc:* Gerence Guan ; Anthony Holloway <
> avholloway+cisco-v...@gmail.com>; cisco-voip voyp list <
> cisco-voip@puck.nether.net>
> *Subject:* Re: [cisco-voip] Expressway Cluster failover for MRA
>
> *** EXTERNAL EMAIL - DO NOT CLICK LINKS
cisco-v...@gmail.com>>
Cc: cisco-voip voyp list
mailto:cisco-voip@puck.nether.net>>
Subject: Re: [cisco-voip] Expressway Cluster failover for MRA
*** EXTERNAL EMAIL - DO NOT CLICK LINKS ***
@Brian
Clustering is not that critical. As long as the Jabber can register back via
the DR without any m
aboration Engineer – IT Infrastructure & Security
From: cisco-voip on behalf of "Mark H.
Turpin"
Date: Tuesday, July 7, 2020 at 2:41 PM
To: Gerence Guan , Anthony Holloway
Cc: cisco-voip voyp list
Subject: Re: [cisco-voip] Expressway Cluster failover for MRA
I don't belie
* Anthony Holloway
> *Cc:* cisco-voip voyp list
> *Subject:* Re: [cisco-voip] Expressway Cluster failover for MRA
>
> *** EXTERNAL EMAIL - DO NOT CLICK LINKS ***
>
> @Brian
> Clustering is not that critical. As long as the Jabber can register back
> via the DR without any m
Cc: cisco-voip voyp list
Subject: Re: [cisco-voip] Expressway Cluster failover for MRA
*** EXTERNAL EMAIL - DO NOT CLICK LINKS ***
@Brian
Clustering is not that critical. As long as the Jabber can register back via
the DR without any manual system level changes. It is acceptable even if users
@Brian
Clustering is not that critical. As long as the Jabber can register back
via the DR without any manual system level changes. It is acceptable even
if users need to logout and login jaber again.
@Anthony
it would be good if someone has that table. It will help a lot.
On Tue, Jul 7,
Brian,
This wouldn't support failover in all scenarios though, correct? E.g.,
CUCM sub to sub failover.
Does anyone have a nice table of failover scenarios covered and not covered
by expressway clustering versus not?
On Mon, Jul 6, 2020 at 9:29 AM Brian Meade wrote:
> I would not use Expressw
I would not use Expressway clustering and just have 2 different C/E pairs
with different SRV Weights/Priorities instead.
On Mon, Jul 6, 2020 at 3:17 AM Gerence Guan wrote:
> Hi Everyone.
>
> I was googling the answer for MRA failover and found this maillist.
> Got a similar setup as Jonathan's e
Hi Everyone.
I was googling the answer for MRA failover and found this maillist.
Got a similar setup as Jonathan's environment.
Having a pair of expressway C&E in primary DC, and planning to setup
another pair of expressway C&E in the DR site. All MRA should go via
primary DC, only use DR site whe
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 rereg
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 con
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
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 wrote:
> I could be wrong here,
e 2020 23:18
Para: Lelio Fulgenzi mailto:le...@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 go
Lelio Fulgenzi
> *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
> alw
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 i
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 i
> To: Jonathan Charles
> 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 influ
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 t
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
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 t
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. An
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 cluster
23 matches
Mail list logo
