Forum Discussion
S4B Standard Edition deployement in a branch Site throught VPN Site-2-Site
I'm not sure, if VPNs goes down, SiteB's users goes in limited functionality.
For sure, replication and topolgy sync will be screwed, but IF in Site B I have all'MCUs, Mediation and PSTN BreakOut + optionally an Edge farm and a RProxy in Site B, the only thing that I loose will be (as already said) topo-sync, federation communications (and if I paired the 2 STD the DR Backup failures) ...isn't it ?
(note: obvious more complex config, more Cert SAN costs, more DNS names and configuration...but is part of the game IMHO)
Yep 100% they will go into limited functionality mode.
There can only be one active master CMS. I assume this to be on Site A's FE. You Pair them it doesn't become active active as far as the CMS is concerned.
The VPN goes down, I am assuming the users in Site A will still have use of SfB there where the CMS is.
You cannot force the CMS online in site B in this event and run a split brain model, When the link comes back up your CMS will be corrupted and everyone will go into limited functionality.
Regardless of all MCU services being there, if they cannot write to the active CMS after 20 mins users go into limited functionality and Skype protects itself from the point of no return.
You put an Edge in Site B, and the VPN goes down, you can only have 1 federation edge for signaling traffic. which assuming is Site A. media is negotiated via local edge to user but signaling will still go via the federation edge, so the session will never begin in this instance.
The only time that you can restore full service is to take Site A completely down. So youre sacraficing all users in site A to satisfy site B users when the link goes down.
If the link stays up but its Skype that fails in site A, then everything continues to work for both sites once you've performed failover.
Hi Mark,
First of all, thank you for your very sharp and contructive answer.
Indeed, my choice to deploy a server FE in the site B is based on some research I have on the internet and especially this article (http://ucken.blogspot.com/2012/10/lync-branch-site-options-and.html) pushed me to this choice there.
In addition I would like to have a complete environment so that soon I can create easly response groups in site B without changing the architecture of the servers.
In my case, Site B employees are completely dependent on Site A Servers (Exchanges servers and other production servers). So anyway if Site A falls, we can not do anything from Site B. (This is the case right now).
In the end, that's why I would like to have more visibility regarding SIP traffic separation.Sami,
Hi
Your issue is not SIP separation. It is down to the CMS Database.
I get what you are trying to do, my point is to note that if the S2S VPN failed and both Skype FE's where technically online then no matter what you are going to lose functionality in Site B. Users will go into Limited Functionality even though technically there is nothing wrong with their server.
As I said the reason for this is the CMS can only be active on one server, and this will more than likely be in Site A. As it's just the link between the two sites down Site A retains full functionality, but Site B will suffer if 20 minutes has past with no fix to the VPN. You wouldn't be able to have full mode in Site B. You couldn't "failover" Site B as you'd go into split brain and a whole world of pain!
But in a perfect world, if you localised SBCs, PSTN lines, Exchange etc in Site B for Site B users then when the link is up, you're going to achieve your BAU goal of reducing media over the S2S VPN. My point has always been if that link drops specifically then the hardware in Site B will be of limited use.
thanks
