Good morning Ed,

Just thought I’d toss this out there to be aware of; 
CsCuy96398<https://bst.cloudapps.cisco.com/bugsearch/bug/CSCuy96398?referring_site=cisco_cli_analyzer>
 (DNS query delay). While your 16.3.5 version is not listed as a known affected 
release, its also not specifically listed as a known fixed release. The good 
news is that 16.3.1 is listed as a known fixed release, so your 16.3.5 likely 
has the fix baked in (but who really knows when it comes to IOS bugs). I’d just 
keep it in the back of your mind if you have to tshoot 😊.

Here is the bug condition:

Upon start-up/reboot the DNS process doesn't initiate a query till around 18 
minutes after the boot up. This long delay results in hostname configured 
features (ex:NTP servers) not being used till this process is complete. Even 
when doing this time the DNS server is reachable.

Thanks,

Ryan
From: Ed Leatherman<mailto:ealeather...@gmail.com>
Sent: Tuesday, March 6, 2018 7:31 AM
To: Anthony Holloway<mailto:avholloway+cisco-v...@gmail.com>
Cc: Cisco VOIP<mailto:cisco-voip@puck.nether.net>
Subject: Re: [cisco-voip] session target dns

Thanks Anthony, That was spot on what I was trying to figure out. I've been 
using server-groups up until now (and will continue on the CUCM facing side), 
the service provider is forcing the change on the side facing them.

Loren: That's an interesting idea to lock in the host resolution on the CUBE 
itself, but in this case I think it might set me up for an outage if the 
service provider changes their IP Addressing. Maybe I can get them to commit to 
telling me before they change those..

On Mon, Mar 5, 2018 at 2:31 PM, Anthony Holloway 
<avholloway+cisco-v...@gmail.com<mailto:avholloway+cisco-v...@gmail.com>> wrote:
Loren,

Just out of curiosity, why didn't you just use session server groups?  Based on 
the config you shared, it looks like it would achieve the same thing, but with 
less config, and not adding in the DNS stack within IOS.

Ed,

*Note, you cannot use DNS in server groups, so it's one or the other.

I also think it's important to know that the IOS code is written such that it 
will look for SRV records first, and then fallback to looking for an A (host) 
record once the DNS timeouts.

E.g.,

You enter "session target dns:collab.domain.com<http://collab.domain.com>"

IOS looks for _sip._udp.collab.domain.com<http://udp.collab.domain.com> SRV 
record first, timesout, then looks for 
collab.domain.com<http://collab.domain.com> host record second.

*Note that the outgoing session transport on IOS is UDP by default, unless you 
change it to TCP with the command "session transport tcp" at the "voice service 
voip" level, or at the dial-peer level.  So, having a _sip._tcp SRV record on 
your CUBE would create a confusing scenario.  Contrast this with the incoming 
connection, which can be either.  However, SRV records, like Loren is showing, 
are for outbound connection establishments.

I have not done an extensive amount of testing here, but I would be curious to 
know if IOS handles the TTL for the DNS record correctly, or if it queries DNS 
for every setup like how that one defect was hitting CUCM SIP trunks for a 
while there.  I looked for "TTL" in the CVP Config guide, but it didn't say.

On Mon, Mar 5, 2018 at 11:19 AM Loren Hillukka 
<lchillu...@hotmail.com<mailto:lchillu...@hotmail.com>> wrote:
You can have your gw query your DNS server, and you have to add SRV records to 
your central DNS server (like with the jabber entries required to get jabber 
sign-in to work).
Here’s the example of doing local DNS to static entries on the gateway itself, 
from the CVP 10 config guide.  CVP is where I first started doing dns srv on 
the local gateway, as I preferred breaking the call center myself instead of 
having the AD/DNS teams do it for me without me knowing ;-)
===========
You can also configure the Gateway statically instead of using DNS. The 
following example shows how both the A and SRV type records could be configured:
ip host cvp4cc2.cisco.com<http://cvp4cc2.cisco.com/> 10.4.33.132
ip host cvp4cc3.cisco.com<http://cvp4cc3.cisco.com/> 10.4.33.133
ip host cvp4cc1.cisco.com<http://cvp4cc1.cisco.com/> 10.4.33.131
For SIP/TCP:
ip host _sip._tcp.cvp.cisco.com<http://tcp.cvp.cisco.com/> srv 50 50 
5060<tel:50%2050%205060>cvp4cc3.cisco.com<http://cvp4cc3.cisco.com/>
ip host _sip._tcp.cvp.cisco.com<http://tcp.cvp.cisco.com/> srv 50 50 
5060<tel:50%2050%205060>cvp4cc2.cisco.com<http://cvp4cc2.cisco.com/>
ip host _sip._tcp.cvp.cisco.com<http://tcp.cvp.cisco.com/> srv 50 50 
5060<tel:50%2050%205060>cvp4cc1.cisco.com<http://cvp4cc1.cisco.com/>
For SIP/UDP:
ip host _sip._udp.cvp.cisco.com<http://udp.cvp.cisco.com/> srv 50 50 
5060<tel:50%2050%205060>cvp4cc3.cisco.com<http://cvp4cc3.cisco.com/>
ip host _sip._udp.cvp.cisco.com<http://udp.cvp.cisco.com/> srv 50 50 
5060<tel:50%2050%205060>cvp4cc2.cisco.com<http://cvp4cc2.cisco.com/>
ip host _sip._udp.cvp.cisco.com<http://udp.cvp.cisco.com/> srv 50 50 
5060<tel:50%2050%205060>cvp4cc1.cisco.com<http://cvp4cc1.cisco.com/>
 ============
Then your dial-peer would have session target 
dns:cvp.cisco.com<http://cvp.cisco.com/> which would point to the SRV record, 
which would use the weight/priority values to choose the final host, and 
resolve the selected host to an IP using the normal "ip host name x.x.x.x" entry


Loren

On Mar 5, 2018, at 10:15 AM, Ed Leatherman 
<ealeather...@gmail.com<mailto:ealeather...@gmail.com>> wrote:
Hi everyone,

Hopefully a quick question - in a dial-peer on CUBE (16.3.5) how does session 
target dns: resolve to an IP? I've never used DNS as target before for this.

Does CUBE just do a query for the A record by default, or does it do a SRV 
query by default? I have a SIP provider that wants to start using SRV for their 
SBC(s) and I'm researching how to setup my end in IOS. If it doesn't query SRV 
default, where do I toggle that behavior?

The command reference just says  "Configures the host device housing the domain 
name system (DNS) server that resolves the name of the dial peer to receive 
calls."

I've found the knob to tell it what SRV format to use in the sip-ua section.

Thanks!



--
Ed Leatherman
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip



--
Ed Leatherman

_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Reply via email to