BGP Community on Inbound Routemaps

[Alex_Shpilman]

Hi CheckMates,

I have a BGP peering with Cisco N9K and need to add a community to routes received from the N9K.

This doesn't seem to work on with inbound routemap, but only outbound, tested with Maestro and non-Maestro and iBGP/eBGP, all with the same outcome.

Inbound routemap example:

set routemap lab id 10 on
set routemap lab id 10 allow
set routemap lab id 10 match community 1000 as 65000 on
set routemap lab id 10 match protocol bgp
set routemap lab id 10 action community 100 as 65099 on
set routemap lab id 10 action community append on
set routemap lab id 10 action localpref 400
set routemap lab id 10 action preference 500

The expectation is community 65099:100 to be added to the routes.

set bgp external remote-as 65000 import-routemap lab preference 10 on

show route bgp detailed
1_01:
Route: 10.101.0.0/24
Next Hop: 10.101.199.2, via bond1.1199
MED: None
Local Preference: 400
Age: 25691
Rank: 170
Weight: 500
AS Path: (65099),65000,Incomplete.(Id-8),comm-65000.1000
Local AS: 65099
Peer AS: 65000
Origin: Incomplete
Originator ID: 10.101.0.2
BGP Next Hop Attribute: 10.101.199.2
Communities: 65000:1000
Route: 10.101.198.0/24
Next Hop: 10.101.199.2, via bond1.1199
MED: None
Local Preference: 400
Age: 25691
Rank: 170
Weight: 500
AS Path: (65099),65000,Incomplete.(Id-8),comm-65000.1000
Local AS: 65099
Peer AS: 65000
Origin: Incomplete
Originator ID: 10.101.0.2
BGP Next Hop Attribute: 10.101.199.2
Communities: 65000:1000

With outbound routemaps, everything works the peer receives the community.

set routemap lab-out id 10 on
set routemap lab-out id 10 allow
set routemap lab-out id 10 match network 10.101.0.0/16 all
set routemap lab-out id 10 match network 10.102.0.0/16 all
set routemap lab-out id 10 match protocol direct
set routemap lab-out id 10 action community 200 as 65099 on

set bgp external remote-as 65000 export-routemap lab-out preference 10 on

show bgp peer 10.101.199.2 advertise
1_01:

IPv4 Route MED LocalPref Nexthop Communities
10.101.199.0/24 None N/A(EBGP) 10.101.199.254 65099:200
10.102.199.0/24 None N/A(EBGP) 10.101.199.254 65099:200

Any ideas? Am I missing something or is it a limitation?

Thanks in advance.

[PhoneBoy]

What version/JHF?

[Alex_Shpilman]

Hi @PhoneBoy 

I tried on several deployments, R81.20 JHF 41 (tried both Maestro and non-Maestro) and R81.10 JHF 109, all tests produced the same results.

Thanks

[Alex_Shpilman]

Enabled BGP trace all and got the below:

Feb 15 16:14:40.529306 [routed] WARNING: Task BGP_65000: Routemap lab (inst 10) Actions (Set Community List|Append To Community List) not supported during IMPORT by Protocol BGP.They will be ignored

So, it looks like a weird limitation ... 

[the_rock]

Last time I worked with TAC on this 2 years ago, they said it was not supported. Maybe its changed, you can ask them.

Best,

Andy

[Alex_Shpilman · Accepted solution]

Looks like still not supported, thanks @the_rock 

[the_rock]

No worries.

Best,

Andy

[Alex_Shpilman]

I will open an RFE through our local SE here in New Zealand.

[the_rock]

That sounds like a good idea.

Best,

Andy

[APopisteru]

R82: the limitation persists, trace says:

Task BGP_xxxxx: Routemap xxxxxx (inst 100) Actions (Set Community List|Append To Community List) not supported during IMPORT by Protocol BGP. They will be ignored

Will open a RFE too.

[KlowikiOne]

Appends in BGP for community are an export feature only.  

RFC 1997 describes 

   A BGP speaker may use this attribute to control which routing
   information it accepts, prefers or distributes to other neighbors.

   A BGP speaker receiving a route that does not have the COMMUNITIES
   path attribute may append this attribute to the route when
   propagating it to its peers.
Key word and phrase to understand. BGP Speaker is stating that the community will be spoken to others. Not listening to set the append.  "propagating it to its peers." Reinforcing that this attribute will be sent to the peers.

I hope this helps.  

[APopisteru]

I know that communities are optional attributes and we are implementing by the RFCs, but in large ISP networks (I found our interpretation of processing communities in such a network) it's a common practice to append ISP's communities to prefixes received by the customer (that may already have other communities as attributes), to have those prefixes imported in the routing tables for various policed exports based on appended communities. It's not a big deal and there are workarounds, but an ISP that has entire routing and forwarding infrastructure based on, let's say, Junipers, that implement the feature, might find cumbersome to accommodate our peculiarities. Usually I'm saying that it might be better to do dynamic routing through the firewall not with the firewall (remember gated?) .