Voice Gateway and Voice VRF – Caveats

Many networks leverage what is known as a VRF. These are used for traffic isolation and create separate routing instances within a router. It is important that vrf awareness is confirmed for any service (DHCP, Voice GW, etc) being locally provided for a given point in the network. One use case for such a configuration might be for voice isolation with or without MPLS. In the case that a router is providing voice gateway functionality (i.e. FXO/FXS to VOIP), the voice functions must understand the VRF construct in order to properly fulfill the role.

TL;DR–This configuration sometimes does not behave as expected and, in my experience, may require a reboot after following the documented procedure.

The configuration for VRF-Aware H.323 and SIP for Voice Gateways can be found at the URL below.


Notice that it makes reference to the fact that the services need to be restarted–

To configure a voice VRF, you must shut down voice services on the gateway, assign a previously defined VPN VRF to the VoIP SPI, and then restart voice services.

As one researches this particular configuration, the concept of voice “multi-vrf” will likely come up. Based on my research and understanding, this is a different configuration. Multi-vrf seems to be mutually exclusive to what the above link describes as VRF-Aware H323 and SIP. Multi-vrf is also limited to IP to IP VOIP communication (think SIP to SIP in the form of a CUBE).

I will also make the comment that the VRF aware H323 and SIP configuration seems to behave whether VRF’s are local only, extended using VRF-lite or networked using MPLS VPNv4. MPLS is only mentioned in the Cisco link I shared any many voice engineers aren’t very familiar with those concepts.

Some caveats I ran into as I configured this are as follows.

First, you can’t actually configure a voice vrf without individually disabling h323 and sip (see below). The configuration link correctly states that the service must be shut down.

//starting config without the voice vrf
BR_MPLS#show run | sec voice service voip
voice service voip
allow-connections h323 to h323
allow-connections h323 to sip
allow-connections sip to h323
allow-connections sip to sip
no supplementary-service sip handle-replaces
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none
no call service stop
call start slow
no call service stop

//shutdown voip
BR_MPLS(config)#voice service voip

//attempt voice vrf config
BR_MPLS(config)#voice vrf voip
% Cannot configure/unconfigure the CLI when VoIP services are running or when active VoIP calls are present

//verify it did NOT take
BR_MPLS#show run | inc voice vrf voice

//to get it to take, you have to stop h323 and sip manually/individually
BR_MPLS#conf t
Enter configuration commands, one per line. End with CNTL/Z.
BR_MPLS(config)#voice service voip
BR_MPLS(conf-serv-h323)#call service stop
BR_MPLS(conf-serv-sip)#call service stop

//now the voice vrf can be configured
BR_MPLS(config)#voice vrf voice
BR_MPLS(config)#do show run | inc voice vrf voice
voice vrf voice

//now you have to bring sip/h323 and voip service back up
BR_MPLS(config)#voice service voip
BR_MPLS(conf-serv-h323)#no call service stop
BR_MPLS(conf-serv-sip)#no call service stop
BR_MPLS(conf-voi-serv)#no shut

At this point and based on my experience and what I have seen, voip/RTP will only work in one direction.

  • VOIP Phone  -> PSTN  (functions as expected)
  • PSTN  -> VOIP Phone  (does not function properly)

It seems that the RTP is packaged up and associated with the global vrf. I verified this in my lab by building an MPLS VPNv4 WAN then adding routes to the destination of the dial peer (dial peers not explained in this article but this was a ‘typical’ configuration using an ipv4 session target) in the global table. I observed traffic that should’ve been in the VOICE VRF as untagged traffic egressing the WAN interface.

To my surprise, the fix was simple. I performed a wr mem and reload and everything functioned as expected.

Ultimately, I reproduced this multiple times and had similar results each time. Something happens at a very low level that seems to require the config to include the voice vrf during the startup process.


This is a configuration that doesn’t seem to have much recent documentation. It does seem to work as one would expect once the reboot has been performed. However, I would recommend testing and understanding the behavior in a lab or working with someone from Cisco to better understand the support-ability of the feature.


Disclaimer: This article includes the independent thoughts, opinions, commentary or technical detail of Paul Stewart. This may or may does not reflect the position of past, present or future employers.

About Paul Stewart, CCIE 26009 (Security)

Paul is a Network and Security Engineer, Trainer and Blogger who enjoys understanding how things really work. With over 15 years of experience in the technology industry, Paul has helped many organizations build, maintain and secure their networks and systems.
This entry was posted in How-To and tagged . Bookmark the permalink.

5 Responses to Voice Gateway and Voice VRF – Caveats

  1. Pingback: Segmenting Layer 3 Networks with VRFs - PacketU

  2. Alex says:

    Thanks for this. Saved me some running around on the interwebs

  3. Jim says:

    What are the key differences between this and multi-VRF? Which would one want to use if they possibly may have an IP conflict with a SIP provider?

Comments are closed.