Christopher Morrow Sent: Tuesday, April 14, 2020 2:51 AM
On Mon, Apr 13, 2020 at 7:38 PM Brandon Martin <lists.nanog@monmotha.net> wrote:
On 4/13/20 4:31 PM, Randy Bush wrote:
it seems a lot of folk think prepending acrually works.
I mean, there's prepending and then there's prepending 50+ times... Has the latter EVER been useful in any way, shape, or form?
for ~4 yrs or so there's been possible problems with as-paths longer than ~50 (I think, i can't recall the exact vendor bug) so, folk should have already been denying announcements with longer than ~soemthing-like-45 asn in the path.. right? :)
From memory this was one of the two accidents (someone prepending their AS 255 times and an university announcing special unheard-of attribute) that triggered the good work around RFC 7606 - Revised Error Handling for BGP UPDATE Messages. And why Randy and we all can enjoy messages like Apr 12 17:57:42 r0.iad rpd[1752]: Prefix Send failed ! 103.148.41.0/24 bgp_rt_trace_too_big_message:1209 path attribute too big. Cannot build update. Or RP/0/RSP0/CPU0:Jan 18 00:22:41.029 : bgp[1058]: %ROUTING-BGP-3-MALFORM_UPDATE : Malformed UPDATE message received from neighbor x.x.x.x (VRF: INTERNET) - message length 87 bytes, error flags 0x00400000, action taken "DiscardAttr". Error details: "Error 0x00400000, Field "Attr-unexpected", Attribute 128 (Flags 0xe0, Length 18), Data [e0801200]". NLRIs: [IPv4 Unicast] <<not gonna name and shame>> While our BGP sessions keep on working just fine and either the update is treated as withdraw or the attribute is deleted.
On the point of as-path length limit, Yes I know of at least one tier-1 that does it and since I left some 8 years back I do it everywhere I go. In addition to the above (best common practice, id' say) -on junos you can do community length limiting -and on cisco you can do attribute filtering -hence my question to this forum some time back about whether folks do filter all the "experiments" for the sake of running a successful business (paraphrasing...) adam