cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1492
Views
1
Helpful
12
Replies

CUBE MultiVRF Limitations

j.a.m.e.s
Level 3
Level 3

Dear All,

 

I would like to use the new-ish CUBE multivrf feature (documented here). One of the limitations is:

Multi-VRF is not supported on TDM-SIP gateway

What is actually meant by this? If I wanted to run say an MGCP controlled NIM-4FXS on the same router as the CUBE, could it be done?

 

Many thanks

James.

 

1 Accepted Solution

Accepted Solutions

You are implementing Multi-VRF on the CUBE. So the SIP to SIP call flow limitation is from the perspective of the CUBE. The highlighted call flow should be supported.

View solution in original post

12 Replies 12

R0g22
Cisco Employee
Cisco Employee
Multi-VRF is for a CUBE setup primarily SIP to SIP call flows only.

Thank you Nipun, but my question really is about whether it's possible to combine CUBE with Multi-VRF and still host an analog card on the same router. The business case is to supply a single fax line at the site without purchasing an additional device.

 

Regards

 

James

Like i said multi-vrf is only for a sip to sip call flow and not IP to POTS or vice-versa.
Further, MGCP process on the IOS is not vrf aware. You cannot source MGCP traffic from/to an interface belonging to vrf. MGCP will always use global routing table.


Thanks Nipun. So, if I want to run CUBE with MultiVRF and then have a separate loopback (in the default vrf) which is binded to MGCP and controlling an analog card, that would be a supported setup?

 

Sorry to keep pressing this question, but i basically want to clarify what Cisco mean by "not supported on TDM-SIP gateway".

Is there a reason for using mgcp ? Do you have vrf’s configured already ? what is the purpose of having vrf’s in your network ?

> what is the purpose of having vrf’s in your network ?

To keep the routing tables of various ITSPs segregated. It's a security and manageability feature.

> Do you have vrf’s configured already ?

Yes

> Is there a reason for using mgcp ?

I think we're going round in circles here..Let me rephrase the question. "With CUBE MultiVRF configured, can I add an analog card into the CUBE and make this card MCGP controlled?"

 

Check my initial post. I will answer it again -
1. Multi-VRF is only supported on SIP to SIP call flows.
2. MGCP is not VRF aware. Traffic is sourced via global routing table.
3. Taking your scenario of using a loopback (non-vrf), your MGCP registration will work fine but traffic going out to your ITSP will be through a VRF since you are already using it like you said. This will be a POTS to IP scenario again. Multi-VRF is not supported.
4. You did not answer my question of why the need for MGCP. You can just plug the fax machine on the FXS ports and route the calls directly to your ITSP. This will again be a non SIP to SIP call flow. No support for multi VRF.

All of this was already answered. None of your call flows are SIP to SIP. Hence no support for multi-VRF.

As a workaround, use a ATA on the CUCM to host your faxes. Won't cost much and won't require un-necessarily complicating your production CUBE.

Hope that answers your question.

Thanks Nipun, but I'm still not quite 100% clear on what's meant by:

 

1. Multi-VRF is only supported on SIP to SIP call flows.

Let's say we have:

Fax -> VG224 -> MGCP -> CUCM -> SIP -> CUBE_MULTIVRF -> SIP Itsp

This is not a SIP call end-to-end, but is it is SIP on either side of the CUBE itself. Is this supported?

 

Regards

James.

You are implementing Multi-VRF on the CUBE. So the SIP to SIP call flow limitation is from the perspective of the CUBE. The highlighted call flow should be supported.

j.a.m.e.s
Level 3
Level 3

This is an old post, but I can see that in IOS-XE 17.6+ the limitation ("Multi-VRF is not supported on TDM-SIP") has gone.

Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards, then look at Restrictions.

 

 

 

j.a.m.e.s
Level 3
Level 3

Just a quick shout out to anyone implementing CUBE MultiVRF and using IOS-XE v17.x (that should be most people at the time of writing), there is a bug which prevents calls matching the incoming dial-peer if a SIP message (e.g. Options Ping) arrives during router bootup:

https://bst.cisco.com/bugsearch/bug/CSCwj06857

Luckily, this can easily be worked-around by binding the control and media interface under 'voice service voip' and you can still override at the dial-peer level to achieve MultiVRF separation.

i.e. If you are running MultiVRF and IOS-XE v17.x. make sure this is configured:

voice service voip
sip bind control source-interface x
bind media source-interface x
exit

 

Great information. However per the bug note a better, or at least more specific, workaround is to use tenant configuration bindings for different types of dial peers, for example to CM or ITSP.



Response Signature