[cisco-voip] SIP Fail over

[Ryan Huff]

Additionally, I’m not suggesting that ntp master x, is a valid way to serve NTP to UCOS in a production sense, because as Anthony stated, the local clock really isn’t a true NTPv4 server.

What I am saying is that in a DR/outage scenario, can be used to keep cluster communications ... etc in sync, until you can sync to real NTP severs again.

Ideally, you are monitoring “things” in the network and are aware of the NTP sync outage, or other event that caused the NTP sync outage (carrier failure ... etc).

However, as Anthony also mentioned, you must do the due diligence to make sure the local clock remains a fallback, and is only promoted from association to synchronization, if needed.

Sent from my iPhone

On Dec 20, 2018, at 18:17, Ryan Huff <ryanhuff at outlook.com<mailto:ryanhuff at outlook.com>> wrote:

Corrected sentence:

“CCM syncs to a local ntp master set at 2 just fine; yields the CCM pub at S3 and cluster subs at S4...”

Sent from my iPhone

On Dec 20, 2018, at 18:12, Ryan Huff <ryanhuff at outlook.com<mailto:ryanhuff at outlook.com>> wrote:

CCM syncs to a local ntp master set at 2 just fine; yields the CCM pub at S3 and cluster subs at S3...

Alternatively, if your router syncs to an S1, and CCM Pub subsequently sync’ed to said router, you’ll find the CCM pub happily at S2 and the cluster subs then at an S3. Works great actually.

Sent from my iPhone

On Dec 20, 2018, at 18:05, Anthony Holloway <avholloway+cisco-voip at gmail.com<mailto:avholloway+cisco-voip at gmail.com>> wrote:

Nate,

Good point.  Might be hard to finesse a fake stratum into the master command, without accidentally messing with the selection process.  Stratum number isn't the only criteria, and the process seems to be pretty complex.

Looks like we might not be able to have our cake and eat it too.

You must be referring to the following sentence from the CUCM SRND<https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.cisco.com%2Fc%2Fen%2Fus%2Ftd%2Fdocs%2Fvoice_ip_comm%2Fcucm%2Fsrnd%2Fcollab12%2Fcollab12%2Fnetstruc.html%23pgfId-1497943&data=02%7C01%7C%7Cd0b99f8e3a39490987a408d666d156bf%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636809446622332644&sdata=4Nt3sjTKA9i8C%2BUldasGaflyWel8I0Xe%2Brb30wQadoY%3D&reserved=0>:

"Cisco highly recommends configuring the publisher to point to a Stratum-1, Stratum-2, or Stratum-3 NTP server to ensure that the cluster time is synchronized with an external time source."







On Thu, Dec 20, 2018 at 4:46 PM NateCCIE <nateccie at gmail.com<mailto:nateccie at gmail.com>> wrote:
I think the lowest cucm will use is a 3?

Sent from my iPhone

On Dec 20, 2018, at 3:35 PM, Anthony Holloway <avholloway+cisco-voip at gmail.com<mailto:avholloway+cisco-voip at gmail.com>> wrote:

I have never seen that done before.  I like it!

Just be careful hard coding your stratum to a value of 2 all the time.  Instead it should be a relative value, higher than your reference clock.  Or if you do want a one-size-fits-all stratum, 14 maybe<https://nam05.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsupport.ntp.org%2Fbin%2Fview%2FSupport%2FSelectingOffsiteNTPServers%23Section_5.3.5.&data=02%7C01%7C%7Cd0b99f8e3a39490987a408d666d156bf%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636809446622332644&sdata=FXaGwkKPhFdDTU%2FKbP4nrrJrlJF6tNbF7ejvbrfogBI%3D&reserved=0>?

Thanks for sharing that tip Ryan!



On Thu, Dec 20, 2018 at 3:52 PM Ryan Huff <ryanhuff at outlook.com<mailto:ryanhuff at outlook.com>> wrote:
I like ntp master 2 as a fallback, to allow synchronization with the local device clock in a DR/Outage scenario where I fail sync to the actual reference clock

Sent from my iPhone

On Dec 20, 2018, at 14:51, Anthony Holloway <avholloway+cisco-voip at gmail.com<mailto:avholloway+cisco-voip at gmail.com>> wrote:

It's very interesting to me the kinds of things people take for granted and go a long time without ever being corrected, simply because the people who know these things, think it's common knowledge.

