Attention: The Cisco Support Community site will be in read only mode on Dec14, 2017 from 12:01am PST to 11:30am for standard maintenance. Sorry for the inconvenience.
I have a requirement of an extranet solution (ASP model) where many customer will be connected to a central site. The spoke sites do not talk to each other, not even through the central site. One option is to use 1 VRF at the central site and import routes from all other spokes sites (different RD and RT at the spopke sites). This has been rules out. so now my other alternative is to use multiple vrf on a single access link (ethernet in this case) between the CE and PE. I was thinking of using vrf-lite at the central site, but few concepts I am not clear about.
1) can i get away without using vrf-lite on the central site. PE configures individual vrf for each 1.q interface, but CE just uses 1.q without any vrf. For start I am going to have only two/three sites, so I can either map the subinterface to a separate LAN port or i could do .1q on a single LAN int and map it to the WAN subinterface. Maybe this is not the best solution,but I do not want to go for an unnecessary solution.
2) what are the advantages and disadvantages of using vrf-lite vs no vrf (if it is possible) in this scenario.
Attached is a diagram.
Main advantage to using vrf-lite is that each customer has it's own completely separate routing table within the same device which really extends your VPN's back into your LAN.
You can use access-lists/PBR etc. to achieve a similiar level of segregation and sometimes it's easier to do that depending on how many customers you need to keep separate.
I also think it's easier to make a mistake with access-lists/PBR approach and all the customer routes are in the same table.
Thanks. I agree with you on the completely separate routing table to the LAN when using vrf-lite. And in my case there is a growth potential to many more customers/sites. So I think I will go with vrf-lite.
I will probably have some configuration questions/clarifications later when I do some reading. I will be using BGP between CE and PE so will pick this up later.
Hi, I hate to hijack someone else's thread but I haven't received a response on my question that I had posed a couple days ago. I am thinking of a similar setup as Rana's however I am using a firewall between my outside edge device which will host all the VRF's and the inside device which preferably should not have any vrf's. I am wondering if this setup is possible.
I will be using BGP (IPv4 BGP) between the external and the internal device.
The link to the firwall will be a L3 link from both sides. So the external device will have a L3 link to the firewall. The internal device will have a L3 link to the firewall.
I want to bring every customer in on its own vrf on the external device and than export all the routes from each vrf into the global BGP process. Is that possible and more importantly is that feasible? Thx for your help.
I am back with some reading on vrf lite. I am pasting a sample configure that I picked up from another post. I noticed that there is no 'network' statement or 'redistribute static'. My questions:
1) If I am running BGP with PE, what is the normal pratice to advertise my routers per vrf?
2) In the LAN do I run separate OSPF or EIGRP instances per VRF (per subinterface)? what is the best way?
3) If I have static route to other LAN routers then I will be using 'redistribute static' right? Do I have to be specific about which static route I should redistribute to that vrf. If not how does the router know which static route to redistribute to which vrf.
I have attached a diagram. The below sample does not map to my diagram.
interface serial0/0/0.1 point-to-point
ip vrf forwarding A
ip address x.x.x.x x.x.x.x
frame-relay interface-dlci 100
interface serial0/0/0.2 point-to-point
ip vrf forwarding B
ip address y.y.y.y y.y.y.y
frame-relay interface-dlci 101
And So on for further interfaces.
router bgp 1
address-family ipv4 vrf A
neighbor x.x.x.x remote-as x
address-family ipv4 vrf B
neighbor y.y.y.y remote-as y
As long as we all can share/learn/solve problems, it is perfectly fine. I don't think I qualify to give you any advise but here is what I have found in another post that might be of interest to you.
In your post you mentioned that you do not think you can run MP-BGP between the two switch through the FW. In another post I had got an indication that you can run LDP between two PE's using GRE tunnel. In your scenario you are going throuhg a FW and in that particular post the PEs are separated by a third service provider. So if you are open to explore this might be a solution for you.
Hope this piece of information helps.
Apologies for the delay in replying.
Is the config above taken from a PE or CE device ?.
I'll try and answer your questions regardless
1) Do you mean where to advertise routes from CE to PE if you are running vrf-lite ?.
If so then you do this under your BGP config on the CE device eg.
router bgp 1
address-family ipv4 vrf A
neighbor 22.214.171.124 remote as 2
neighbor 126.96.36.199 activate
network 10.10.10.0 mask 255.255.255.0
2) I have only done this with EIGRP. With EIGRP you can use the "address-family ipv4 vrf
3) You do need to specific about which vrf to use with static routes. The command is
"ip route vrf
Please come back if i haven't covered all your questions
Also you can use only one VRF at the central site , and export only the Central site IP prefix to the spokes VRF's, so now the sokpes have only one route to reach, which is the Central site route and all spokes can not communicate with each otheres due to incomplete routing informations.
OK, but this will save some memory for you from the Central side, as you do't need to create seperated instance for each spoke, for me we used in in large solutions when one VRF need to manage a set of different VPN's, so we use it instead of VRF-Lite due to memory issues from the customer CE side.
I agree with you. And I too have used the method you mentioned for some customers. But for this case it has been decided to use multi-vrf. Thanks for the advise.