MitelInMyBlood
Technical User
I'm trying to figure out if something is misconfigured between my Unity Connection (voice mail) pub & sub.
The pub is local (in house) and the sub is remote (offsite). the connection between sites is a leased gig circuit with a DS3 (45 Mbps) backup. There is normally a lot of traffic going across the the path, but never before a problem.
Yesterday we lost the GIG pipe for several hours & the network traffic failed over to a backup DS3, swamping it. Latency, which is normally 4 or 5 ms was suddenly 2300~2500 ms. I understand this.
During the time the gig path was down we began getting complaints of delayed MWI and delayed message delivery.
The gig path was restored sometime overnight, but when I came in this morning there was no MWI working & no messages being delivered, although CUCX was answering correctly.
Both PUB and SUB were able to ping each other (from the OS maint window) but the PUB was stuck in Split Brain Recovery state and couldn't see the sub. The SUB was answering calls but MTA and Notifier services were stopped on both pub & sub. Neither pub nor sub could "see" each other.
TAC had us restart the PUB from the CLI, which eventually resolved the problem.
My question is why did we experience problems locally? Why did losing the primary path to the CUCX sub (remote site) cause an initial slowdown of MTA and Notifier services on the local pub? The why, after the network was restored did MTA and Notifier services stop altogether, requiring manual intervention? With this experience behind us it would appear our voice mail is not as redundant as our VAR led us to believe.
Comments & thoughts on this appreciated.
Thanks!!
Original MUG/NAMU Charter Member
The pub is local (in house) and the sub is remote (offsite). the connection between sites is a leased gig circuit with a DS3 (45 Mbps) backup. There is normally a lot of traffic going across the the path, but never before a problem.
Yesterday we lost the GIG pipe for several hours & the network traffic failed over to a backup DS3, swamping it. Latency, which is normally 4 or 5 ms was suddenly 2300~2500 ms. I understand this.
During the time the gig path was down we began getting complaints of delayed MWI and delayed message delivery.
The gig path was restored sometime overnight, but when I came in this morning there was no MWI working & no messages being delivered, although CUCX was answering correctly.
Both PUB and SUB were able to ping each other (from the OS maint window) but the PUB was stuck in Split Brain Recovery state and couldn't see the sub. The SUB was answering calls but MTA and Notifier services were stopped on both pub & sub. Neither pub nor sub could "see" each other.
TAC had us restart the PUB from the CLI, which eventually resolved the problem.
My question is why did we experience problems locally? Why did losing the primary path to the CUCX sub (remote site) cause an initial slowdown of MTA and Notifier services on the local pub? The why, after the network was restored did MTA and Notifier services stop altogether, requiring manual intervention? With this experience behind us it would appear our voice mail is not as redundant as our VAR led us to believe.
Comments & thoughts on this appreciated.
Thanks!!
Original MUG/NAMU Charter Member
Obviously the redundant path needs to be the same speed as the primary, i.e., gig, which coincidentally we just got the 2nd gig path added today, but now the IT folks look upon that 2nd gig path as more bandwidth and so want to flood both paths with cubic volumes of constant ongoing backup traffic to offsite storage. Seems bandwidth begets abuse thereof, which begets more bandwidth followed by even more abuse.