Claudio Jeker([email protected]) on 2018.05.30 15:18:45 +0200:
> Hi,
>
> This adds a protection to handle aspaths overly large attributes in bgpd.
> The main idea is to protect other bgp routes downstream for hitting the
> limit with is often not well catched.
> The limit is currently a bit arbitarily set to 4096 - 1024 which is afaik
> the same limit that bird uses.
the rfc says
If, due to the limits on the maximum size of an UPDATE message (see
Section 4), a single route doesn't fit into the message, the BGP speaker
MUST not advertise the route to its peers and MAY choose to log an error
locally.
so this is correct.
> While the default free zone should be fine with this it may be to strict
> from some strange internal use, where a large amount of e.g. communities
> are attached for extra information. I don't want to make this a knob
> fest and making this configurable. So happy for input from BGP users.
i for one dont see a problem with it.
code reads and runs ok too.
> Cheers
> --
> :wq Claudio
>
> Index: rde.c
> ===================================================================
> RCS file: /cvs/src/usr.sbin/bgpd/rde.c,v
> retrieving revision 1.379
> diff -u -p -r1.379 rde.c
> --- rde.c 10 Feb 2018 05:54:31 -0000 1.379
> +++ rde.c 24 Feb 2018 13:16:09 -0000
> @@ -997,6 +997,13 @@ rde_update_dispatch(struct imsg *imsg)
> if (attrpath_len != 0) { /* 0 = no NLRI information in this message */
> /* parse path attributes */
> asp = path_get();
> + /* protect from oversized messages */
> + if (attrpath_len > 4096 - 1024) {
> + asp->flags |= F_ATTR_PARSE_ERR;
> + log_peer_warnx(&peer->conf, "update too big (%i), "
> + "path invalidated and prefix withdrawn",
> + attrpath_len);
> + }
> while (len > 0) {
> if ((pos = rde_attr_parse(p, len, peer, asp,
> &mpa)) < 0)
>
