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>
