This topic is to discuss the following lesson:
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.
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.
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
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!
- 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?
- We can also do all thing with import map which we did during export map?
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.
I hope this has been helpful!
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 126.96.36.199/32 which as the route target 1:1 :
ip prefix-list CE1_L0 seq 5 permit 188.8.131.52/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.
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!