BGP communities attached to prefix issue

[Javor Kliachev]

Hello,

We use BIRD as route server with the well-known "BGP Community policy 
based filtering" as in most of all other IXP with the following type:

  * /Do not announce a prefix to a certain peer: 0:peer-as/
  * /Announce a prefix to a certain peer: IXP_AS:peer-as/
  * /Do not announce a prefix to any peer: 0:IXP_AS/
  * /Announce a prefix to all peers: IXP_AS:IXP_AS/

But recently we came across the following case:

A member of our IXP is sending his prefixes with attached a huge count 
of BGP communities ( ~ 750 pcs )

Each of the attached community has following type: 0:ASN ( peer-as ).

We see that BIRD accepts these prefixes from member but it return the 
following error notification:

2016-06-30 10:06:59 <ERR> R0_248: Attribute list too long, skipping 
corresponding routes
2016-06-30 10:06:59 <ERR> R0_248: - route *x.x.x.0/24* skipped

In the same time I'm able to see the prefixes that are exported fine to 
all member RIBs(for which there is no prohibiting with 0:ASN) via pipes
but in spite of that , the prefix is not advertised to any peer over 
eBGP protocol.

In addition at the same time I'm able to see that the prefixes persist 
into the RIB and BIRD shows that they're advertised but obviously this 
is not a true.

Here is the output with a brief explanation of our scenario:*

*R0_248**- protocol BGP of member that should accept the prefixes
R0_132 - protocol BGP of the member that sends the prefixes with the 
huge count of communities.
10.0.0.132 - the peer from protocol R0_132
T60230 - connected table to R0_248
Prefix: *x.x.x.0/24* - prefix with ~750 communities.

/# birdc "show route export R0_248 //*x.x.x.0/24*//all"/
*x.x.x.0/24*     via 10.0.0.132 on eth0 [R0_132 10:01:33] * (100) [ASxxxxi]
     Type: BGP unicast univ
     BGP.origin: IGP
/BGP.as_path: yyyy xxxx/
     BGP.next_hop: 10.0.0.132
     BGP.med: 1000
     BGP.local_pref: 100
     BGP.community: (64700,44217) (1,1082) (65400,65400) (65400,0) 
(0,42) (0,251) (0,286) (0,553) (0,680) (0,702) (0,714) (0,1239) (0,1241) 
(0,1248) (0,1267) (0,1273) (0,1547) (0,1668) (0,1680) (0,1764) (0,2119) 
(0,2484) (0,2603) (0,2613) (0,2635) (0,2686) (0,2818) (0,2828) (0,2854) 
(0,2857) (0,2906) (0,2914) (0,3209) (0,3216) (0,3223) (0,3225) (0,3252) 
(0,3255) (0,3257) (0,3292) (0,3303) (0,3320) (0,3327) (0,3356) (0,3491) 
(0,3549) (0,3561) (0,3741) (0,3786) (0,3856) (0,3910) (0,4134)
......................................................................
......................................................................
......................................................................
         (0,4589) (0,4637) (0,4651) (0,4657) (0,4766) (0,4788) (0,4809) 
(0,5089) (0,5391) (0,5400) (0,5404) (0,5409) (0,5410) (0,5413) (0,5430) 
(0,5466) (0,5483) (0,5539) (0,5563) (0,5578) (0,5588) (0,5603) (0,5605) 
(0,5713) (0,6083)
         (0,60280) (0,60294) (0,60404) (0,60447) (0,60764) (0,60868) 
(0,61186) (0,61244) (0,61266) (0,61317) (0,61438) (0,61955) (0,62023) 
(0,62044) (0,62093) (0,62325) (0,62336) (0,62363) (0,62955) (0,63199) 
(0,63311) (0,63949) (0,64597) (44217,1039) (44217,1049) (44217,1053) 
(44217,1064) (44217,1074) (44217,9101)

# birdc "show route table T60230 /*x.x.x.0/24*/"
/*x.x.x.0/24*/     via 10.0.0.132 on eth0 [R0_132 10:01:33] * (100) 
[ASxxxxi]

Our BIRD version is 1.4.5 We have tried with the latest 1.6.0 but there 
is no effect.

Furthermore during our troubleshooting as a separate issue we have 
observed that we can't add more than ~505 communities to a given prefix.

I hope this information will be useful for resolving this issue.

Any ideas or thoughts are highly appreciated!

Thanks in advance!
-- 


    Javor Kliachev


        Senior IP Engineer

tel: +359 2 975 16 16; fax: +359 2 975 34 36; mob: +359 885 988 495; 
web: www.neterra.net
<https://bg.linkedin.com/pub/javor-kliachev/11/b46/843>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20160630/31db8760/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 387 bytes
Desc: not available
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20160630/31db8760/attachment.png>