MPLS L3 VPN

Unanswered Question
Aug 9th, 2007

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.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
mheusing Mon, 08/13/2007 - 07:54

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

kamranraza Tue, 08/14/2007 - 23:27

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.

mheusing Tue, 08/14/2007 - 23:36

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

kamranraza Wed, 08/15/2007 - 01:08

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.

colbedi Wed, 08/15/2007 - 02:27

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

kamranraza Wed, 08/15/2007 - 02:39

thanx gupta.i think it would be very clear if u illustrate both these with an example.

mheusing Wed, 08/15/2007 - 03:49

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

kamranraza Wed, 08/15/2007 - 04:37

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.

swaroop.potdar Wed, 08/15/2007 - 09:18

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

Actions

This Discussion