cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3482
Views
0
Helpful
14
Replies

VRF without RD

CiscoNutt
Level 1
Level 1

Hi,

Is it possible to configure an MPLS VRF without the use of RDs?  I have tried to get this to work in a lab but have been unsuccessful (I have always had to use RD to get it to work)

If I were to set up a MPLS VPN between a Nexus switch which has VRFs without RDs, and an IOS router, how would I go about doing this?  Would I need to configure RDs on the Nexus to get this to work?           

14 Replies 14

Hello.

I guess you are talking about VRF lite and not MPLS VPN.

For VRF lite it's mandaroty to have RD under ip vrf confiruration.

RD is different from RT, and in VRF lite only locally significant (as well as VRF name).

So, what is the issue you are trying to escape omitting RD?

I am wondering if it is possible to refrain from using RD and yet have VRF functional between two locations or at the least not have to use RT

RD and RT are used in BGP. They are not needed for VRF lite. However, configuring RD is still enforced in some software versions.

Which routing protocol do you plan to run between the two locations?

Daniel Dib
CCIE #37149

Please rate helpful posts.

Daniel Dib
CCIE #37149
CCDE #20160011

Please rate helpful posts.

Was wanting to use BGP, to integrate it with the existing configuration on the Nexus switches

The setup is that we will have two new IOS routers between two locations.  Some of the VRFs already exist in the Nexus setup while other will be new.  I need the existing VRFs on the Nexus network to be able to access the new network.  the new routers will be directly connected to the Nexus switches with trunks.

I suppose I am wondering that if we use RD and RT on the new setup and the nexus switches do not use RD and RT will traffic within the same VRF still be forwarded between the new network and the existing network.  we have a firewall that handles all inter VRF routing.

It's not clear where the firewall is in relation to the new routers. If you are trunking to the routers then i assume you are going to place the SVIs on the Nexus and the corresponding subinterfaces on the router into the same VRF ?

If so and you are using VRF-LIte then as others have said RD (and RT) are only locally significant ie. they only mean something to the actual device you have configured them on unlike MPLS where they have meaning between PE devices.

So if the router placed the correct routes into each VRF then the Nexus would be able to access the new networks. How the router is doing that is unclear. If the router is a PE device running full MPLS then yes it could import the correct routes into each VRF and there should be an end to end path.

The only thing that is not clear is how you are going to route bewteen the existing and new VRFs. Is this where the firewall comes in ?

If it does it's not clear how the firewall will learn of the new VRFs unless you extend them from the Nexus to the firewall but it's difficult to say without seeing the topology. It may be you do not need communication between the existing and new VRFs.

I had a brief look at the Nexus configuration guide and it does seem as though you can configure a VRF without the RD so this may be where the confusion has come in. With or without, it is, as already said, only significant to the actual device so it should work.

Jon

Vasilii, think u are right, he is talking about the VRF lite, RD is locally significant

CiscoNutt
Level 1
Level 1

Nice!  The reasoning for this is that I have been asked to implement a new part of the network using BGP as the routing protocol and implement it with the existing network (which happens to be Nexus switches with several VRFs).

All VLANs within the different VRFs will be extended to the firewall which will in turn be handling all inter VRF router as well as routing to the internet. So the network would look something like this. The first ASA is there to provide a barier between the company and a 3rd party.  I am thinking (or I should say hoping) to configure MPLS VPN between R1 and R2, and R2 connects to the Nexus with subinterfaces within each VRF VLAN.  The Nexus already has SVIs (some new ones will need to be created) that are part of existing VRFs.  The Nexus in turn has a trunk to the ASA where all VLANs are extended to and inter VLAN and VRF routing happens.

ASA---R1---R2---Nexus---ASA

Now the existing client network on the Nexus needs to be extended to R1.  So since RD and RT are only locally significant this should be a viable setup.

Please correct me if this is not possible.

Thanks again

Between R1 and R2 is an MPLS WAN or are they just connected to each other, sorry it's not clear.

If any of the following is wrong then please clarify -

 

1) the existing client network VRF is routed on the right hand ASA.

2) on R2 you are going to have subinterfaces connecting to the Nexus switch

3) the subinterfaces and corresponding SVIs will each be in their own VRF.

4) you are going to run MPLS between the routers and import the relevant routes into each VRF

