Import map

Unanswered Question
Oct 21st, 2007

Is it possible to use set commands in route maps used with an import map for a VRF ?

for example

ip vrf a

rd 100:1

route-target both 100:1

import map test

route-map test

match extndcommunity 100:1

set local preference 300

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4 (1 ratings)
etienne.basset Mon, 10/22/2007 - 04:54


yes it is possible

yet import-map will apply on your PE *only if the RD from routes received from mpbgp is different from your locally configured RD*.


rakesh.hegde Mon, 10/22/2007 - 05:55


Thanks for the info. I am not sure about the restriction on rd though, because I have seen import maps work just fine where the vrf on the router had the same rd as the update . The only thing I haven't been able to do is changing attributes(eg. local preference) before placing the routes in the bgp table for that vrf.


swaroop.potdar Mon, 10/22/2007 - 10:48

The VRF table is in between the MPBGP and PE-CE protocol, if you want to change BGP atributes, you will have to apply the route-map on the VPNv4 AFI against the neighbor you want this recived routes to be modified.

For example between PE1 and PE2 you will have to apply the route-map matching the required RT and changing the local pref when receiving the route from PE2 before installing that route in the VRF routing table locally.



rakesh.hegde Mon, 10/22/2007 - 12:12

Hi Swaroop,

I understand that we can do it by applying a rotue map under vpnv4 address space . With this we need to take into account all MPBGP updates for all customers (route targets) being sent and received between two neighbors. It would be really nice if we can change attributes inside a vrf using import map because in this case you are just doing it for one customer (vrf) and you dont have to worry about all other route targets.

Since we can match updates based on Ip address,ext communities and standard communities, I was wondering if we can get use set statements as well...

Thanks in advance


swaroop.potdar Mon, 10/22/2007 - 13:50

Hi Rakesh,

Unfortunately can we modify a routing table without modifying the BGP table itself.

Its just like that the difference between the RIB and the FIB. VRF table is a forwarding table derived from the BGP RIB after MPBGP has run its path slection based on the received attributes. After the path selection is done the route is placed in the FIB (vrf table).

So untill and unless there is a MPBGP AFI to IPv4 AFI attach point introduced in the software, i cannot think of a place where you can apply route-map to change the local preference except the VPNv4 AFI.

So defintately its not possible in the VRF import map except the VPNv4 route-map.

as a better option you can modfiy the local preference

at the point of injection rather than receipt. But to do the same on receipt for a BGP attribute you can do it only on the Vpnv4 Afi.

Also one more important reason I would like to understand is, why do you want to change the local pref at the receiving side, hows your logical topology, do you have 2 routes to a destination or something?



rakesh.hegde Mon, 10/22/2007 - 14:20


What you are saying makes sense but I still have a question though. When a PE receives a VPNV4 update, it goes through all the vrfs configued on that router and imports that route into the BGP table of any vrf thats got the import statement with a route target matching the update. We know that we can control what subnets get imported int to the BGP table by using the import table. So, if I use a set switch in the route map , I am theoretically matching a prefix and changing the attibute before putting that prefx in the BGP table right ? I am more than happy to let BGP make the routing decision after that based on what it has in its BGP table.

Am I missing something ?

BTW, I am trying to come up with a way to configre PEs to choose exit points (default route) to the internet based on their location (SOO) . PEs are receiveing default routes from multiple internet PES

Thanks again


swaroop.potdar Mon, 10/22/2007 - 21:21

Since you are wanting to do this for injecting multiple defaults into the BGP RIB and one preferred default into the FIB, you would be using different RD.

Since you are using different RD, this rule shouldnt constrain you from manipulating the local pref with a import map in a VRF as Etienne pointed earlier. This would constrain you only if you have the same RD which was inferred from your earlier post.

You can export the default from the internet gateways using a unique RT and RD as well and set higher loca pref manually to the GW which is closest in a given region. Others would be acting as fallback.



rakesh.hegde Tue, 10/23/2007 - 11:05


Using different rds works great.

I guess , my question boils down to why we need different RDs to use set clauses in import map. I can use match clauses with same rds and it works fine.

This is what I got from Cisco. I think they are talking about what import maps can do with same RDs.

There are very limited things we can do with import and export map. basically they are only used for route filtering and cannot do much. What you are trying to do was brought up as DDTS CSCee53143 earlier but it junked stating the limitation mentioned above.



swaroop.potdar Tue, 10/23/2007 - 11:59

If you get in and look at it logically, you will see that the same previous constraints of RIB and FIB should have been applicable in this case as well. But somehow its not, call it a feature or a bug, this more of looks like a feature request being incorporated into IOS trains.

As logically a it shouldnt have been possible to manipulate the BGP table through a routing table.

But its there, though using a different RD. So only answer to the question why its possible with different RD and not same RD

( I personally feel it should not have been possible at all) is probably it must have been a feature request.

As a benchmark to compare if you have access to an XR gear try applying RPL at import attach point on a vrf and it would

error giving the same constraint of RIB/FIB.

Just my opinion :-)



rakesh.hegde Tue, 10/23/2007 - 12:08

I agree . We are moving towards implementing RRs in our cloud so we need separate RDs anyway. Thanks for all your help



This Discussion