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.
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:
Dial-Peers
- 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.
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.
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":
! 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
- 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
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.
ConclusionDon'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
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!
Great post!!! Thanks!!!
ReplyDeleteI like the higher level organization of your dial peers.
ReplyDelete7xxxx CUBE (SIP dial-peers?)
8xxxx CallManager (voip dial-peers)
9xxxx PSTN (pots dial-peers)
2 things I've encountered that I don't see here is:
1) dial peers for redundant/alternate gateways. They're usually voip so I would put in the 8xxxx section.
2) internal PRI trunks. They're pots so I would put in the 9xxxx section. I might want to use similar number, similar 2nd digit, to redundant/alternate VGs. In my mind, they are a similar functions.
And I really like a 5 digit base for all dial-peers. I love how it works with the section command. Same for 'show dial-peer voice summary | inc'.
Overall a flexible & easily understood organization of the dial-peers. I'm going to add to my standards.
Great post, one suggestion for the voice translation profile names. When I did my CCIE sometime ago I used the a tag to know if the profile should be used in the outgoing or incoming direction. In that way it was very easy to remember and also verify that the profile was tied to voice ports, dial peers... in the right direction.
ReplyDeleteFor example I might name a profile used for outgoing translation of called number to 911 like this, OUT-DNIS-911.
Roger,
DeleteGood info. Thanks for contributing. I use named profiles in production for sure. I follow a convention similar to your suggestion. For my lab prep I moved to a "numeric" tag for the profiles primarily for speed.
I think that the important thing for anyone reading this blog and our comment thread is that you have to pick something that works for you and can be consistently applied to various situations. I think your method fits the bill!
Thanks again!
-Bill (@ucguerrilla)
Great Post Buddy!
ReplyDelete- Tommer
Hey Tommer,
DeleteThanks for the feedback. How have you been?
-Bill