BGP communities attached to prefix issue
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>
On Thu, Jun 30, 2016 at 04:28:00PM +0300, Javor Kliachev wrote:
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
Hi By RFC 4271, BGP message is limited to 4 kB of length. BIRD internally limits attribute part of a transmitted message to 2 kB. This is equivalent of 1024 (4 kB) or 512 (2 kB) communities. You could replace constants 3072 [1] and 2048 [2] with say 3840 and 3584, that would allow 3.5 kB of attributes (~ 900 communities). [1] proto/bgp/packets.c:372 and proto/bgp/packets.c:465 [2] proto/bgp/packets.c:385 and proto/bgp/packets.c:481 Or, as these communities are destinated for your IXP, you could simply strip 0:* and IPX_AS:* communities before prefixes are forwarded to your clients. This is probably a good idea anyways as having too large attribute list may cause problems later. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
On Mon, Jul 04, 2016 at 12:02:59PM +0200, Ondrej Zajicek wrote:
By RFC 4271, BGP message is limited to 4 kB of length. BIRD internally limits attribute part of a transmitted message to 2 kB. This is equivalent of 1024 (4 kB) or 512 (2 kB) communities.
You could replace constants 3072 [1] and 2048 [2] with say 3840 and 3584, that would allow 3.5 kB of attributes (~ 900 communities).
[1] proto/bgp/packets.c:372 and proto/bgp/packets.c:465 [2] proto/bgp/packets.c:385 and proto/bgp/packets.c:481
Do you have https://tools.ietf.org/html/draft-ietf-idr-bgp-extended-messages-12 on your roadmap? This draft bumps the 4 kB limit to ~ 65 kB. Kind regards, Job
On Mon, Jul 04, 2016 at 12:15:18PM +0200, Job Snijders wrote:
On Mon, Jul 04, 2016 at 12:02:59PM +0200, Ondrej Zajicek wrote:
By RFC 4271, BGP message is limited to 4 kB of length. BIRD internally limits attribute part of a transmitted message to 2 kB. This is equivalent of 1024 (4 kB) or 512 (2 kB) communities.
You could replace constants 3072 [1] and 2048 [2] with say 3840 and 3584, that would allow 3.5 kB of attributes (~ 900 communities).
[1] proto/bgp/packets.c:372 and proto/bgp/packets.c:465 [2] proto/bgp/packets.c:385 and proto/bgp/packets.c:481
Do you have https://tools.ietf.org/html/draft-ietf-idr-bgp-extended-messages-12 on your roadmap? This draft bumps the 4 kB limit to ~ 65 kB.
It is already mostly [*] supported in 1.6.0, but it needs to be supported by both sides and does not solve this issue for route servers of IXPs unless everyone has the support. [*] well, it allows 64 kB messages but i forgot about the internal 2 kB limit for attributes, so it is currently not much useful. Will be fixed in the next version. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
participants (3)
-
Javor Kliachev -
Job Snijders -
Ondrej Zajicek