[VoiceOps] Acme SBC geographic redundancy

[Jason L. Nesheim]

If you're going to use SRV records in an Access deployment with registration caching on the Acme SBC one thing to keep in mind is that non-HA SBCs (or two separate pairs) will not share their registration and NAT databases. 




-- 
Jason Nesheim 




----- Original Message ----- 
From: "Brad Anouar" <Brad at broadcore.com> 
To: voiceops at voiceops.org 
Sent: Thursday, September 3, 2009 4:25:10 PM 
Subject: Re: [VoiceOps] Acme SBC geographic redundancy 


I agree with Alex, SRV records could be a more realistic solution for the access side given that you are willing to accept some post dial delay in failover mode. If you plan on using ACME for peering, since most providers don't support SRV records, you will have to provide them with multiple IPs and the order in which you would like them to be used. 



Brad Anouar 
Director - Systems Engineering 
P: 310-360-2028 
F: 310-360-2029 
brad at broadcore.com 



-----Original Message----- 
From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Alex Balashov 
Sent: Thursday, September 03, 2009 4:03 PM 
To: Brandon Buckner 
Cc: voiceops at voiceops.org 
Subject: Re: [VoiceOps] Acme SBC geographic redundancy 

As with any HA setup of IP nodes, the main problems boil down to: 

1. Adequate network bandwidth and network availability between the 
primary and standby unit (or silo) for reliable and sufficiently 
low-latency synchronisation of various information (config changes, 
standby status, any call state information shared among them in Acme's 
HA setup, etc.); 

2. The more common way to make them effectively redundant from a user 
perspective is to have them share an IP address, in which case it is 
necessary to ensure that the traffic destined for that IP network can 
pass into the other POP in the event of a failure, which requires 
complicated integration with your BGP and/or IP connectivity 
arrangements and any interior routing protocols you may be running. 

A more realistic approach is to have all the clients use an SRV record - 
if all your clients are capable of SRV lookups - and specify the 
secondary with lower priority, avoiding the complexities of IP sharing 
across disparate geographic sites altogether. 

-- Alex 

Brandon Buckner wrote: 

> Is anyone doing geographic redundancy with their Acme Packet SBCs? We've 
> got an HA pair of nn4250s right now and are installing a new Metaswitch 
> system that is geographically redundant at two locations with external 
> call agents, TDM links, etc. We'd like to get SIP to be the same. I'm 
> still waiting on a response from our Acme SE about it but wanted to see 
> what others had done, if anything. I figure some discussion will spark 
> questions I can bring up with Acme as well. 


-- 
Alex Balashov - Principal 
Evariste Systems 
Web : http://www.evaristesys.com/ 
Tel : (+1) (678) 954-0670 
Direct : (+1) (678) 954-0671 
_______________________________________________ 
VoiceOps mailing list 
VoiceOps at voiceops.org 
https://puck.nether.net/mailman/listinfo/voiceops 
_______________________________________________ 
VoiceOps mailing list 
VoiceOps at voiceops.org 
https://puck.nether.net/mailman/listinfo/voiceops 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20090906/7874e917/attachment.html>