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:
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