If the above is correct then yes it should work as long as the new VRFs are extended to the right hand ASA because that is where the inter VRF routing is done. So you would need to presumably have new interfaces/subinterfaces for the new VRFs on the right hand ASA.

Traffic flow would obviously be from the clients network on the Nexus to the right hand ASA back to the Nexus (in the target VRF) and then on to R1.

Is this what you were thinking of ?

Jon

The only thing i am not clear on is why you have SVIs on the Nexus in VRFs if those VRFs are routed on the firewall ie. for traffic to go anywhere from one VRF to another you have to go to the ASA anyway.

Or do you have multple SVIs in the same VRF on the Nexus ?

 

Not trying to confuse the issue, i just want to make sure i fully understand the setup.

Jon

Between R1 and R2 is an MPLS WAN or are they just connected to each other, sorry it's not clear.

The routers will be directly connect.  We will have a dark fiber running between the two locations.

The only thing i am not clear on is why you have SVIs on the Nexus in  VRFs if those VRFs are actually routed on the firewall ie. for traffic  to go anywhere from one VRF to another you have to go to the ASA anyway. 

There are several SVIs per VRF on the nexus

1) the existing client network VRF is routed on the right hand ASA.

The whole network is owned by the comany so all VRFs that are configured on the nexus are owned by the company.  All inter VRF traffic is routed through the firewall, and all intra VRF traffic is routed directly to the desired location without having to go through the firewall.

If the above is correct then yes it should work as long as the new VRFs  are extended to the right hand ASA because that is where the inter VRF  routing is done. So you would need to presumably have new  interfaces/subinterfaces for the new VRFs on the right hand ASA.

Thanks for the heads up...this has already been taken into consideration and the required VLANs and subinterfaces throught the new network addition has been planned.

I was just uncertain if the RD and RT on R2 would cause any issues between the existing VRFs and the new ones. I suppose saying new VRFs is incorrect.

Lets say that on the Nexus (and around the rest of the network for that matter) we have Client_VRF.  This vrf is to also exist in the new addition to the network which will be running MPLS VPN (as the plan is right now).  My concern is if this existing VRF would have problems communicating with the same VRF on the new network...and vice versa.

Lets say that on the Nexus (and around the rest of the network for that matter) we have Client_VRF.  This vrf is to also exist in the new addition to the network which will be running MPLS VPN (as the plan is right now).  My concern is if this existing VRF would have problems communicating with the same VRF on the new network...and vice versa.

When you say existing VRF and new VRF you are talking about the same VRF ?

If you add the Client_VRF to R2 then as long as you place the correct subinterface(s) on the connection to the Nexus into the Client_VRF then you have in effect just extended the VRF. But i can't see what this gives you unless you plan to import/export routes between VRFs on R2 in which case inter VRF routing would not be needed on the ASA.

I am now not sure what you are trying to achieve. I thought you had networks on the R1 side that you were going to advertise across the MPLS network to R2 which then placed them in their own VRF(s). For the existing VRFs to get to these new VRFs they would be routed via the right hand ASA.

Can you clarify ?

Jon

The thing is I have been unsuccessful in setting up a lab running VRF lite.  I have only managed to get this to work using MPLS VPN...It could be that I am using GNS3 to lab this and it is a limitation of the virtualization.

What I am trying to do is to have seperate routing tables so these VRFs can not route between eachother without going though the firewall, in addition to that I want the subnets within the same VRF to be able to route directly to one another.

I have tried to set this up in GNS3 using OSPF and tunnel interfaces but I am only able to get one neighbor up at a time, the second VRF never creates a neighborship.  Here is the config if you were interested:

R1

version 12.4

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname R1

!

boot-start-marker

boot-end-marker

!

logging buffered 4096

!

no aaa new-model

memory-size iomem 5

no ip icmp rate-limit unreachable

ip cef

!

!

!

!

ip vrf VRF_A

rd 65512:1

!

ip vrf VRF_B

rd 65521:2

!

no ip domain lookup

ip auth-proxy max-nodata-conns 3

ip admission max-nodata-conns 3

!

multilink bundle-name authenticated

!

!

archive

log config

  hidekeys

!

!

ip tcp synwait-time 5

!

!

interface Tunnel1

