Migrating Layer 2 network to VRF

[DROFNUD]

Hi,

We are in the process of merging a couple of networks into one and using VRF's to separate the client zones. The core is a pair of Nexus 5762's with Fabric extenders and we are moving connections from a 6500 over to it.

My question is in regards to Client VLANS. Currently we have a Data, Voice, Printer and Management VLAN on the access layer switches and at first I was planning to simply drop Data, Voice and Printer into a "CorporateUsers" VRF, however the Voice VLAN would need to extend over multiple client networks including the servers.

To complicate things further, the client PC's have Lync phones installed, so all this traffic is using the data VLAN.

Any suggestions to which is the better solution?
1) Put the Voice VLAN in a different VRF and use Virtual Route Forwarding to route between Voice and Server VRF's.
2) Leave it in the client VRF's (Along with Lync) and add firewall rules to allow the different voice networks to communicate?

If you know of any best practice guides or other documentation I would really appreciate it.

Thanks in advance guys,
Si...



----------------------------------------

http://www.itspeedway.net

 

[Speedline]

What did you end up doing? I've never used VRFs because I find they complicate things and I've also seen other people suggest that it's best to avoid using them if you can.

 

[DROFNUD]

Hi Speedline:

We've rolled out option 2 and moved Voice traffic into the Client VRF. This part of the project is nearly complete with only a couple more user areas to do during an evening next week.

The logic behind the final choice was that Lync traffic is already in the Data VLAN so adding the Voice VLAN to the same VRF would reduce cross-firewall traffic for internal phone calls. At some point in the future we might look at Virtual Route Forwarding of traffic to the servers but for the moment it is looking good.

When we first started looking at VRF's I must admit I thought it was overly complicated and I expect that in most networks they are a bit of an overkill; however now that we've started down the road we are finding that our entire network is simplified and the firewall rules are much cleaner. I doubt every network is as well suited to using them as ours.

The biggest issue has been getting our heads around having multiple layer 3 routed networks running over the same infrastructure! Followed closely by having to upgrade firmware on the entire Cisco estate to IPSERVICES... That was not fun.

Our network is a bit unusual in that we have several third parties onsite to which we outsource parts of the business and they use our infrastructure to communicate between users and their network. Some have their own switches, routers, servers and external connections coming into our main datacenter. Previously communications was done either by allocating a VLAN across the network or by installing separate hardware and running additional fibre or circuits which doubled, trebled (or worst) things up. We also have a guest network where the general public can access the internet and this was previously on an entirely separate switched network across multiple sites with it's own internet connection.

Essentially our network was being used as a carrier for both Corporate, Third party and Public user traffic and whilst VLAN's kind of worked, VRF's have allowed us to separate these logically and reduce the switch count, the number of circuits and ADSL count. The network as it exists now treats each client/third party individually; even our corporate users and servers. In each comms room and datacenter rack there are "Top-of-rack" switches or routers with interfaces configured for the required VRF's. We can add a switch or server to any comms room for any client or third party and know that the traffic will remain secure and isolated from others.

We are still working on migrating some third parties and offices, but there is enough in place already to know we have made a good decision.

One thing stands out as an important consideration before others embark upon this venture: Your firewalls will be doing a lot more work processing Cross-VRF traffic and they become a primary part of your core network. Make sure you have enough capacity in your CPU and your logs for huge growth. All data from the clients to the servers now passes through the firewall and this is huge! Additionally you might need to consider VRF/VSX compatibility in your firewall, especially if you are going to support overlapping subnets.




----------------------------------------

http://www.itspeedway.net

 

[burtsbees]

Wondering why you didn't go with B2B IPSEC VPN's for the third parties and throw incoming traffic into whatever VRF...

ip access-list extended IP-Options-and-Powerball
deny ip any any winning-powerball-ticket
permit ip any any option any-options
!
class-map ACL-Options-and-Powerball
match access-group name IP-Options-and-Powerball
!
policy-map CoPP-POLICY
class ACL-Options-and-Powerball
drop
!
control-plane
service-policy input CoPP-POLICY