BGP peer-policy Template

[fsebera]

We are switching to template configuration but have run into an issue.

Sample template on IOS XE 03.16.09:

router bgp 1

 template peer-policy ROUTE-REFLECTOR

 remote-as 1

 allowas-in 2

 send-community both

After setting up each neighbor (about 80 neighbors) with the inherit peer-policy ROUTE-REFLECTOR the template end result is each neighbor is then configured with send-community extended.  I'm able to then modify each neighbor statement with send-community both but was expecting the template solution would function more consistently for all available options.  If I remove the send-community both from each neighbor statement,  the template automatically reverts back to send-community extended per neighbor.

Any help would be greatly appreciated!!

Thanks

Frank

[paul driver]

Hello

Try clearing the attribute first then apply it as a single statement outside the peer-policy towards the specific peer

router bgp 1
no neighbor x.x.x.x send-community both
no neighbor x.x.x.x send-community standard
neighbor x.x.x.x send-community extended
exit

clear ip bgp * soft out

[fsebera]

send-community both should be automatically applied to each neighbor -as per the template - but for some strange reason (Cisco IOS-XE BUG) send-community extended is applied. As stated I can manually apply the correct attributes but then what is the template doing. Strange.

[paul driver]

Hello

---

@fsebera wrote:

send-community both should be automatically applied to each neighbor -as per the template - but for some strange reason (Cisco IOS-XE BUG) send-community extended is applied. As stated I can manually apply the correct attributes but then what is the template doing. Strange.

---

Learning towards that your peer-policy is just sending extended attributes and possibly due to your bgp neighbors capability to accept them?

Are these ebgp or ibgp peerings as my understanding is both standard/extended are sent as default with ibgp peerings in ios-xe/r  software

[fsebera]

We are sending and receiving standard and extended communities as we are running MPLS multi-as backbone.

This setup is based on an operational production global environment. 

Thanks

Frank

[Giuseppe Larosa]

Hello Frank,

in which address-family are all these neighbors activated ?

IOS XE may provide send community extended as default option in AF VPNv4 as suggested by Paul.

I agree with you that you should be able to inherit the desired command.

What if you try to use an old fashioned peer-group that might be multi AF capable?

Hope to help

Giuseppe

[fsebera]

CONFIGURATION

router bgp 1

 template peer-policy ROUTE-REFLECTOR

   route-reflector-client

   allowas-in 2

   send-community both

exit-peer-policy

!

 template peer-session ROUTE-REFLECTOR

   remote-as 1

   update-source loopback1

exit-peer-session

!

bgp router-id x.x.x.x

 neighbor 1.2.3.4 inherit peer-session ROUTE-REFLECTOR

 !

 address-family ipv4

 exit-address-family

 !

 address-family vpnv4

  neighbor 1.2.3.4 activate

  neighbor 1.2.3.4 inherit peer-policy ROUTE-REFLECTOR

The results:

--snip--

neighbor 1.2.3.4 inherit peer-session ROUTE-REFLECTOR

 !

 address-family ipv4

 exit-address-family

 !

 address-family vpnv4

  neighbor 1.2.3.4 activate

  neighbor 1.2.3.4 send-community extended

  neighbor 1.2.3.4 inherit peer-policy ROUTE-REFLECTOR

I have tested this on the Cisco ASR1006 as-well-as CSR100v, same faulty results.

[paul driver]

Hello

Just querying when you have appended these templates have you manually soft reset the sessions?

clear ip bgp * soft
clear ip bgp * vpnv4 unicast soft

[fsebera]

sadly, clearing BGP soft or hard or reloading the router does nothing.

[fsebera]

FYI

Directly from our Cisco rep

I did some research on the BGP template configuration. I figured it was something we must have seen before. Back in 2011 someone brought this up to the Cisco team saying they “send-community both” in a template gets overwritten by the default. The Business Unit did an analysis and determined they were not going to fix it. Their reasoning is the change was more problematic than the workaround. The error checking that had to occur for the addition and then removal of the command wasn’t minimal from their perspective. It looks like we will need to add the line, per neighbor, in our configurations.

The bug id is - CSCtr76448    

[Giuseppe Larosa]

Hello Frank,

thanks for your feedback

It is an implementation choice that they decided not to change.

Best Regards

Giuseppe