• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Is it opssible to use route target w/ VRF Lite?

C

Cooky

Golden Member
We have a need to set up a MAN to inter-connect multiple sites in a metropolitan area.
The sites will be connected via a 1-Gbps fiber ring.

Each location has multiple vlans, and one of the requirements is to isolate the vlans so that they can't communicate w/ each other.
One exception is the "service vlan" that contains servers & printers, which all vlans should be able to talk to.
A vlan / user group should still be able to talk to the same user group at the other locations.

We plan on running OSPF to provide routing between the locations, but are not sure how to handle the VLAN segregation and provide connectivity to the service vlan at the same time.

We'll definitely NOT do ACL's because the administrative overhead is just too much.
We're thinking about VRF Lite, so basically each VLAN will be assigned an RD.

We'd also like to use route targets to control which VLAN's can communicate w/ the other VLAN's.
However, we're not sure if this would work w/ VRF Lite, or if the full blown VRF & MPLS are required.

If the latter, we're screwed because we don't have the necessary hardware to support MPLS and gig speed at these locations. (we have a bunch of 2800/3800 routers but they can't handle the traffic rate)

Could the routing experts please chime in and help?
thanks.
 
Thanks for both of your replies.

Private vlan is not as messy as doing ACL's but also requires quite a bit of administrative overhead.
Also I'm not sure how that would work w/ LWAPP wireless.

I have to admit I've never done Q in Q, but know the high level concept.
From what I remember, it allows carriers to transport different customers' .1q trunk traffic throughout the same SP network.
How does that fit into the local area network when I need to control vlan access though?

We'd love to use VRF-Lite if that works the way we want it to...
 
Originally posted by: Cooky
I have to admit I've never done Q in Q, but know the high level concept.
From what I remember, it allows carriers to transport different customers' .1q trunk traffic throughout the same SP network.
How does that fit into the local area network when I need to control vlan access though?
Click to expand...

I was kind of curious about the use of QinQ trunking for this particular situation. I did a little research and saw this. Maybe that example and diagram fits the kind of solution you're looking for.

Definitely give us an update on what solution you decide to go with. I think this is an interesting problem. I'm also curious how many sites you have to support with this solution. Any way good luck.
 
To be fair q-in-q is EXACTLY what Cooky is looking for. Why make it more complicated than it needs to be? This is EXACTLY why it exists.

Keep. It. Simple. Stupid.
 
With q-in-q, how do you allow two VLAN's to talk to each other in one location?

The other two engineers and I all opted to go w/ VRF-Lite.
The catch is we'd have to run BGP in order to utilize the import/export function for RT's.

At the end it didn't matter because our manager wanted to stick w/ the traditional ACL's between each VLAN....he was afraid our support staff wouldn't know how to work w/ VRF.
I wanted to tell him "why don't you just deploy hubs and plug everything in as a flat layer 2 network? that way you don't have to worry about the support staff..."

I held back because I still have a family to feed...it ruined my day.
The whole day I was sooo pissed...any of your employers hiring?
 
q-in-q just allows trunking across the MAN. routing between them still involves routing. I'd need to draw it out because I'm still not clear on what you really want. It sounds like you should engage cisco support as in your local SE and escalate it from there. I don't think I can be of more assistance without a whiteboard.
 
That's what I thought; thanks for the clarification.

Sorry for not having made it clear.
In essence, each location has three vlan's - normal users (vlan101), privileged users (vlan102), and services (vlan103).
vlan101 & 102 can't talk to each other, but they both need to talk to vlan103.
All three vlan's need to be able to communicate to the same vlan's at all remote locations, meaning:
vlan101 from site1 can talk to vlan101 from site2, site3, 4, 5,...
The same for vlan102 & 103.

This is the dumbed down version of the scenario.
There are other requirements such as influencing the direction of the ring traffic so that MPLS & Internet traffic would go certain way, but that's not within the scope of this discussion.

So, for the inter-site communication among the same vlan's (vlan101 from all locations), q-in-q works perfectly.
However, we need to address the need to separate two vlans (101 & 102), but allow access to vlan103.
This is the part that we were trying to get the best solution for.

Edit1:
You were right - this would've been better if we had a whiteboard session
 
In case anyone was interested, I just confirmed local route-target import/export is supported under VRF-lite, although you need to run a local BGP process to make it work.
That's how we'll implement the MAN.
 
You must log in or register to reply here.

TRENDING THREADS

Back
Top