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
After addition of an improved Alice-API we no longer need
this workaround to filter data in the frontend.
When a view of all routes of a selected IXP participant
(possibly with multiple routers) is desired this should
become a new page (with assorted API extensions).
This reverts commit 15e728da2c6855a3fad6a22a58dbd6d62456a7cb.
Extend API to include filtered routes on pipe protocol. Required, hence in
case of multiple peering routers of one IXP participant we can only assume that
all routers advertise the same prefixes. Obviously, this assumption does not
hold true if the amount of advertised prefixes differs between those routers.
In essence we estimate the number of routers and correct the amount of accepted
prefixes and those filtered on the participant pipe towards the master table.
In case of multiple peering routers of one customer, their
announcements are aggregated in a single per-customer table.
RoutesPage used to display contents of that table irrespectively
of the current router selected in the UI.
Now, when selecting a router in the UI RoutesPage is initialized
with the nextHop IP of that router to display only routes
(filtered, accepted and noexport) from that router.