For example, I had a conversation with a senior collab person once, who didn't know that region bit rate settings were a ceiling, and that a lower bit rate could be negotiated.

And as another example, Engineers who put ntp master on a router because they think this makes the router an NTP server.

And as one last example, Engineers who use the ^ symbol at the beginning of a Dial Peer destination pattern, not knowing that destination patterns are left justified implicitly.  Or alternatively, don't use the $ at the end, effectively creating a "begins with" clause, when an "is exactly" clause is desired.

Someone should start a thread titled: What is something you found out that you were wrong about for a long time?

On Thu, Dec 20, 2018 at 1:14 PM Lelio Fulgenzi <lelio at uoguelph.ca<mailto:lelio at uoguelph.ca>> wrote:

I’ll be honest. I didn’t know there was a difference.

I’m guessing a SIP trunk to a third party app that is reported as down due to to sip option ping really is down and not some silly networking issue where an icmp ping was failing.

This is good to know.

And the last thing I will learn this year. ;)



-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 at uoguelph.ca<mailto:lelio at uoguelph.ca>

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

[University of Guelph Cornerstone with Improve Life tagline]

On Dec 20, 2018, at 1:01 PM, Anthony Holloway <avholloway+cisco-voip at gmail.com<mailto:avholloway+cisco-voip at gmail.com>> wrote:

Erik,

That's an interesting insight.  It kind of sounds like you think ICMP Ping and SIP OPTIONS Ping are related, but they are completely different.

Just because you cannot ICMP Ping the SIP Peer at L3, doesn't mean you cannot OPTIONs them.

Am I understanding your thought process correctly?

On Thu, Dec 20, 2018 at 11:53 AM Ryan Huff <ryanhuff at outlook.com<mailto:ryanhuff at outlook.com>> wrote:


Thanks,

Ryan Huff, CCDP, CCNP
Cisco Certified Network and Design Professional

________________________________
From: Ryan Huff <ryanhuff at outlook.com<mailto:ryanhuff at outlook.com>>
Sent: Thursday, December 20, 2018 12:46 PM
To: Erik Anderson
Subject: Re: [cisco-voip] SIP Fail over

Not sure what kind of code you're working with but if its modern, you could try server groups. Here is a snippet from one of mine (using AT&T admitidly), sanitized for the NSA ...

voice class server-group 100
 ipv4 12.x.x.x preference 1
 ipv4 12.x.x.x preference 2
 ipv4 12.x.x.x preference 3
 ipv4 12.x.x.x preference 1
 description PSTN SIGNALING PEERS
!
voice class server-group 200
 ipv4 10.x.x.x preference 3
 ipv4 10.x.x.x preference 1
 ipv4 10.x.x.x preference 2
 description CUCM SIGNALING PEERS
!
voice class sip-options-keepalive 100
 description PSTN HEARTBEAT
!
voice class sip-options-keepalive 200
 description CCM HEARTBEAT
!
{ .. other config .. }

dial-peer voice 100 voip
 description INGRESS/EGRESS WITH PSTN
 translation-profile outgoing PLUS1_STRIP
 huntstop
 destination-pattern A
 session protocol sipv2
 session server-group 100
 destination dpg 200
 incoming uri via PSTN
 voice-class codec 1
 voice-class sip options-ping 60
 voice-class sip profiles 100
 voice-class sip options-keepalive profile 100
 voice-class sip bind control source-interface XXXX
 voice-class sip bind media source-interface XXXX
 dtmf-relay rtp-nte sip-notify
 no vad
!
dial-peer voice 200 voip
 description INGRESS/EGRESS WITH CUCM
 translation-profile outgoing PLUS1_STRIP
 huntstop
 destination-pattern A
 session protocol sipv2
 session server-group 200
 destination dpg 100
 incoming uri via CUCM
 voice-class codec 1
 voice-class sip profiles 200
 voice-class sip options-keepalive profile 200
 voice-class sip bind control source-interface XXXX
 voice-class sip bind media source-interface XXXX
 dtmf-relay rtp-nte sip-notify
 no vad
!

Thanks,

Ryan Huff, CCDP, CCNP
Cisco Certified Network and Design Professional

________________________________
From: Erik Anderson <erik.anderson.85 at gmail.com<mailto:erik.anderson.85 at gmail.com>>
Sent: Thursday, December 20, 2018 12:37 PM
To: Ryan Huff
Subject: Re: [cisco-voip] SIP Fail over

