VRF Route Leaking Question

[donniedarko84]

Hi All,

I have a design question for the community.

I have several customers...call them C1, C2, C3 and C4.

The requirement is that they will each need to leak routes to each other.

For example, C1 will need to leak a route to C2....C4 will possibly leak routes to C2,C1 and C3...ect...ect...ect...

My design question is how to do this in a scalable way?...

Each customer will have their own VRF....run a dynamic routing protocol (in this case BGP)...and if possible, be able to leak these routes to the other customers transparently (ie. without involvement from the SP).

I'm currently looking at a way by using BGP community strings....having each string match a route-map tied to an export map on the PE end.  So if C1 advertises a route (10.1.1.0/24) and sends a community string of 400...that means it will go into C4s VRF...this is done with an export map tied into C1s VRF.

My experience with this has been lukewarm...mostly because of the route-map tied to the export map.

I wanted to do something like this....

route-map Customer1-ExportMap seq 10 permit

match community C2-Community

set extcommunity rt AS:200 addittive

route-map Customer1-ExportMap seq 10 permit

match community C3-Community

set extcommunity rt AS:300 addittive

ect...

But...this seems to be over doing it.  Is their a simplier way?

[Giuseppe Larosa]

Hello Donnie,

this is the best way to do this:

customers can set a BGP community values on IP prefixes sent to SP PE nodes signalling  the prefix should be exported to others.

SP has export-maps in place to do this

What you build in this way is a flexible extranet, where each customer can decide what subset of routes are made "public" to others and what is to be kept private.

The advantage of this solution is that if a customer needs to make a change it can do it with no changed on SP side.

to complete the solution each VRF should also import the specific RT extended community set in export maps

you can start to have problems if you need multiple extranets in this case an RT value per extranet is needed.

Hope to help

Giuseppe

[donniedarko84]

Hi Giuseppe,

Thanks for the reply.  I'm glad I was on the right track with my thoughts above.

I'm finding some difficulty in how the route-map, which later would be tied into the export map, would be configured...

If Customer1 is sending an IP prefix...10.1.1.0/24....and they want only Customer2 to have access to it...no problem.

However, what if they now want Customer3 to have access to it aswell?

Customer Configuration

-------------------------------------

route-map SET_COMM seq 10 permit

match ip address WAN_ROUTE_1

set community 200

PE Configuration

-------------------------

ip community C2-Community 200

ip community C3-Community 300

route-map Customer1-ExportMap seq 10 permit

match community C2-Community

set extcommunity rt AS:200 addittive

route-map Customer1-ExportMap seq 20 permit

match community C3-Community

set extcommunity rt AS:300 addittive

What I'm seeing here is that as soon as sequence 10 is matched the route is exported, but it will not hit sequence 20 and export the route into the VRF of C3.  I think I'm correct in stating that this is the general loginc behind route-maps.

Is their another way I'm supposed to be building my route-maps?  I've seen alot of examples, but they are only for VRF-to-VRF...I haven't seen any where its one VRF exporting into three or four VRFs.

[Giuseppe Larosa]

Hello Donnie,

yes I see the point, the route-map like an ACL exits at first match as you have noted.

You need to plan for extranets using an appropriate RT target value for each of them using values that are different from those used in each single VRF

so

AS:3030 means extranet for  customers

AS:3031 means extranet 2 used by cust3, cust5, cust9

this is a point

Then to make a prefix member of multiple extranets

you need to change the route-map set action in:

set extcommunity rt AS:3030 AS:3031 additive

each time you need to do a change and unfortunately this is not plug and play anymore

there is a route-map directive called continue that could be of help too

http://www.cisco.com/en/US/docs/ios/iproute_bgp/command/reference/irg_bgp2.html#wp1071337

this would allow to implement something more adaptive but it should be tested

in this case the customer should export the prefix with multiple BGP communities and you have a route-map that will add an RT if the community-list used in block N is matched

so it would become

route-map Customer1-ExportMap seq 10 permit

match community C2-Community

set extcommunity rt AS:200 additive

continue

route-map Customer1-ExportMap seq 20 permit

match community C3-Community

set extcommunity rt AS:300 additive

Hope to help

Giuseppe

[jcartier]

Hi Giuseppe,

I was toying around with the 'continue' command within the route-maps earlier...still having the same issue.

On the Customer1 gear I have a route-map that is matching different ACLs.  Those ACLs are the routes Customer1 wants to share with the others.  I have set commands that attach a specific community string that is meaningful to upstream PE.

The problem is the 2nd community string doesn't seem to be getting attached...so the route is never exported to the next Customer.

I have confirmed this by looking at the attached community strings on the PE that is recieving the route.

I have something like this configured on the Customer

ip access-list standard Share-to-C2

permit 192.168.1.2

ip access-list standard Share-to-C3

permit 192.168.1.2

permit 192.168.1.3

route-map WAN_Community_OUT permit seq 10

match ip address Share-to-C2

continue

set community 200

route-map WAN_Community_OUT permit seq 20

match ip address Share-to-C3

continue

set community 300

When I look at the route recieved by the PE it only contains the community string matching '200' for the 192.168.1.2 route...the route that should be shared to C2 and C3.

Bug? lol.

[royalblues]

Try using the additive keyword on the second route-map

Narayan

[jcartier]

I'm running into the same scenario.  No luck.

[donniedarko84]

Hi Royal,

Tried it, no luck...