ip vrf forwarding VRF_A

ip address 100.100.100.101 255.255.255.0

ip ospf network point-to-point

tunnel source FastEthernet0/0

tunnel destination 10.10.10.2

!

interface Tunnel10

ip vrf forwarding VRF_B

ip address 200.200.200.200 255.255.255.0

ip ospf network point-to-point

tunnel source FastEthernet0/0

tunnel destination 10.10.10.2

!

interface FastEthernet0/0

ip address 10.10.10.1 255.255.255.252

duplex auto

speed auto

!

interface FastEthernet0/1

no ip address

shutdown

duplex auto

speed auto

!

router ospf 10 vrf VRF_B

log-adjacency-changes

capability vrf-lite

network 0.0.0.0 255.255.255.255 area 0

!

router ospf 2 vrf VRF_A

router-id 100.100.100.100

log-adjacency-changes

capability vrf-lite

network 100.100.100.0 0.0.0.255 area 0

!

ip forward-protocol nd

!

!

no ip http server

no ip http secure-server

!

logging trap debugging

!

!

control-plane

!

!

line con 0

exec-timeout 0 0

privilege level 15

logging synchronous

line aux 0

exec-timeout 0 0

privilege level 15

logging synchronous

line vty 0 4

login

!

R2

version 12.4

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname R2

!

boot-start-marker

boot-end-marker

!

!

no aaa new-model

memory-size iomem 5

no ip icmp rate-limit unreachable

ip cef

!

!

ip vrf VRF_A

rd 65512:1

!

ip vrf VRF_B

rd 65521:2

!

no ip domain lookup

ip auth-proxy max-nodata-conns 3

ip admission max-nodata-conns 3

!

multilink bundle-name authenticated

!

!

archive

log config

  hidekeys

!

!

ip tcp synwait-time 5

!

!

interface Loopback10

no ip address

!

interface Tunnel1

ip vrf forwarding VRF_A

ip address 100.100.100.100 255.255.255.0

ip ospf network point-to-point

tunnel source FastEthernet0/0

tunnel destination 10.10.10.1

!

interface Tunnel10

ip vrf forwarding VRF_B

ip address 200.200.200.201 255.255.255.0

ip ospf network point-to-point

tunnel source FastEthernet0/0

tunnel destination 10.10.10.1

!

interface FastEthernet0/0

ip address 10.10.10.2 255.255.255.252

duplex auto

speed auto

!

interface FastEthernet0/1

no ip address

shutdown

duplex auto

speed auto

!

router ospf 10 vrf VRF_B

log-adjacency-changes

capability vrf-lite

network 0.0.0.0 255.255.255.255 area 0

!

router ospf 2 vrf VRF_A

router-id 100.100.100.101

log-adjacency-changes

capability vrf-lite

network 100.100.100.0 0.0.0.255 area 0

!

router ospf 1

log-adjacency-changes

!

ip forward-protocol nd

!

!

no ip http server

no ip http secure-server

!

!

control-plane

!

!

line con 0

exec-timeout 0 0

privilege level 15

logging synchronous

line aux 0

exec-timeout 0 0

privilege level 15

logging synchronous

line vty 0 4

login

!

!

end

Jon Marshall
Hall of Fame
Hall of Fame

I am not sure how many routers support VRF-Lite to be honest so it may be a limitation of GNS3.

Can you refer back to my previous post while i look at your configuration because the solution is dependant on exactly what you are trying to do.

So my assumption with all of this was that there were new networks that were on the other side of R1. You want one or more VRFs on your Nexus to be able to communicate with these networks. If so then i can't see why you want to extend the Client_VRF to R2.

Basically these new networks would be advertised to R2 from R1. Then you place them into the correct VRF subinterfaces. These subinterfaces correspond to the equivalent SVI on the Nexus and they are routed via the right hand ASA.

Note that in actual fact you do not need to use SVIs on the Nexus. You could simply use the right hand ASA ie. they still go via the Nexus but they are simply L2 switched through from R2 to the Nexus and from the Nexus to the ASA via the trunk links, no need for SVIs on the Nexus as you only route to them via the ASA anyway.

But again i am still not clear on exactly what you mean when you talk about the same VRF on both the Nexus switch and R2 ?

Jon

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Review Cisco Networking products for a $25 gift card