Preserve ext.communities learned from eBGP when advertising into iBGP

[deelystan]

I'm testing the following setup in an MPLS lab:

RTR-1-VRF-1 (ASN 65001) -> eBGP to firewall -> FW-1 (ASN 65002) -> eBGP from firewall -> RTR-1-VRF-2 (ASN 65001)
RTR-1-VRF-1 is setup to send extended communities to the firewall.
The firewall strips ASN 65001 so RTR-1-VRF-2 will accept the routes.
The firewall by default preserves the extended communities it receives from RTR-1-VRF-1.
When RTR-1-VRF-2 receives the route from the firewall, it looks like this:

RTR-1#show bgp vrf VRF-2 10.1.1.64/27
BGP routing table entry for 65001:101:10.1.1.64/27, version 7
Paths: (2 available, best #1, table VRF-2)
Advertised to update-groups:
45
Refresh Epoch 1
65002
10.2.2.10 (via vrf VRF-2) from 10.2.2.10 (10.2.2.10)
Origin IGP, metric 0, localpref 100, valid, external, best
Extended Community: RT:65001:101 RT:65001:102
mpls labels in/out 27124/nolabel
rx pathid: 0, tx pathid: 0x0
Refresh Epoch 1
65002, (received-only)
10.2.2.10 (via vrf VRF-2) from 10.2.2.10 (10.2.2.10)
Origin IGP, localpref 100, valid, external
Extended Community: RT:65001:90 RT:65001:301
mpls labels in/out 27124/nolabel
rx pathid: 0, tx pathid: 0

VRF is configured like this:

vrf definition VRF-2
rd 65001:101
route-target export 65001:101
route-target export 65001:102
route-target import 65001:101
route-target import 65001:103
!
address-family ipv4
exit-address-family

The problem is that the extended communities set by RTR-1-VRF-1 seems to be overwritten by the RTs in RTR-1-VRF-2 sometime after RTR-1-VRF-2 receives the route from the firewall.
The result is that I can't use the extended community set by RTR-1-VRF-1 for route-filtering in spoke VRFs of VRF-2 in the iBGP neighbors of RTR-1.

How can I make RTR-1-VRF-2 preserve the extended communities it receives from the firewall?
Using a route-map to set them again is not the right solution, as that would not scale very well.
We need BGP (or whatever process) to understand that the extended communities learned from an eBGP neighbor should be preserved when advertised to its iBGP neighbors.

[MHM Cisco World]

extend community as I know is same as RT you config under VRF. 
instead of use extend community use community for path. 
in Sender 
route-map MHM permit 10
set community xx:xx
in receiver 
route-map MHM permit 10
match ip community 1
!
ip community-list 1 permit xx:xx

[deelystan]

Thanks, I will try that.

I haven't played around with standard communities yet, is there anything I need to know?
I do know that they are 16-bit:16-bit, so for scalability purposes, both numbers on either side of the colon will need to be utilized.

For extended communities, I would just use our ASN before the colon, and then a 32-bit number after the colon.

Could anything hit us in the future if we use public ASNs in the first part of a standard community? Should we perhaps stick to the private range?

Any comments are appreciated.

[MHM Cisco World]

Yes same value you use in RT Ext-community in community.

[David Ruess]

Hello,

If there is a point where you are adding more communities once the route is received it will overwrite them. I know you mentioned not adding them in a new route map but if you already have one you can use the additive keyword.

route-map test permit 10

match ip address <#>

set community XXX additive

This will preserve any communities already configured and just add to it.

-David