[c-nsp] L3VPN Voice VRF

[Justin Shore]

I'm trying to figure out the best, safest, most secure and of course 
least expensive (in my time, hair, sleep at night, etc) way to implement 
a voice MPLS/VPN across our network.  I'm sure people on c-nsp have done 
it before so I'm hoping for a few pointers.

What we have today are a pair of MetaSwitches, one in each main POP.  In 
front of them at each POP are a pair of HA PIXs.  Customer RTP and 
signaling from our CATV MTAs, IP DSLAMs, FTTH, etc enter through the 
PIXs.  Communication between the 2 MetaSwitches and MS management 
servers is across an IPSec tunnel on the PIXs.

That works well enough but I need to do a few things to make it better. 
  First off the IPSec tunnel needs to go.  It's a real PITA because it 
randomly fails, forcing me to literally power cycle one of the sets of 
PIXs (taking down the remote POP's voice service entirely).  I can't 
clear anything crypto on these PIXs so I can't bring up the tunnel 
remotely.  I also can't see into the IPSec tunnel to identify traffic 
needing QoS preference or not.  My plan was to put the protected MS 
equipment along with the backside of the PIXs in a VRF which can span 
both POPs.  Traffic from the unprotected side to the protected side 
would hair-pin from the core routers through the PIXs back into the core 
router(s) at that site and into the VRF.  That's not too hard to do, 
it's just getting the time to plan and do it.

The second problem is that this does not allow for roving remote users 
with IP phones.  My ACLs on the MS PIXs are tight and I want to keep it 
that way.  We bought a pair of Ditech SBCs to address the roving user 
problem (horrible pieces of junk; I only recommend them to competitors). 
  They will straddle the unprotected and protected network boundary, 
just like the PIXs more or less.  That's not too hard either.  I only 
plan on pointing remote roving users at the SBCs; not VoIP users that 
are using fixed phones on our own SP network.

My current problem is that we're entering into the realm of managed 
voice service.  We're CLECing a remote city and offering managed VoIP 
with SIP for businesses over DS1s and LRE (G.SHDSL).  The CE for voice 
customers is managed by us to ensure QoS is properly configured.  The 
VoIP phones are Linksys currently and will be connected either directly 
to the router (ISR) or a managed PoE switch (Cisco again).  Voice will 
be on a voice VLAN configured as such on the switchports (so it's only 
reachable by devices that speak CDP and look like a phone).  One problem 
with this offering is with remote access to the phones in the voice VLAN 
on the managed-CE.  We could configure IPSec client VPNs on each of the 
managed CEs but that gets exponentially ugly as the number of users 
grows.  My favorite thought is to extend MPLS all the way down to the 
managed-CE (which dictates a minimum of a 2800 ISR, 2811 or bigger for 
our needs, running Adv IP).  Then we could extend a common voice VRF to 
that managed-CE.  The voice VLAN would be put into that voice VRF.  This 
would give us the ability to access the GUI config of the customer's 
phone to configure it, command it to resync, reboot it, etc.  Otherwise 
we're forced to either have the user power cycle the phone by unplugging 
it from the network or figure out which switchport it is and cut the 
power to it.  We could also generate a truck roll to do something as 
trivial as adding a speed dial; not a cost-effective idea.

I favor the voice VRF idea but I struggle to figure out how to fully 
implement it.  On the managed-CE side it's not very hard.  MPLS, LDP, 
mBGP, IGP (IS-IS), address the phones uniquely for each site in the 
common VRF, etc.  Back in the main POPs is where I'm having the most 
difficulties with this concept.  Do I consider a phone hung off of a 
managed switchport trustworthy enough to bring it in BEHIND my firewalls 
and SBCs and allow it direct access to the secured MetaSwitch network? 
If so then this really isn't that hard.  I'll use the same VRF at all 
VoIP sites that I'm going to use behind the MS PIXs.  If I don't 
consider it trustworthy then I have to run the voice traffic through the 
PIXs or SBCs to get the filtered traffic to the MSs, either through the 
outside int of the PIXs or through a DMZ int.  The DMZ interface thought 
opens up some possibilities at least; I can somewhat envision that int 
being tied to a VLAN that's part of the voice customer VRF.  That gives 
me a device to bridge the gap between the a customer voice VRF and the 
MS VRF.  If I didn't use the DMZ then I wouldn't know how to pop 
customers out of the voice VRF to gain access to the public side of the 
PIXs which are in our default VRF.  BTW, all public traffic on our 
network is in the default VRF.

This is a rather complicated problem, or at least I'm mentally making it 
complicated.  I think I could continue using the PIXs and SBCs to bridge 
the gap between the protected MetaSwitch VRF and the unprotected public 
Internet.  It's what to do with the Voice VRF that perplexes me the 
most.  The Voice VRF concept is a popular example in Cisco Press books 
like the MPLS Architectures books.  Unfortunately those books don't 
really tell you how to implement it end to end which is what I need.  It 
also doesn't help you decide when the traffic is secure and when it's not.

Does anyone have any suggestions, pointers to example scenarios, guides, 
howtos, etc?  I'm sure this can be done but I'm missing some critical 
pieces at this point.

Thanks
  Justin