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.
