The implementation of redundancy in any technology is of paramount importance, whether you’re studying to achieve a CCIE certification or designing a network for a client. So it goes without saying that this is a concept with which you should become intimately familiar.
In this blog, we’ll turn our focus specifically to redundancy in IOS dial-peers. Of course, dial-peers come in two different flavors: POTS and VoIP. POTS dial-peers deal exclusively with PSTN connectivity while VoIP dial-peers can be used for several purposes, as long as the communication takes place over IP.
Let’s take the example of a call routed inbound from the PSTN, destined toward the HQ CUCM cluster using the H.323 protocol. The configuration on the gateway appears as shown below.
As you can see, we are accepting calls inbound from the PSTN using dial-peer voice 1 pots and translating the incoming called number to a 4-digit DN. From there, we have two separate dial-peers with the ability to send the call to the HQ CUCM cluster. As you know, the dial-peer with the lowest preference (default 0) is chosen as the first routing option. If for some reason, that option is unavailable, the next possible dial-peer will be chosen to route the call. In this case, the HQ CUCM Subscriber server (10.10.13.12) is the first option while the HQ CUCM Publisher server (10.10.13.11) is second.
During this situation, let’s say that the targeted server listed in the primary dial-peer becomes inaccessible. We can simulate this in our network by creating an IP route to Null0, essentially dropping all traffic destined for this address in the “bit bucket”.
Since the Subscriber server is now inaccessible, inbound calls should be routed towards the Publisher server, right? Technically this is true, but by default, it will take a total of 15 seconds to do so. This is because the timer associated with establishing a TCP connection in the H.323 protocol suite defaults to this value. Furthermore, even if the user was willing to wait the required amount of time for the call to be processed, the ISDN PRI will prevent the wait time from exceeding 10 seconds due to the ISDN Call Proceeding (T310) timer. This means that in this configuration, the call will never be routed to the intended destination in the case where the primary dial-peer fails. See the below debug isdn q931 command output (abbreviated) for an ISDN timeout example.
Based on these facts, the best course of action here is to modify the H.323 timer in order to make the failover happen more quickly. Keep in mind that it must be less than 10 seconds to avoid conflict with the ISDN T310 timer. The modification will take place within a voice class specifically geared towards the H.323 protocol. The h225 timeout tcp establish command will be used to set the timer; in this case 1 second was chosen. Once the voice class is configured, it should be assigned to the dial-peers.
Once assigned, calls from the PSTN will now failover to the redundant dial-peer after 1 second. For confirmation, see the below debug isdn q931 command output (abbreviated).
Just as with H.323, SIP faces the same challenge with failover time. Let’s now take the same example, but replace the H.323 dial-peers with SIP dial-peers.
The settings that are associated with failover, in this case are the “Retry INVITE” parameter and the “TRYING” timer. The number of times that the INVITE message is re-sent is determined by the first parameter while the initial delay time is determined by the second setting. By default, the values are 6 and 500 ms, respectively. Furthermore, each time that an INVITE message is sent, the delay time (time before another re-INVITE) is doubled. This means that between the second and third re-INVITE, the delay will be 1 second rather than 500 ms. In total, if unchanged, the call will take 63.5 seconds to fail over, which is obviously unacceptable.
Default Timers (TRYING – 500 ms, INVITE – 6 retries)
- INVITE at time 00.000 Seconds – Total Time 00.000 (Original INVITE
- INVITE delay of 00.500 Seconds – Total Time 00.500 (1st Retry)
- INVITE delay of 01.000 Seconds – Total Time 01.500 (2nd Retry)
- INVITE delay of 02.000 Seconds – Total Time 03.500 (3rd Retry)
- INVITE delay of 04.000 Seconds – Total Time 07.500 (4th Retry)
- INVITE delay of 08.000 Seconds – Total Time 15.500 (5th Retry)
- INVITE delay of 16.000 Seconds – Total Time 31.500 (6th Retry)
- INVITE delay of 32.000 Seconds – Total Time 63.500 (Failover Occurs)
Now let’s modify the SIP settings to fail over before the ISDN T310 timer expires. Here the sip-ua on the router is configured with the retry invite parameter set to 2 and the timers trying parameter set to 150 ms.
After the configuration change, the timers should behave as outlined below.
Default Timers (TRYING – 150 ms, INVITE – 2 retries)
- INVITE at time 00.000 Seconds – Total Time 00.000 (Original INVITE)
- INVITE delay of 00.150 Seconds – Total Time 00.150 (1st Retry)
- INVITE delay of 00.300 Seconds – Total Time 00.450 (2nd Retry)
- INVITE delay of 00.600 Seconds – Total Time 01.050 (Failover Occurs)
Obviously, since we are referring to VoIP dial-peers, the timer and redundancy configuration for both H.323 and SIP applies to more than just inbound PSTN calls. It can also play a major role on any IP to IP gateway, such as CUBE.
I hope this blog was helpful to you in your CCIE Collaboration preparation! As always, give us a call and speak with a training advisor if you’re interested in purchasing our workbooks, attending a class, or have any questions regarding your preparation. Thanks again for reading and good luck in your preparation!
Learn More About Dial Peer Configurations
- iPexpert’s Cisco CCIE Collaboration Technology Workbook (Vol. 1)
- iPexpert’s Cisco CCIE Collaboration Lab Video on Demand