Ryan,

Level 3 does not support options ping. If i try to ping the call control IP it will always fail. There is a separate pingable address, but I didnt think i could configure the options ping to use any address other than the target.

On Thu, Dec 20, 2018 at 11:34 AM Ryan Huff <ryanhuff at outlook.com<mailto:ryanhuff at outlook.com>> wrote:
Couldn't you just use voice class sip options/keepalives to mark when the ITSP is down, so CUCM marks the trunk out of service and fails to the next route group member immediately (ideally, your secondary CUBE)? Seems like thats a more natural way of doing it versus using IP SLAs...

Thanks,

- Ryan
________________________________
From: cisco-voip <cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at puck.nether.net>> on behalf of Erik Anderson <erik.anderson.85 at gmail.com<mailto:erik.anderson.85 at gmail.com>>
Sent: Thursday, December 20, 2018 12:03 PM
To: cisco-voip voyp list
Subject: [cisco-voip] SIP Fail over

Morning Folks,


We have implemented a new SIP solution with Level 3 and found that we have outbound calling failover issues. When a CUBE loses its ability to talk to its Level 3 Peer, but can still talk to CUCM outbound calls will still connect to the CUBE, but fail connecting to Level 3. In turn CUCM still thinks the call is connected since the CUCM SIP trunk remains up to the CUBE.



Architecture Notes:



4 Locations with 1 CUBE Each

4 CUCM SIP Trunks with each connecting to one of the 4 CUBEs

4 CUCM Route Groups with Various CUBE/SIP Trunks assigned a Distribution Algorithm of Top Down

Each CUBE has 2 SIP Peers

Each CUBE can only talk to its respective SIP peer via its local Level 3 Transport to reduce call control latency by not allowing it to use the DMVPN backup network

Level 3 does not support SIP Options Ping

CUCM Trunks have SIP Options Ping enabled



Call Flows:



Working Flow:



Phone ----> SLRG ----> Route Group Member #1 ----> CUBE SIP TRUNK ----> CUBE ----> Level 3 Transport ----> Level 3 SIP Peer #1/#2 ----> Call Completes





CUBE Failure:



Phone ----> SLRG ---->

         Route Group Member #1 ----> CUBE SIP TRUNK --X--> CUBE (CUCM Cant Reach CUBE)



        CUCM Routes Call to Next Route Group Member



                              Route Group Member #2 ----> CUBE SIP TRUNK ----> CUBE ----> Level 3 Transport ----> Level 3 SIP Peer #1/#2 ----> Call Completes



Level 3 Transport Failure/SIP Server Failure:



Phone ----> SLRG ---->

         Route Group Member #1 ----> CUBE SIP TRUNK ----> CUBE --X--> Level 3 Transport (CUBE Cant Reach Level 3 SIP Server)



        CUCM Thinks Call Connects since the CUBE accepts the call, Phone gets dead air, never tries the next RG Member





My idea to fix this is to use an IPSLA to ping the pingable address on the Level 3 SIP Servers. If both address are unreachable then shutdown the CUCM Dial-Peers. This doesn’t sounds like the best way of fixing it, but it should work.



If any has any other better ideas please let me know.

--
Erik Anderson
Telecom Manager
Some Random Corp.


--
Erik Anderson
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip<https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7C%7Cd0b99f8e3a39490987a408d666d156bf%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636809446622332644&sdata=O6kTM2sSJbTLPWf8xQd%2B%2Fi2UBE0kFeopcYeG4xUtMgU%3D&reserved=0>
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip<https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7C%7Cd0b99f8e3a39490987a408d666d156bf%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636809446622488915&sdata=N%2BtP3lUiuu0aUuskasAPyc4CKIIkyM8%2FGTGI%2F%2BK2KOY%3D&reserved=0>
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip<https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7C%7Cd0b99f8e3a39490987a408d666d156bf%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636809446622488915&sdata=N%2BtP3lUiuu0aUuskasAPyc4CKIIkyM8%2FGTGI%2F%2BK2KOY%3D&reserved=0>
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7C%7Cd0b99f8e3a39490987a408d666d156bf%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636809446622488915&sdata=N%2BtP3lUiuu0aUuskasAPyc4CKIIkyM8%2FGTGI%2F%2BK2KOY%3D&reserved=0
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20181220/eca47f4d/attachment.html>