Taming Dial-Peers for CCIE-V Lab

Accuracy and efficiency are two critical success criteria for the IE lab. I know that this is not a monumental revelation! On my own personal journey, I am starting to develop/adapt strategies for taking the test and tactics for streamlining execution. You need both. 

You need a strategy so that you don't get lost. There are several popular strategies, but you have to pick one (or create one) that works for you.


You also need to put together some tactics for executing specific tasks. This is different than having a strategy for taking the test. Think of the test-taking strategy as a "macro-level" thought process and the tactical execution of tasks as a "micro-level" process. They work together and can, if you aren't careful, work against each other. 

You can come up with strategies/tactics on your own or you can adapt these from your contemporaries that are on the same journey as you. I recommend that you explore the latter approach first. There are lots of good ideas out there. In fact, the topic of today's blog is to discuss having a convention for creating dial-peers, translation rules, and translation profiles. The approach provided is a combination of an idea I got from the ipExpert boot camp and my own method for building out dial-peers in production environments.

Convention

The objective is to have a convention that is easy to remember and one that can be applied to any of the lab voice gateways. Whether they be H.323, SIP, or some flavor of SRST.  Everyone will have their own convention and I have adapted mine from what I use for production builds. 

Dial-Peers

I use a 5-digit ID for dial-peers. You don't need to use 5-digits, I think of the "tag" as more of a fixed-field descriptor. Each digit means something. To illustrate:

• POTS dial-peers:
• 9101x : Emergency calls (911, 999, 9911, 0999, etc.)
• 9102x : Local calls
• 9103x : Reserved for local calls that may be a different digit length, for instance if you have a 7D and 10D local dialing solution. TBH, I haven't had reason to use this in my lab prep yet. I just kept it since I already have this model committed to memory.
• 9104x : Long distance or national calling
• 9105x : International calling
• VoIP dial-peers for TEHO: Basically, the same convention as the POTS dial-peers but I use a "8" instead of a "9" in the first digit-field. This comes into play if you have a CME deployment where the requirement is that you should use a VoIP trunk to CUCM for TEHO and you need a local POTS for high-availability.
• VoIP dial-peers for CUCM integration 
• 81990 : Primary CUCM node
• 81991 : Secondary CUCM node
• VoIP dial-peers for other integrations (CUE SIP, RAS for CME, Ingress/Egress for CUBE, etc.)
• 79xxx : CUBE dial-peers, where "xxx" is free-form. I tend to use 101, 102, 103, etc. 
• 7xxxx : CUE SIP, RAS to CME, and related dial-peers that may have a 4-digit extension. For example, if CUE has a pilot of 3600 then I would use 73600.

There is a method to my madness and while the above may appear to "overboard" at first glance, I hope the value is demonstrated as we walk through how I use this. The first relevant point of interest is that I use the same convention for dial-peer tags as I use for voice translation rules and translation profiles. 

At this point, let's explore an example and then come back to translation rules/profiles. The following provides an example of local and long distance POTS dialing solution for an H.323 gateway.

!
voice translation-rule 91020
 rule 1 /^2...$/ /\+1202555\0/ type any subscriber plan any isdn
 rule 2 /^3...$/ /\+1408555\0/ type any national plan any isdn
!
voice translation-rule 91021
 rule 1 // // type any subscriber plan any isdn
!
voice translation-profile 91020
 translate calling 91020
 translate called 91021
!
dial-peer voice 91020 pots
 destination-pattern 9[2-9]......
 translation-profile outgoing 91020
 port 0/1/0:23
 forward-digits 7
!
voice translation-rule 91040
 rule 1 /^2...$/ /\+1202555\0/ type any national plan any isdn
!
voice translation-rule 91041
 rule 1 // // type any national plan any isdn
!
voice translation-profile 91040
 translate calling 91040
 translate called 91041
!
dial-peer voice 91040 pots
 destination-pattern 91[2-9]..[2-9]......
 translation-profile outgoing 91040
 port 0/1/0:23
 forward-digits 10
!

Translation Rules/Profiles

In the example provided, it should be noted that the translation rule and translation profiles follow the same basic convention used for dial-peers. To state the convention "rules":

• For translation rules, the first 4-digits (e.g. 9101) line up to the dial-peer tag. The 5th digit identifies purpose:
• 91010 is the calling party translations
• 91011 is the called party translations
• For translation profiles, I always set the first 4-digits to line up with the dial-peer tag and use "0" for the fifth digit. I haven't had reason to go outside of that convention

Benefit

So, why follow this path? Again, the exact convention you use is yours and yours alone. However, the fact that you should have a convention that you can adapt to any question and execute quickly is, in my opinion, absolutely necessary. Some of the immediate benefits:

Don't Think...Do

The first benefit is that with a flexible convention you get to a point where slamming out the dial-peer config is almost a reflex. You don't want to have to think about it. It is like having a convention for your partition names in UCM.

Recycle, Recycle, Recycle

The second benefit is that you can re-use the configurations and that means an overall savings in terms of time spent. Let's say that in the example provided earlier, we were slapping that configuration on a H.323 gateway. Further assume that you have been asked to provide a SRST configuration for one of the other gateways. Since the conventions are basically the same, you can copy the configuration from one gateway into notepad. Do a search/replace for "port x/y/z:dd", calling party translations, etc. In most all cases, you will go down the config and tweak things like "destination-pattern".

Quick Verification

This goes to the fact that we have used the same conventions for dial-peer, translation rule, and translation profile tags. If I wanted to quickly check my configuration for POTS calls to emergency services, I can use the command: show run | s 9101 and if I wanted to see configurations for VoIP integration with CUCM cluster: show run | s 3199. See example below.

BR1-RTR#sh run | s 9101
voice translation-rule 91010
 rule 1 /^1...$/ /+1617863\0/
voice translation-rule 91011
voice translation-profile 91010
 translate calling 91010
 translate called 91011
dial-peer voice 91010 pots
 corlist outgoing local-pt
 translation-profile outgoing 91010
 destination-pattern 911
 port 0/1/0:23
 forward-digits 3
BR1-RTR#
BR1-RTR#
BR1-RTR#
BR1-RTR#sh run | s 3199
dial-peer voice 31990 voip
 destination-pattern 1...
 voice-class codec 1
 voice-class h323 1
 session target ipv4:10.3.120.11
 dtmf-relay h245-alphanumeric
 no vad
dial-peer voice 31991 voip
 preference 1
 destination-pattern 1...
 voice-class codec 1
 voice-class h323 1
 session target ipv4:10.3.120.10
 dtmf-relay h245-alphanumeric
 no vad

Conclusion

Basically, the conclusion is that you should have a method. We only talked about a method for configuring dial-peers and associate configs. Where feasible, you should develop an easy-to-remember, logical, and flexible convention for configuration tasks. It will help at game time when you want to be able to knock out most of your requirements without thinking too heavily.

---

Thanks for reading. If you have time, post a comment!