BGP - set clauses are ignored on reflected routes

Network:

R4,R5,R6 have serial interfaces connected to Frame cloud 172.14.45.0/24
R3,R4,R5 have LAN interfaces connected to 172.12.34.0/24

R6 has EBGP peering with R5 and R4, however R5 has R6 neighbor shutdown for now.
R4 is connected to R5 via IBGP.
R5 then connects to R3 via IBGP.
R5 has R3 configured as a route-reflector client.
R5 reflects routes learned from R4 to R3.
R5 has the following config:

router bgp 345
bgp cluster-id 5
neighbor 3.3.3.3 remote-as 345
neighbor 3.3.3.3 update-source Loopback0
!
address-family ipv4
neighbor 3.3.3.3 activate
neighbor 3.3.3.3 send-community
neighbor 3.3.3.3 route-reflector-client
neighbor 3.3.3.3 route-map SET out
!
ip prefix-list SIX seq 5 permit 6.0.0.0/24
!
route-map LOOPBACK permit 10
match ip address 5
!
route-map SET permit 10
match ip address prefix-list SIX
set community 500
!
route-map SET permit 20
!

The community does not show up on R3:

R3#show ip bgp 6.0.0.0
BGP routing table entry for 6.0.0.0/24, version 9
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Not advertised to any peer
65000
4.4.4.4 (metric 2) from 5.5.5.5 (5.5.5.5)
Origin IGP, metric 0, localpref 100, valid, internal, best
Originator: 4.4.4.4, Cluster list: 0.0.0.5

Now let's peer R5 directly with R6 and see what happens:

R5(config)#router bgp 345
R5(config-router)#neighbor 4.4.4.4 shutdown
R5(config-router)#no neighbor 172.14.45.6 shutdown

Immediately the community shows up on R3:

R3#show ip bgp 6.0.0.0
BGP routing table entry for 6.0.0.0/24, version 13
Paths: (1 available, no best path)
Flag: 0x820
Not advertised to any peer
65000
172.14.45.6 (inaccessible) from 5.5.5.5 (5.5.5.5)
Origin IGP, metric 200, localpref 100, valid, internal
Community: 500

I got this info while browsing the DocCD:

Configuring a Route Reflector

"The use of set clauses in outbound route maps can modify attributes and possibly create routing loops. To avoid this behavior, set clauses of outbound route maps are ignored for routes reflected to iBGP peers."

BGP - expanded community-lists

BGP expanded community-lists are more flexible than their standard counterparts because they can match on regexp instead of just a community string. Here you can see the differences:

R4(config)#ip community-list standard STANDARD permit ?
<1-4294967295> community number
aa:nn community number
internet Internet (well-known community)
local-AS Do not send outside local AS (well-known community)
no-advertise Do not advertise to any peer (well-known community)
no-export Do not export to next AS (well-known community)

R4(config)#ip community-list expanded EXPANDED permit ?
LINE An ordered list as a regular-expression

Now for a little lab. R1 and R2 are both going to EBGP peer with R4. R4 will then EBGP peer with R3. R1 and R2 will each send routes with different community strings to R4, along with routes without a community. We will use an expanded list to match certain community values. Hopefully, we can get it done with one permit statement.

R1 has 4 loopback networks:
1.0.0.0/24
1.0.1.0/24
1.0.2.0/24
1.0.3.0/24

R2 has 4 loopback networks:
2.0.0.0/24
2.0.1.0/24
2.0.2.0/24
2.0.3.0/24

R1 is sending community 100 with its first two loopbacks
R2 is sending community 200 with its first two loopbacks
The other loopbacks do not have a community attached.
Here is how we do it on R1, R2 is similar:

R1(config)#ip prefix-list LOOP1 permit 1.0.0.0/24
R1(config)#ip prefix-list LOOP1 permit 1.0.1.0/24
R1(config)#route-map setcom
R1(config-route-map)#match ip address prefix LOOP1
R1(config-route-map)#set commu 100
R1(config-route-map)#exit
R1(config)#route-map setcom perm 20
R1(config-route-map)#exit
R1(config)#router bgp 65000
R1(config-router)#neighbor 172.12.14.4 send-community
R1(config-router)#neighbor 172.12.14.4 route-map setcom out

