Layer3 to the edge

[Zach Smith]

I have a goal of segregating some internal networks at my company.  The catalyst for this project is PCI compliance.  Internally I run two 6509-E chassis in VSS and 4507 switches in my closets.  These 4507 switches have a direct trunk link to my 6509 core.  I have no 'middle' distribution layer.  Core-Edge.

Now - I need to segregate some networks.  Each closet switch has 2 VLANs that only that closet has.  Vlan 10,11 on Closet A, VLAN 20,21 on Closet B etc.  I have about 12 closets.  Also on these closets are some networks that 'float' around the building.  A VLAN for access on an external circuit for our conference rooms, a VLAN for the PCs in the conference rooms, a VLAN for any developer.  These VLANs exist on every switch. 

I'm changing my L2 links from my core to L3 port-channel links becuase I've come to the conclusion that creating VRFs is the way to go for the segregation I need.  (If you have a better idea by all means...)  Since I need to implement VRF (VRF-Lite it is called on the 4500s) I am under the impression I need to run L3 from my core to my edge switches.  Here is my problem that I haven't figured out yet. 

If I take one closet - say closet A and move them to L3 - my 'floating' VLANs - how do I keep them on the switch?  Lets say I have a floating VLAN of VLAN100 - I have 2 users on this closet switch in VLAN100 - when this switch becomes L3 - that VLAN tag isn't important once it goes onto the L3 link to the core.  Is there a way to keep this?  I guess I could keep a L2 link between my edge/core switch with only the 'floating' VLANs on the trunk...but I would rather not do that.  Any ideas?  Perhaps there is a better way to segregate my networks?

Thanks for the help.

[daniel.dib]

One option is to keep the L2 trunks. Create SVI with unique VLAN which is P2P between edge and core. Run routing over this VLAN. That way you can keep spanning VLANs but still do routing for all other traffic.

You lose a bit in convergence running routing over SVIs compared to physical links. If that's acceptable then it's a viable solution.

Daniel Dib
CCIE #37149

Please rate helpful posts.

[paul driver]

Hello

Have you thought about PVLANS?

res

Paul

Please don't forget to rate any posts that have been helpful.

Thanks.

[Zach Smith]

Yea I have thought of that.  Initially I didnt want to turn my switches into VTP-Transparent switches...but the more I think about what I'd be doing by running L3 - VTP-Transparent seems much simpler.  When someone would implement VRF across their internal LAN..I wonder what implementation approach they take.  I couldnt imagine doing this as an all-or-nothing implementation.  Too much risk.  However I'm still white boarding my solutions and PVLAN is looking more and more attractive each day.

[paul driver]

Hello

The beauty of pvlans is, it also supports inter-vlan communcation and once setup you can add/remove or isolate vlans at you will, then I suppose the this also applys to vrf-lite however the latter seems a lot more work and re-config to setup.

res

Paul

Please don't forget to rate any posts that have been helpful.

Thanks.

[Jon Marshall]

The issue as you have outlined is that with a L3 access layer your vlans are contained within the access switch so you cannot have a vlan on multiple access layer switches. This is the main limitation of using L3 to the access layer. And it also why, since the advent of VSS and MEC on stackable switches the L3 routed access layer is not necessarily such as good choice because VSS etc. has removed a lot of the STP issues you faced before.

Where i am slightly confused is where you say you need L3 for VRF-Lite. I have actually found the opposite to be the case ie. if you have a L3 interface that interface can only be in one VRF. If you had vlans on a switch that you wanted in different VRFs a L3 link is a problem. Whereas a L2 trunk link is not because each vlan then has it's own SVI which you can allocatd into different VRFs. So you can then extend the VRFs back to your coe/distro switches.

In the last place i worked i wanted to extend certain MPLS VPNs back into the LAN using VRF-Lite but the thing that stopped us doing it was that the access layer switches were uplinked to the distro switches with  L3 links so we could not extend the VRFs to the access layer.  Unfortunately for other reasons we could not change the links to L2 trunks so we had to do something else.

So i may have misunderstood your original point and perhaps you do not want to use VRFs between the vlans on each access switch but if you do then a L3 link would not work.

Edit - in terms of setting it up , as long as you have L2 trunks it is relatively straightforward but what you do need to plan, if you decide to go that way, is whch routes need to leaked between VRFs eg. internet default route for example. With MPLS VPN you obviously have route targets and can us MBGP to do this but when i was looking into VRF-Lite which is long while ago the solution for route leaking was static routes.

Edit 2 - just found this link (thanks Alain !) which shows how you could do it using BGP. Note you don't actually need to have a BGP peering with another router, you just use BGP or more specifically MBGP to import and export routes between VRFs -

http://blog.ipexpert.com/2010/12/01/vrf-route-leaking/

As Paul has said though, the configuration does become more complex.

Jon

[Zach Smith]

Thanks for the links Jon.  I could have sworn I read somewhere that L3 to the edge was a requirement of VRF.  Let me read the blog post and get back with you.  Thanks again.

[Jon Marshall]

I could have sworn I read somewhere that L3 to the edge was a requirement of VRF.

You got me thinking there

I thinks the documentation can be a bit confusing eg. from the 4500 VRF-Lite configuration guide -

First it says this -

Note VRF-lite interfaces must be Layer 3 interfaces.

which makes you think it might only be physical links but then a bit further down -

The Catalyst 4500 series switch supports configuring VRF by using physical ports, VLAN SVIs, or a combination of both. The SVIs can be connected through an access port or a trunk port.

full link is here -

http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.2/25ew/configuration/guide/vrf.html

There is no equivalent configuration chapter for the 6500 that i can find but it does support VRF-Lite and this document suggests it will do VRF-Lite on SVIs -

http://www.cisco.com/en/US/products/hw/modules/ps2797/products_tech_note09186a0080b6216e.shtml

Jon

[Zach Smith]

Jon - the article is very interesting.  I do believe this will be the way to go.  I'm going to confirm some configurations in my 'lab' and report back, however I do suspect that is the best solution to my scenario.

Thanks much

Zach

[Jon Marshall]

Zach

Just in case you check back to this thread there is now a technology that's called Easy Vitual Network (EVN) which apparently simplifies the deployment of VRFs within a campus environment. It is supported on 4500/6500 switches but you do need relatively recent IOS versions.

Cisco anticipate it will replace VRF-LIte but i have absolutely no idea how much it is being used, whether it is stable etc. etc.

It might be worth a look though. Just do a search on CCO for EVN and you should find some documentation.

Edit - if you haven't already seen it here is a link to a design document on path isolation and it discusses VRF-Lite/EVN among other things -

http://www.cisco.com/en/US/docs/solutions/Enterprise/Campus/Network_Virtualization/sccsolover.html

Jon