VRF lite help

Answered Question
Nov 13th, 2009

Hey all. I am trying to configured VRF-lite in a Dynamips environment using four 3640 routers (topology is shown in the attached .jpg). For some reason I am just not grasping the concepts behind VRF in general. I have been scouring the Internet for references all day (literally all day) to try and find a blog or a white paper that can "flip the switch" so to speak and get me over the hump. One of the areas that I'm REALLY struggling in is with the idea of RD and RT's. Is the RD globally unique or not?? For the RT's, I see some configs that have both the export and import set as the same ASN:nn but in some others I see the export = the local RD and the import = a neighbors export RT. For example:

rtr1

ip vrf rtr1vrf

rd 64512:01

route-target export 64512:01

route-target import 64515:01

rtr2

ip vrf rtr2vrf

rd 64515:01

route-target export 64515:01

route-target import 64512:01

How and why would you set the export and import to be the same?? When I do a sho ip bgp or a show ip bgp neighbor I just get blank lines back, why is that?? I am peering successfully. One last question is in my scenario I don't want Clutterbuck and Burns to know about each other, but I want Koivu to know about both of them. I thought that I could just configure Clutterbuck and Burns to import routes from 1001:2 and they would only see the routes sourced from Koivu. Do only routes sourced by Koivu get the 1001:2 extended community value?? Do I need to have a distribute-list in place instead?? It just doesn't make sense. Please give me a swift kick in the skull...

I have this problem too.
0 votes
Correct Answer by Giuseppe Larosa about 7 years 2 weeks ago

Hello Dennis,

my first answer is misleading because it is focused on MPLS VPN.

With VRF-lite there is no VPNv4 address-family and you have eBGP sessions in address family vrf.

to be noted that this should be normal eBGP sessions, that is I don't expect that the job you did on route targets that is already similar to what I called hub and spoke is effective.

you are using send-community both but this should not allow to pass route targets.

in your case you should use route-maps like in a classic scenario to filter routes sent to each device.

let me say in real world VRF lite is not used in this way.

In a scenario like yours is more common to use full L3 MPLS VPN.

in that case central router can act as P node and Route reflector server and it is possible to implement an hub and spoke topology playing on route targets.

VRF lite is used with multilayer switches to act as multi-VRF CE nodes shared by different customers.

Hope to help

Giuseppe

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.5 (2 ratings)
Loading.
Giuseppe Larosa Sat, 11/14/2009 - 01:49

Hello Dennis,

to see VPNv4 routes and peerings you need to use

show ip bgp vpnv4 all summary

in the same way to see a prefix

sh ip bgp v a

about RD and RT:

their usage can be different depending on what you want to achieve.

the simplest scenario is that of any-to-any connectivity:

in this case RD and RT can be equal the end result is that all VRF sites can communicate directly.

When to use different RTs:

to provide different connectivity models, if there is a customer that wants to implement an hub and spoke topology so that communication between remote sites is not direct but going via a central site for security or other reasons.

for an hub and spoke

remote VRF sites import central site route-target RT1

central site imports RT2 exported by remote sites

multiple RTs can be associated to a VPNv4 prefix but only one RD.

multiple RTs can be useful to implement an extranet where some sites of customerA have to talk with some sites customerB.

RTs are extended BGP communities associated to the VPNv4 prefix.

RD is part of the VPNv4 prefix

VPNV4 = RD+32 bits IP address

RD exists to allow support of overlapping IP addresses in different non-communicating VRFs.

There are cases where RD has to be differentiated:

a multi homed VRF site that connects to two different PE nodes require to use two different RD to have both PE nodes advertisements propagated by Route Reflector servers in the provider domain.

if RD is equal RRS propagates only one advertisement the best BGP path.

RD has to be unique within a single PE node.

About your last question:

the more elegant solution is to use two route targets values in an hub and spoke connectivity model.

Hope to help

Giuseppe

unclerico Sat, 11/14/2009 - 07:22

Guiseppe,

Once again, thank you for your help I really appreciate it!!! I have a loopback on the PE router (Backstrom) that is the update-source for all BGP peers. Should that interface be in the global routing table?? Could you explain a little more what you mean about your suggestion of using two route target values in a hub and spoke connectivity model?? Thank you very much!!!

Correct Answer
Giuseppe Larosa Sat, 11/14/2009 - 11:46

Hello Dennis,

my first answer is misleading because it is focused on MPLS VPN.

With VRF-lite there is no VPNv4 address-family and you have eBGP sessions in address family vrf.

to be noted that this should be normal eBGP sessions, that is I don't expect that the job you did on route targets that is already similar to what I called hub and spoke is effective.

you are using send-community both but this should not allow to pass route targets.

in your case you should use route-maps like in a classic scenario to filter routes sent to each device.

let me say in real world VRF lite is not used in this way.

In a scenario like yours is more common to use full L3 MPLS VPN.

in that case central router can act as P node and Route reflector server and it is possible to implement an hub and spoke topology playing on route targets.

VRF lite is used with multilayer switches to act as multi-VRF CE nodes shared by different customers.

Hope to help

Giuseppe

unclerico Sat, 11/14/2009 - 13:53

so the only way that the RT is used is with a VPN?? in my previous post i asked if i should include the loopback interfaces that are used for BGP peering in the global routing table as opposed to any particular VRF instance; is this correct??

do you have a blog or anything?? i'd love to be able to look at mock labs and your description of how those labs work because you explain things very concisely.

i appreciate the time you are taking to help me out!!!

Reza Sharifi Sat, 11/14/2009 - 14:24

Dennis,

If you are using a VRF lite to peer with another VRF, you should use a loopback interface for that specific VRF. If you are using the global routing table, then you should use the global loopback interface. For example, use Lo0 for global peering and Lo100 for VRF peering.

Don't forget to add Lo100 to whatever VRF you using.

HTH

Reza

Actions

This Discussion