MPLS VPN VRF Import Map

This topic is to discuss the following lesson:

Hello,

I lab a big scenario with almost everything explained in MPLS section. There are two customer each one with two sites. So my intention was to test Import and export maps, and ĂŚ thought in this situation:

  • I wanted all routes from customer B site 1 to customer A site 2 be advertised and viceversa.
  • I wanted some connectivity between some routes (filtering with export maps) of customer A site 2 and customer B site 1

So my first failed attemp I tried this on R4

ip vrf AA
 rd 3:3
 export map PRUEBA
 route-target export 5:5
 route-target import 5:5
 route-target import 1:2
!
ip vrf BB
 rd 4:4
 route-target export 6:6
 route-target import 6:6
!
R4#sh route-map PRUEBA
route-map PRUEBA, permit, sequence 10
  Match clauses:
    ip address prefix-lists: OCHO
  Set clauses:
    extended community RT:2:1
  Policy routing matches: 0 packets, 0 bytes
R4#

but it was only exporting what the export map had, route-target export 5:5 was useless totally.

So I change to:

ip vrf AA
 rd 3:3
 export map EXPORTALL
 route-target import 5:5
 route-target import 1:2
!
ip vrf BB
 rd 4:4
 route-target export 6:6
 route-target import 6:6
!
route-map EXPORTALL, permit, sequence 5
  Match clauses:
    ip address prefix-lists: OCHO
  Set clauses:
    extended community RT:2:1 RT:5:5
  Policy routing matches: 0 packets, 0 bytes
route-map EXPORTALL, permit, sequence 10
  Match clauses:
  Set clauses:
    extended community RT:5:5
  Policy routing matches: 0 packets, 0 bytes

An it worked fine.

From R2, I found that both importmap and route-target statement are needed

ip vrf AA
 rd 1:1
 route-target export 5:5
 route-target import 5:5
!
ip vrf BB
 rd 2:2
 import map IMPORT
 route-target export 6:6
 route-target export 1:2
 route-target import 6:6
 route-target import 2:1
!
route-map IMPORT, permit, sequence 10
  Match clauses:
    ip address prefix-lists: OCHO2
    extcommunity (extcommunity-list filter):AA
  Set clauses:
  Policy routing matches: 0 packets, 0 bytes
route-map IMPORT, permit, sequence 20
  Match clauses:
    extcommunity (extcommunity-list filter):BB
  Set clauses:
  Policy routing matches: 0 packets, 0 bytes
route-map IMPORT, deny, sequence 30
  Match clauses:
  Set clauses:
  Policy routing matches: 0 packets, 0 bytes
R2#

For me my conclusion, correct me if I am wrong is that:

  • In export-map, when you used it, it make other route-target in configuration statement useless.
  • In import-maps both the import map and the route target are needed to work properly.
    Is there any other way to make this simplier? because I think there is no scalability in adding RT labels more and more.

Hello Ignacio,

In export-map, when you used it, it make other route-target in configuration statement useless.

That sounds correct, I noticed the same behavior in my MPLS VPN export map example.

In import-maps both the import map and the route target are needed to work properly.

That sounds right too. Even with the import-map, you still see the VPN routes. The import map influences the VPN routes you import into the VRF.

Is there any other way to make this simpler? because I think there is no scalability in adding RT labels more and more.

Hmm I don’t think there is but you probably could do most of the work with the export-maps and regular route-target import commands. For simple sites where you don’t differentiate between the prefixes, you can use a single RT to export everything. Another site can import everything with a single RT.

For sites with multiple prefixes and you want to define who gets to import these prefixes, you must use an export-map to set different RTs per prefix. You can import them with the regular route-target import command.

Rene

1 Like

Hello,

Really interesting topics i’ve been through recently regarding an internet infrastructure/vpn. We had issue during operation in which our PE didn’t import the prefix with let say local pref defined. This operation was made to improve flow repartition (outbound) from multiple datacenter.
As we didn’t understand what was happening a first place, we decided to rollback. Then I reproduced the whole infrastructure and figured out that there was (don’t know exactly why) but multiple PE with same RD for this specific VPN (internet). When I wanted to manipulate metrics from a specific route, my metric was not applying and I noticed the default one(100 for localpref).
I then labbed multiple case with basic mpls backbone and when trying specific manipulation, having different RD on each PE is recommended I guess.
I was not able to produce debug logs attached for explaining exactly why but I’d say as vpnv4 update, the device is already considering the route by his own and then my import wap was never matching at all.

Cisco documentation is not so clear about import map/export map in my opinion

Yoann

Hello Yoann

Thanks for sharing your experience and the procedure you followed to investigate further. It’s always a good idea to troubleshoot by reproducing your topology in a lab environment. If you need any more specific help with your troubleshooting process on this or any other topic, please let us know!

Laz

Hi Laz,

  1. Is this possible that PE1 can have two same VPNv4 route? here same vpnv4
    route means ip prefix and RD will be the same, How?
  2. We can also do all thing with import map which we did during export map?

Hello Pradyumna

No, a VPNv4 route must be unique. This is what the RD does. It makes two customer prefixes that may be the same, unique. This can be clearly seen in section 1.2 of the MPLS Layer 3 VPN Configuration lesson.

Yes, the import and export map features, as described in the linked lessons perform the same functions, but in the “opposite direction” so to speak.

I hope this has been helpful!

Laz

Do we still need “route-target import” while using the “import map”

What I can see in your config that you are using both in the vrf config:

ip vrf CUSTOMER
 rd 1:1
 import map IMPORT_MAP
 route-target export 2:2
 route-target import 1:1
!

The route map is configured to import only the prefix 1.1.1.1/32 which as the route target 1:1 :

ip prefix-list CE1_L0 seq 5 permit 1.1.1.1/32
!
route-map IMPORT_MAP permit 10
 match ip address prefix-list CE1_L0
 match extcommunity CUSTOMER

And this seems to filter all the other routes.

But this config seems to go against your previous lesson on route-target export. In that case if you use both the “route-target export” with the “export map”. The prefixes not matching the export-map were getting assigned with the rt values configured with “route-target export” command.

Hello Muhammad

In the case of the export map, the configuration was a bit different. In that case, Rene actually modified the route-target on the route. In the Export Map with Prefix-list section of the lesson, he uses the same logic as in the import map lesson. However, because the RT was modified to 3:3, and because there was no route-target import 3:3 command, he had to add that in.

In the case of the import map in this lesson, the RT was not modified, and the route-target import 1:1 was already in the VRF config, so no additional commands were necessary.

I hope this has been helpful!

Laz