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>
