Route targets in Multi-Vrf

[maosa7578]

I am trying to understand why I would need import/export route-targets in a CE configured for Multi-Vrf. Since the CE will have connections ( physical or logical ) to an attached PE, the VRF association on the CE should be enough by connection alone. But I have seen some configs on CEs that actually have route targets in the configured VRFs and I cant understand how these get to be used. My understanding of Route targets is that they only get to be relevant when you want to associate updates coming from a remote peer to a locally configured VRF. Since the CE is not directly receiving or sending updates to any remote peers, why would one configure them on the CE ?

I hope my question is clear.

Anyone ?

Herbert.

[pkhatri]

Herbert,

What if you had a situation where you had to share some routes between VRFs on the same local router ? The route-targets would sure come in handy then ...

Pls do remember to rate posts.

Paresh

[maosa7578]

Paresh,

I will need more schooling here. Can we run Multi-VRF on a CE without BGP ? If the answer is yes, how would we share route-targets since route-targets are BGP extended community attributes?

The particular configs I have seen actually have two vrf on a CE. One of the VRF simply has an RD, and networks belong to it simply by interface association. The other VRF has RTs in it. So in this situation then definitely it is not for local exchange or routes on the CE. The CE is then connected to a PE as normal. Is this a common setup ? RTs on a CE running Multi-vrf ?

Herbert.

[pkhatri]

Herbert,

You certainly do not need BGP on a CE to run multi-VRF. I just did a quick test for you on a live router and the route-target is indeed ineffective without the use of BGP (I was thinking that Cisco might possibly use the route-target for import/export between VRFs on the same router without enabling BGP). So the answer to your question is that configuration of route-targets in a multi-VRF VRF serves no purpose. In fact, I found a document on CCO that confirms that:

http://www.cisco.com/en/US/products/hw/switches/ps4324/products_configuration_guide_chapter09186a00801cddd9.html

Pls do remember to rate posts.

Paresh

[maosa7578]

Hi Paresh,

Again thanks for this. But this document just adds to my confusion because it actually does configure route-targets on the CE ( the Catalyst 4500 Switch ). I still dont understand why one would need route targets on the CE.

Many thanks,

Herbert.

[pkhatri]

Herbert,

As that example goes, the route-targets are doing nothing. I believe it is just showing you what is possible. Since the switch is running BGP, you have the possibility of imoporting routes between VRFs if you want to do so for any reason.

So the bottom line is that the examples show what is possible and as a result, the route-target config is not really necessary. I've used multi-VRF without needing to define route-targets so I don't believe they are necessary at all...

Pls do remember to rate posts.

Paresh

[mheusinger]

Hello,

as already pointed out, route-targets are BGP extended communities. So in case you need VRF to VRF connectivity withing one PE using Multi-VRF you need to enable BGP and use proper route-targets. An example:

ip vrf NMS

rd 65000:161

route-target export 65000:161

route-target import 65000:162

ip vrf Cust1

rd 65000:1

route-target import 65000:161

export map ManagedCE

ip vrf Cust2

rd 65000:2

route-target import 65000:161

export map ManagedCE

router bgp 65000

!

address-family ipv4 vrf NMS

redistribute static

exit-address-family

!

address-family ipv4 vrf Cust1

redistribute static

redistribute connected

exit-address-family

!

address-family ipv4 vrf Cust2

redistribute static

redistribute connected

exit-address-family

route-map ManagedCE permit 10

match ip address 10

set extcommunity rt 65000:162

access-list 10 permit host 10.1.1.1

access-list 10 permit host 10.2.2.2

This would allow you to manage devices (10.1.1.1 and 10.2.2.2) found behind a Multi-VRF router through one interface connected to VRF NMS. Without RT and MP-BGP the solution would require a separate management interface per VRF, which is much less scalable.

This way also overlapping VPNs, Central Service VPNs and the like can be implemented.

Hope this helps! Please rate all posts.

Regards, Martin

[maosa7578]

Hi Martin,

