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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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> | [email protected] >>> >>> >>> >>> 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 <[email protected]> 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 >>> [email protected] >>> 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 >> [email protected] >> >> 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%7C637159260995073329&sdata=FiPM638B7JKc3x9OhTq2s9Tf1hqWUQ9chaJfw13bxkk%3D&reserved=0 >> >>
_______________________________________________ cisco-voip mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-voip
