A useful command that displays your Windows network stacks calculated Path MTU, Estimated Path Speed and RTT time for your recent IP or IPv6 destinations!

I recently stumbled across this useful windows command to show what MTU value windows will try and use for your IP connections based on the source, next hop and destination address.

 netsh interface ipv4 show destinationcache

Interface 10: Ethernet

PMTU Destination Address                           Next Hop Address

---- --------------------------------------------- -------------------------

1500 4.153.29.52                                   192.168.1.1

1500 13.91.148.88                                  192.168.1.1

You can even add the level=verbose option to display Windows estimated path speed as well as the RTT Mean (average) and RTT Deviation (also known as jitter.)

In this example, I am also passing the address parameter so you can see the syntax if you want to drill down to a specific destination, the level=verbose param works fine with or without a destination specified :)

netsh interface ipv4 show destinationcache address=74.214.24.53 level=verbose

Destination              : 74.214.24.53

Next Hop Address         : 192.168.1.1

Source                   : 192.168.1.11

Interface                : Ethernet

Path MTU                 : 1500

Upper-layer MTU          : 1480

RTT mean                 : 16

RTT deviation            : 6

Path transmit speed (Bps): 10337720

Path receive speed (Bps) : 28962424

Link transmit Speed (bps): 1000000000

Link receive Speed (bps) : 1000000000

Flags                    : 0x0

To get the same info for IPv6, just replace ipv4 with ipv6 in your netsh command.

The important of two vBond Controllers

 Hi Guys

Just a quick note: if you only have one vBond controller, you are never going to be able to discover what kind of NAT you are behind, so don't get into the habit of using IP addresses in your system->vbond commands as this will mean that you're not going to be able to determine the NAT type.

If you do use a static "ip host" command, make sure you specify TWO addresses:

ip host vbond-9991397001.sdwan.cisco.com 1.9.151.47 27.155.41.205

use the "show sdwan control local-properties" to find your nat type:

 NAT TYPE: E -- indicates End-point independent mapping

           A -- indicates Address-port dependent mapping

           N -- indicates Not learned

           Note: Requires minimum two vbonds to learn the NAT type

session target loopback:rtp

Hi Everyone!

I came across a feature for Cisco CUBE called loopback RTP. 

It's a great way to test your CUBE SIP configuration by creating a dial-peer that, when matched, will provide a "Test call echo" type feature that simply echo's your voice. Very similar to a skype test call.

Here's a quick example of the configuration:

dial-peer voice 1000 voip

 session protocol sipv2

 destination-pattern 1000

 session target loopback:rtp

!

The feature can be configured on IOS 15 and above.

Check out the description of the feature and link below for additional info, including how to utilize it for testing incoming video calls too :)

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube_proto/configuration/15-mt/cube-proto-15-mt-book/voi-rtp-media.html

"RTP packets are looped back toward the source device when the RTP Media Loopback for SIP Calls feature is configured on a dial peer. The SIP RTP media loopback can be used during Cisco UBE deployments to make test calls to verify the media path between the endpoints and Cisco UBE. In a voice loopback call, an echo is heard at the device originating the call. In a video loopback call, the locally captured video and the audio echo must be rendered at the source device."

(Oh, and apologies for the lack of blog posts, You should see a lot more from me this year, with a lot of posts on SD-WAN coming up!)

The growing importance of DNS in your CUCM configs

Hi Guys!

It used to be that DNS was an afterthought for most CUCM deployments, many engineers advocated at one point or another just using an IP address rather than dealing with the system team who could either be extremely cooperative or extremely slow.

Those days are GONE, my friends. 

Every bit of UC software you use should be properly configured with DNS.

 Infact, anywhere you CAN use DNS, you should be using it.

The main driver for this is definitely Jabber, I can't count the number of things that can go wrong with Jabber if you do not have your DNS configured correctly.

If you absolutely must get a system up very rapidly and the sysadmin team have been very slow to get there side finished, you can use a router as a temporary DNS server:

The config for this is shown below:

conf t
 ip domain-name
ip  dns server
ip name-server 8.8.8.8 4.4.2.2

ip host _cisco-uds._tcp.ccierants.com srv 0 10 8443 cucm01.ccierants.com
ip host cucm01 192.168.1.10
ip host unity 192.168.1.20
ip host imp 192.168.1.30
ip host _cuplogin._tcp.ccierants.com srv 0 10 8443 imp.ccierants.com


As you can see from the example above, you can use the host command to specify manual DNS entries, you can even do SRV records etc, the only records i can't seem to see are CNAME records, but for our purposes this does not matter.

You can then point your UC servers to this router as there DNS server as a temporary workaround while you wait for the system administration team.

How to tell what dial-peers are being matched on an ALREADY ACTIVE call

Hey Guys!

Working out what dial-peers got matched after a call has already begun sometimes seems like a bit of a mystery. For me at least I could never quite work it out. I ran across this command and thought I would share:

maui-gwy-06#show call active voice brief

!--- This information was captured once the call was placed and active.
!---
!--- 
!--- Notice that in this case, default VoIP(keyword IP) dial-peer 0 was 
!--- matched inbound.
 
Total call-legs: 2
87   : 257583579hs.1 +105 pid:0 Answer  active

In the example above, Dial-peer:0 was matched for the incoming since it showed Originate,  answer will show for incoming

Here's an example of a complete call:

0    : 1008757 10:18:47.997 CST Fri Aug 14 2015.1 +2630 pid:9999 Originate 15552226550 connected
 dur 00:17:21 tx:52067/8327756 rx:52050/8328000
 IP 216.200.200.XXX:19296 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms g711ulaw TextRelay: off
 media inactive detected:n media contrl rcvd:n/a timestamp:n/a
 long duration call detected:n long duration call duration:n/a timestamp:n/a

0    : 1008795 10:30:13.867 CST Fri Aug 14 2015.1 +11460 pid:99 Answer 5555921332 active
 dur 00:05:46 tx:17311/2769760 rx:17313/2770080
 IP 192.168.122.149:28152 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms g711ulaw TextRelay: off
 media inactive detected:n media contrl rcvd:n/a timestamp:n/a
 long duration call detected:n long duration call duration:n/a timestamp:n/a
 

The important sections are in bold, pid:XXXX (where XXX is the dial-peer) the keyword answer or originate (depending on
if this is the incoming dial-peer or outbound dialpeeer) and then the number that has been rung.

I hope this helps!

More Info Here:
http://www.cisco.com/c/en/us/support/docs/voice/call-routing-dial-plans/14074-in-dial-peer-match.html