Filtered routes were erroneously removed from the api output.
This fixes the following case:
A peer announces legitimate (accepted) routes that
carrry a next_hop attribute and an empty 'learnt_from'
attribute. Filtered routes from the same peer have an
incorrect next_hop but matching 'learnt_from' attribute.
Those were previously not included in the output of filtered
routes.
Reported by: Johannes Moos <johannes.moos@de-cix.net>
In case of remote-triggered blackholing filtered routes may be present
that have a nextHop different from the IP of the neighbour the route
has been learnt from. These would not appear in on the routes page.
With this patch, routes ar displayed if either
gateway matches nextHop or the learnt_from address.
Effectively de-activate routes deduplication in case a peer announces
just filtered routes. Because no legitimate (accepted) route is
announced, we cannot reliably infer the neighbours gateway / nextHop IP.
This needs changes in the future when another means of obtaining the
neighours gateway address (e.g. global peer status) becomes available.
In case neighbour.Description does not contain the string e.g. "AS42"
- this is the case when only the friendly name of a neighbour is in the
description field - we need to match this input with a regex and search within the
neighbour.Asn attribute.
In a mulit-stage filtering setup the responses of a birdwatcher
BIRD API need processing to eliminate duplicate entries of routes
and eliminate routes of other routers that an IXP participant might
have.
The filter is applied in the .../protocols/<protocolID>/routes endpoint
it affects "imported" (removes routes that are filtered in pipe),
"filtered" (only those of router with <protocolID>), and "noexport"
(same).
Matthias Hannig:
Resolved merge conflict in import path