Verify on R4 (this shows R4 is receiving all loopbacks)

R4#sho ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0/24 172.12.14.1 0 0 65000 i
*> 1.0.1.0/24 172.12.14.1 0 0 65000 i
*> 1.0.2.0/24 172.12.14.1 0 0 65000 i
*> 1.0.3.0/24 172.12.14.1 0 0 65000 i
*> 2.0.0.0/24 172.12.24.2 0 0 65000 i
*> 2.0.1.0/24 172.12.24.2 0 0 65000 i
*> 2.0.2.0/24 172.12.24.2 0 0 65000 i
*> 2.0.3.0/24 172.12.24.2 0 0 65000 i

Here are the loopbacks with community attributes:

R4#show ip bgp community 100 | begin Net
Network Next Hop Metric LocPrf Weight Path
* 1.0.0.0/24 172.12.14.1 0 0 65000 i
* 1.0.1.0/24 172.12.14.1 0 0 65000 i
R4#show ip bgp community 200 | begin Net
Network Next Hop Metric LocPrf Weight Path
* 2.0.0.0/24 172.12.24.2 0 0 65000 i
* 2.0.1.0/24 172.12.24.2 0 0 65000 i

Here is R3:

R3#show ip bgp

Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0/24 172.12.34.4 0 400 65000 i
*> 1.0.1.0/24 172.12.34.4 0 400 65000 i
*> 1.0.2.0/24 172.12.34.4 0 400 65000 i
*> 1.0.3.0/24 172.12.34.4 0 400 65000 i
*> 2.0.0.0/24 172.12.34.4 0 400 65000 i
*> 2.0.1.0/24 172.12.34.4 0 400 65000 i
*> 2.0.2.0/24 172.12.34.4 0 400 65000 i
*> 2.0.3.0/24 172.12.34.4 0 400 65000 i

Now we will configure R4 to send only routes with community 100 or 200 to R3:

R4(config)#ip community-list expanded EXPANDED permit [1-2]00
R4(config)#route-map filtercom
R4(config-route-map)#match community ?
<1-99> Community-list number (standard)
<100-500> Community-list number (expanded)
WORD Community-list name
R4(config-route-map)#match community EXPANDED
R4(config-route-map)#exit
R4(config)#router bgp 400
R4(config-router)#neighbor 172.12.34.3 route-map filtercom out

Let's check on R3:

R3#show ip bgp
BGP table version is 66, local router ID is 3.3.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0/24 172.12.34.4 0 400 65000 i
*> 1.0.1.0/24 172.12.34.4 0 400 65000 i
*> 2.0.0.0/24 172.12.34.4 0 400 65000 i
*> 2.0.1.0/24 172.12.34.4 0 400 65000 i

In this example the regexp string [1-2]00 matched either 100 or 200 an only allowed these routes through to R3.

BGP no-export community

This is gonna be short and hopefully sweet. I'll leave some blanks in here so you can fill in the rest...

R4 (AS3) connects to R1 via EBGP
R1 connects to R2 via IBGP (AS 2)
R2 connects to R5 (AS1) via EBGP

We don't want AS2 to become a transit AS between R4 and R5 so we can use the no-export community to accomplish this. There are several ways to do is but here is a way with using the as-path access-lists. AS-path access-lists are awesome because they use regexp.

So on R1 we create an AS-path access list to match any routes originating in R4 AS:

ip as-path access-list 1 permit _3$

Then we create a route-map and apply it to the R2 neighbor going outbound:

route-map noexport permit 10
match as-path 1
set community no-export

route-map noexport permit 20

router bgp 2
neighbor 155.1.23.2 send-community
neighbor 155.1.23.2 route-map noexport out

Now on R2 we have this:

R2#show ip bgp 204.12.1.0 | inc Community
Community: no-export

R5 does not have the route!

R5#show ip bgp 204.12.1.0
% Network not in table
R5#

You can do the reverse on R2 to accomplish the two way restriction. Also note that R4 can bypass this by prepending an AS# to its routes! A better way would be to add the no-export community to all routes learned from R4 not just the ones originating in R4's AS. But I just wanted to see the flexibility of route-maps and as-path access lists with communities.