08-09-2007 09:55 AM
Need to implement HUB and SPOKE topology while all customers are on same PE 10720, same VRF and same RD as directly connected. One directly connected site should act as HUB and all other sites are SPOKES and requirement is that SPOKES can not communicate with each other.
08-13-2007 07:54 AM
Hi,
you need to create a VRF per SPOKE and one for the Hub. Example config excerpt:
ip vrf Hub
rd 65000:1
route-target export 65000:1
route-target import 65000:2
ip vrf SPOKE1
rd 65000:101
route-target export 65000:2
route-target import 65000:1
ip vrf SPOKE2
rd 65000:102
route-target export 65000:2
route-target import 65000:1
interface Serial1/0
description to Hub
ip vrf forwarding Hub
ip address 10.1.1.1 255.255.255.252
interface Serial1/1
description to SPOKE1
ip vrf forwarding SPOKE1
ip address 10.1.101.1 255.255.255.252
interface Serial1/2
description to SPOKE2
ip vrf forwarding SPOKE2
ip address 10.1.102.1 255.255.255.252
You naming, IP addresses etc. may be different. The main point here is: no SPOKE will import any route from another SPOKE, only from the Hub site. Thus spokes do not get connectivity to each other. The hub site imports all spoke routes, thus can connect everywhere.
What is missing in the example above is the respective routing contexts for each VRF. You are free to choose appropriate protocols on a per VRF basis and redistribute them into MP-BGP.
Hope this helps! Please rate all posts.
Regards, Martin
08-14-2007 11:27 PM
Thanks Martin But we have to implement it in a single vrf .is their any way that we could have only a single vrf for all customers sites and that all sites can only communicate with hub site.and communication with each other should be forbidden i think u got my point.
08-14-2007 11:36 PM
Hi,
What is the reason for the single VRF requirement? A single VRF will act as a single router, i.e. interconnect all networks in the routing table by default. So the only option remaining, if a single VRF is not negotiable, is to use packet filters (ACLs). The example in my first post is offering a much more elegant way of achieving the requirements you stated so far, except the number of VRFs.
Regards, Martin
08-15-2007 01:08 AM
Thanx for ur previous post actually this is our client requirement that they want a single vrf for all client branches.and just that client branches can only talk to HUB branch.i have implemented it with ACL but it would be difficult to manage.Also in our design all the Client branches are coming on the single router that is 10720.So you can see if their are 700 branches then their would be 700 vrf`s.if u can tell a way or mpls has some sort of support that we could have only 1 vrf and we can control their routing to hub branch effiencitenly.your early reply would be highly appreciated.
08-15-2007 02:27 AM
Hello
there are 2 ways you can do this.
1. you dont need to use 700 vrf for all spoke locations . only 2 vrf will do. one for hub and other for spoke.
like
vrf hub
route target export hub
route target import spoke
vrf spoke
route target export spoke
route target import hub
2. in case you want it with only one vrf use the import map command and import the routes of hub location only.
HTH
regards
Ashish gupta
08-15-2007 02:39 AM
thanx gupta.i think it would be very clear if u illustrate both these with an example.
08-15-2007 03:49 AM
Hi,
one VRF as given in the example will not do, because the VRF RIB will interconnect all spokes.
Actually there is one scalable method for you, check out "Configuring Scalable Hub-and-Spoke MPLS VPNs"
http://www.cisco.com/en/US/products/ps6350/products_configuration_guide_chapter09186a0080442090.html
It uses one upstream VRF and one downstream VRF per interface (other interfaces than vts should be good as well). This should pretty much fulfill all your requirements. ONE VRF is impossible or needs ACLs - an operational nightmare.
Hope this helps! Please rate all posts.
Regards, Martin
08-15-2007 04:37 AM
Yes.I agree with martin.i have tried to worked it out with route import and export and it doesnot seems to work.bcoz of that VRF RIB.i will try the other method and then let u know that does that fulfill our requirement or not.Thanx for ur time.
08-15-2007 09:18 AM
Since the requirement puts in a lot of restrcitions you can although come up with a innovative solution out of the box, which is generally not recommended.
You can propose using GRE tunnels between the HUB n Spokes. When doing this the GRE tunnels is built using the VRF routing table, and only the upstream traffic to other spokes goes via the GRE tunnel and lands directly on the HUB, the downstream from the HUB to the other spokes always takes the VRF interface path via the PE.
Only benefit i see with this option over the ACL is the operational overheads being reduced as its only a one time implementation when you deploy the connectivity from CE-PE.
Although this is not the recommended way to implement Hub n spoke, but again considering the extreme restrictions, this works well.
HTH-Cheers,
Swaroop
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: