sort list and view
AMANI M. BIN SUWAIF
amani at ies.etisalat.ae
Wed Jul 20 05:15:05 UTC 2011
Hi,
The problem is that fail-over between A records is not standard and
might/might not work with various SIP clients. On the other hand SRV in
my opinion has been designed with that in mind, that's why the
additional complexity with 2 SRV records.
Thanks & Regards,
*Amani*
On 7/20/2011 2:50 AM, Kevin Darcy wrote:
> On 7/18/2011 11:42 PM, AMANI MOHAMED BIN SUWAIF wrote:
>> Hi,
>>
>> I have the below scenario
>>
>> _TCP.EXAMPLE.COM IN SRV 10 0 5060 primary-sbg.example.com
>> _TCP.EXAMPLE.COM IN SRV 20 0 5060
>> secondary-sbg.example.com
>>
>> I have 2 IP ranges and 2 SBGs host, my intention is
>>
>> for client in IP range1
>> primary-sbg IN A 1.1.1.1
>> secondary-sbg IN A 2.2.2.2
>>
>> for client in IP range2
>> primary-sbg IN A 2.2.2.2
>> secondary-sbg IN A 1.1.1.1
>>
>> can this be achieved without using a views?
>>
>> I thought this can be solved just by a sortlist, where
>> primary-sbg IN A 1.1.1.1
>> primary-sbg IN A 2.2.2.2
>> secondary-sbg IN A 2.2.2.2
>> secondary-sbg IN A 1.1.1.1
>>
>> and then introduce the sortlist, which sorts the position of IP
>> addresses based on the IP range client comes from?
>> something like,
>>
>> sortlist {
>> {
>> IPRANGE1; // 1st client IP selection matches any of these
>> {1.1.1.1; // return any of these response IPs as 1st preference
>> };
>> {
>> IPRANGE2; // 1st client IP selection matches any of these
>> {2.2.2.2; // return any of these response IPs as 1st preference
>> };
>> };
>>
>> but in this case,
>> client from IPRANGE1 receive 1.1.1.1 as a first choice for both
>> primary-sbg and secondary-sbg
>> and
>> client from IPRANGE2 receive 2.2.2.2 as a first choice for both
>> primary-sbg and secondary-sbg
>> which is not the intention. sortlist doesn't not consider domain name.
>> The intention is to have primary SBG for first iprange act as a
>> secondary SBG for the second ip range and vice verse and in similar
>> manner for multiple IP ranges and SBGs. Problem with views is that
>> anytime this setup gets bigger and we will have additional ip ranges
>> and additional SBGs, it will require additional views...
>>
>> (LOC)RANGE PRIMARY(LOC) SECONDARY(LOC)
>> (L1)IPRANGE1 SBG1(L1) SBG6(L2)
>> (L1)IPRANGE2 SBG2(L1) SBG7(L2)
>> (L1)IPRANGE3 SBG3(L1) SBG8(L2)
>> (L1)IPRANGE4 SBG4(L1) SBG9(L2)
>> (L1)IPRANGE5 SBG5(L1) SBG10(L2)
>>
>> (L2)IPRANGE6 SBG6(L2) SBG1(L1)
>> (L2)IPRANGE7 SBG7(L2) SBG2(L1)
>> (L2)IPRANGE8 SBG8(L2) SBG3(L1)
>> (L2)IPRANGE9 SBG9(L2) SBG4(L1)
>> (L2)IPRANGE10 SBG10(L2) SBG5(L1)
>>
>> half of the SBGs is in one location (L1) and half in other (L2),
>> that's why it is important that for clients from ranges in one
>> location, first half of SBGs is preferred, and for other clients from
>> second location other half of SBGs is preferred. Client configuration
>> should be uniformed (same SRV) regardless the location.
> Are you over-engineering this? If the A-record failover by your client
> is fast enough you might only need 1 SRV record, and then sortlisting
> will work fine (subject to the usual caveats: as long as you can
> control the sortlist config of every resolver your clients will use,
> and keep them in sync).
>
>
>
> - Kevin
>
>
> _______________________________________________
> Please visithttps://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20110720/10d01463/attachment.html>
More information about the bind-users
mailing list