attribution

Mailman List Mirror (Read Only)
1

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.

so some idiot is barfing out a ridiculous as_path. dear lazynet, is
there an easy way to get attribution for this stupidity? i.e. the
as_path.

e.g. a nice query to ris or rv given the prefix, 103.148.41.0/24, and
the uct time, Apr 12 17:57:42.

randy

2

I’m using CAIDA’s bgpreader and this one looks like it might be an example of what you want.

R>R>1586714402.000000|routeviews|route-views.eqix|||2914|206.126.236.12|103.148.41.0/24|206.126.236.12|2914 58717 134371 134371 134371 134371 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076|140076|2914:410 2914:1405 2914:2406 2914:3400||

—Sandy

3

I’m using CAIDA’s bgpreader and this one looks like it might be an
example of what you want.

R>R>1586714402.000000|routeviews|route-views.eqix|||2914|206.126.236.12|103.148.41.0/24|206.126.236.12|2914 58717 134371 134371 134371 134371 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076|140076|2914:410 2914:1405 2914:2406 2914:3400||

aut-num: AS140076
as-name: MIS-AS-AP
descr: Mir Internet Service
country: BD
org: ORG-MIS3-AP
admin-c: MISA2-AP
tech-c: MISA2-AP
mnt-by: APNIC-HM
mnt-irt: IRT-MIS-BD
mnt-routes: MAINT-MIS-BD
mnt-lower: MAINT-MIS-BD
last-modified: 2020-01-31T06:35:38Z
source: APNIC

actually, an example of what none of us wants :slight_smile:

it seems a lot of folk think prepending acrually works.

thanks

4

Oh, it works ... just not for anything pragmatically useful.

5

In 2020, no less.

Can't recall the last time I used this feature, even if it's one we
offer for BGP communities we accept from customers.

Admittedly, I don't think of any of them use it.

Mark.

6

Well, according to your router’s error message, it did work…it ensured you couldn’t propagate that route update, thereby ensuring no traffic from your neighbors would traverse the prepended path.

Of course, it’s a bit of a degenerate case of “working”–but it did serve to shift traffic away. ^_^;;

Matt

7

I mean, there's prepending and then there's prepending 50+ times... Has the latter EVER been useful in any way, shape, or form?

8

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

(yes, any prepend past ~10 is arguably not worth the time)

9

Christopher Morrow
Sent: Tuesday, April 14, 2020 2:51 AM

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

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