Thanks for your reply, but I dont think I quite understand it. Firstly can you clarify whether the supplied config is going on a PE or a CE ? I understand the use of route-targets on the PE, but I dont understand their use on a Multi-VRF CE.

If I wanted to manage a device beyond the CE running multi VRF, I could still do so without using route-targets, and still use one physical interface between the PE and CE as well as the CE and the Managed device. All I would need to do is to create seperate logical interfaces on both the PE-CE link as well we CE-Device Link, and just associate these interfaces to the vrfs.

for instance

ip vrf Management

rd 111:100

!

interface serial0/0/0:0.100 point-to-point

description Connection to PE

ip vrf forwading Management

ip address x.x.x.x y.y.y.y

!

interface Fa0/0.100

description Connection to Managed device beyond this CE

encapsulation dot1q 100

ip vrf forwading Management

ip address a.a.a.a b.b.b.b

On the PE I will just associate the corresponding interface to serial0/0/0:0.100 in the Management VRF that is defined on that PE. Then if I enable BGP on this link and let the CE advertise the Fa0/0.100 LAN from its management vf to the PE, the PE should be able to manage the devices beyond the CE if it sources its management packets from the Management VRF. All this without the need for route-targets on the CE.

Am I making sense ? I hope so....

Herbert.

[mheusinger]

Hello Herbert,

I think the names PE and CE are somewhat inappropriate in my example. All I showed is a Multi-VRF router, no matter who administers this box or whether there is any MPLS enabled router around.

VRFs, RTs and all that have been invented over the last ten years. Fot sure there are solutions without RTs - but not quite the same. In your example finally you need either Multi-VRF on every router to be managed or you have a normal router.

The first example is for sure more complex to administer and operate than the second possibility.

The second possibility a normal router without VRFs will have to have a separate subinterface for Management purposes, which also imposes some security risks of routing between customer network and NMS network. You could prevent this through filters, but again complexity increases.

The point really is: VRFs are like Virtual routers. And for one reason or another you might want connectivity between those virtual routers (inside a Multi-VRF router). One example is centralized management, which I described above. Another could be several departments/company accessing the same server.

If you are RT-phobic ;-) then you can always avoid them. But to me (RT-affin ;-) it is in some cases the most elegant and scalable solution for a given problem.

Hope this helps! Please rate all posts.

Regards, Martin

P.S.: the communication between VRFs inside a MPLS PE is also working exactly like in the Multi-VRF router. And the same reasons, why you use overlapping VPNs and the like apply to both MPLS enabled PE and Multi-VRF router without any labels involved.

[maosa7578]

Hello Martin,

I think you just succeeded in confusing me further ? Am I being rediculous ? I hope not. I thought the whole point of creating VRFs is to isolate routes ? If on the same device (PE or CE ) I want to share routes between VRFs, wouldn't one VRF suffice ? In that case all updates from remote PEs will go into the VRF by way of route-targets and the locallly attached networks would go into the VRFs by associating their physical interface ?

[mheusinger]

Hello,

well I do not totally agree to your statement "the whole point of creating VRFs is to isolate routes". There is not a single point, but a set of interesting features. The idea of VRFs is to build a - more or less - hardware independant L3 infrastructure, which supports all kind of customer connectivity requirements.

Managing devices in different customer networks is one specific connectivity requirement. Assume there are 500 separate customers, so you need 500 VRFs. How to connect your NMS? One VRF where everything is connected to would NOT suffice in this case. The two questions to be answered in this case are:

First, how do you insert the route to the NMS into every customer environment (VRF)?

Second, how do you insert the (loopback) host routes into the NMS routing environment?

Well, you could try to set everything up with sub-interfaces and distribution lists - but my argument is, that this approach is not very scalable from an operations point of view, using 500 sub-interfaces and separate distribution lists per customer.

Exactly for this purpose RTs were invented. So you need only one interface between NMS and Multi-VRF/PE router and route-distribution is done through RT import/export. There is NO NEED for a remote or second PE here. The use of RTs is independant of the number of PEs/Multi_VRF routers involved.

Hope this helps! Please rate all posts.

Regards, Martin