I'll also point out that 95% of the problems we get are DNS related (i may be exaggerating a little, but it certainly seems that this is the case).
We can educate until the cows come home but to make this system more reliable we need to have the servers control their own (DNS) destiny and make DNS easier to configure. I'm not nearly as concerned about the phones as I am the servers and the inter-server / inter-process communications. Also this is only going to get more complex. On small systems the DNS queries are not excessive, but on large systems they are. Do a tcp dump on a system and you will see... If we can speed this up and reduce load on the servers everything will work better. Mike On Thu, Jun 16, 2011 at 12:55 PM, Josh Patten <[email protected]> wrote: > I think the point of this post is being dodged. I'll break it down: the way > sipXecs services utilize DNS is wholly inefficient. While it may seem > trivial for small systems to have this many DNS queries this can become a > real problem with large installations regardless of a caching server. This > is not just a "make it log less" issue, this is a "quit making gobs of > unnecessary DNS queries" issue. > > Regarding future DNS implementations in future versions of sipXecs, the > idea is that with the ability to have tens of servers that remote branch > locations would have their own SIP proxy to handle local registrations and > SIP routing. There is currently no other way that I am aware of the force > traffic to stay local for these scenarios other than to use BIND views. > > > On Thu, Jun 16, 2011 at 9:01 AM, <[email protected]> wrote: > >> *Number of queries:* >> As Gerald says, install a caching name server, by default most Linuxes >> won't cache. >> (But to be honest, the DNS load is not high currently IMHO). >> >> *Logging:* >> The logging is happening too frequent and it should be able to "disable >> dns stuff" for services you don't use. >> I don't use TLS for example but my log file is full with >> "2011-06-16T02:04:06.845279Z":2776308:SIP:WARNING:first.epo.org:SipSrvLookupThread-22:B5EFCB90:SipXProxy:"DNS >> query for name '_sip._tls.third.epo.org', type = 33 (SRV): returned >> error" >> "2011-06-16T02:02:50.442031Z":2776125:SIP:WARNING:first.internal.epo.org:SipSrvLookupThread-22:B5EFCB90:SipXProxy:"DNS >> query for name '_sip._tls.second.internal.epo.org', type = 33 (SRV): >> returned error" >> Should these be added to sipx-dns, dns advisor and dns or are they not >> needed? >> >> These also either don't make sense or sipx-dns needs adjusting: >> "2011-06-16T02:02:48.196400Z":2776086:SIP:WARNING:first.internal.epo.org:SipSrvLookupThread-20:B60FEB90:SipXProxy:"DNS >> query for name '_sip._udp.rr.first.internal.epo.org', type = 33 (SRV): >> returned error" >> "2011-06-16T02:02:48.196443Z":2776087:SIP:WARNING:first.internal.epo.org:SipSrvLookupThread-23:B5DFBB90:SipXProxy:"DNS >> query for name 'rr.first.internal.epo.org', type = 1 (A): returned error" >> I have the correct _sip._tcp.rr records in place, according to sipx-dns >> thats all I need, but the log is complaining about a _sip._UDP.rr , but only >> for my first/main server. >> Also DNS advisor is not complaining about this record. >> >> And then there is also a >> "2011-06-16T02:02:50.428519Z":2776115:SIP:WARNING:first.internal.epo.org:SipSrvLookupThread-22:B5EFCB90:SipXProxy:"DNS >> query for name '_sip._tls.rr.other-domain.internal.epo.org', type = 33 >> (SRV): returned error" >> Where "other-domain" is another sipx cluster configured as unmanaged >> gateway. >> Why would something want to do TLS with an unmanaged gateway?......Figured >> it out...I left Transport protocol on Auto for this unmanaged gateway, not >> for the others I have. >> It says "Set to force the SIP transport protocol. If set to auto the >> transport is determined through a DNS query. " on the Gateway details in >> "Advanced settings". >> The "a DNS query" is more like "a lot of DNS queries", 124 in a good 12 >> hours top be exact, intervals between 1 and 8 minutes. >> And looking at my first logging problem, probably it's the same problem, >> only not cross-domain and not configurable, servers within one cluster will >> try to resolve TLS records >> and you can't disable this (or can you). >> >> *Linux DNS subsystem failover* >> OK, fast failover is good >> >> *Simplified DNS Management from Administration Web Interface* >> If sipX is DNS server then all could be "under the hood". >> For people that configure their own DNS maybe it is possible to create a >> sipx-dns function in the GUI that based on the configured servers and >> services creates the right output of all needed DNS records (but DNS advisor >> sort of does that already). >> Views however are not everybody's cup of tea, I don't know whether that >> should become mandatory. >> >> My DNS advisor is complaining a lot about my third XMPP only server. >> According to sipx-dns run like >> sipx-dns domain.internal.epo.org first.internal.epo.org/10.x.x.1 >> second.internal.epo.org/10.x.x.2 -x domain.internal.epo.org/10.x.x.3 >> I don't need >> _sip._udp.domain.internal.epo.org. pointing to third server >> _sip._tcp.domain.internal.epo.org. pointing to third server >> _sip._tcp.rr.first.internal.epo.org. pointing to third server >> _sip._tcp.rr.second.internal.epo.org. pointing to third server >> _sip._tcp.rr.third.internal.epo.org. pointing to third server >> >> According to DNS advisor I do need them, but I am running happily without >> them. >> >> Now it's weekend for me because I have to prepare our polder day coming >> saturday: >> * >> http://www.schieveensepolder.eu/joomla/index.php/activiteiten/midden-delfland-dag-2011 >> *<http://www.schieveensepolder.eu/joomla/index.php/activiteiten/midden-delfland-dag-2011> >> >> >> Josh Patten <[email protected]> wrote on 16-06-2011 15:56:29: >> >> >> > I'm not just talking about logging...I'm talking about fixing the >> > reason why the services are logging DNS items that frequently in the >> > first place regardless of where the DNS server is located. TTL >> > values should be followed. The most efficient way to do this in my >> > opinion is for the service to query DNS at startup and then only >> > perform another query when another sipXecs service is restarted or >> > when the TTL is about to expire. >> > >> > On Thu, Jun 16, 2011 at 1:43 PM, Gerald Drouillard >> > <[email protected]> wrote: >> > > On 6/16/2011 1:20 AM, Josh Patten wrote: >> > >> DNS as a primary method for facilitating communication between >> > >> endpoints, sipXecs servers, and gateways has proven to be an >> excellent >> > >> method of enabling load balancing and, to a lesser extent, redundancy >> > >> of sipXecs services. >> > >> >> > >> As it is currently implemented in sipXecs, DNS is the root cause of >> > >> many outages and issues. This is because DNS configuration for proper >> > >> sipXecs operation is complex for most network >> engineers/administrators >> > >> and is very difficult for most telecom engineers to understand. This >> > >> will only become more complex as future versions of sipXecs will add >> > >> the capability for many more servers to be added to each sipXecs >> > >> cluster, each possibly being deployed at a remote site to be used for >> > >> survivability or load balancing. It has also been observed that >> > >> individual sipXecs processes are making unnecessarily large amounts >> of >> > >> DNS queries which can result in network congestion and extra load on >> > >> the sipXecs cluster. >> > > I agree about the excessive log writing. Maybe one could get that >> info >> > > in debug mode. To reduce traffic then install a caching name server >> on >> > > the sipx machine. >> > > >> > -- >> > Josh Patten >> > eZuce >> > Solutions Architect >> > O.978-296-1005 X2050 >> > M.979-574-5699_______________________________________________ >> >> > sipx-dev mailing list >> > [email protected] >> > List Archive: >> http://list.sipfoundry.org/archive/sipx-dev/ >> _______________________________________________ >> sipx-dev mailing list >> [email protected] >> List Archive: http://list.sipfoundry.org/archive/sipx-dev/ >> > > > > -- > Josh Patten > eZuce > Solutions Architect > O.978-296-1005 X2050 > M.979-574-5699 > > _______________________________________________ > sipx-dev mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-dev/ > -- Michael Picher eZuce Director of Technical Services O.978-296-1005 X2015 M.207-956-0262 @mpicher <http://twitter.com/mpicher> www.ezuce.com
_______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev/
