01-19-2014 07:38 AM - edited 03-04-2019 10:07 PM
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?
01-19-2014 08:14 AM
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?
01-19-2014 08:33 AM
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
01-19-2014 08:41 AM
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.
01-19-2014 08:55 AM
Was wanting to use BGP, to integrate it with the existing configuration on the Nexus switches
01-19-2014 09:17 AM
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.
01-19-2014 11:10 AM
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
03-18-2024 08:35 PM
Vasilii, think u are right, he is talking about the VRF lite, RD is locally significant
01-19-2014 11:28 AM
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
01-19-2014 11:38 AM
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
01-19-2014 12:01 PM
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
01-19-2014 12:31 PM
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.
01-19-2014 12:52 PM
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
01-19-2014 01:10 PM
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
01-19-2014 01:25 PM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide