A rural broadband cooperative notices that one subscriber on a shared aggregation port is consuming enough upstream bandwidth to degrade service for neighboring subscribers on the same port. Which combination of Junos concepts, applied together on that interface, addresses this at an introductory level?

A firewall-filter term written with from conditions that identify the specific subscriber's traffic, paired with a then action referencing a policer configured with a bandwidth limit and burst-size limit, is the introductory Junos pattern for capping one subscriber's throughput on a shared aggregation port without affecting neighboring subscribers on the same physical port. Lowering a route preference through routing policy changes which route Junos prefers for reaching a destination; it does not throttle the volume of traffic a subscriber can send and would not address a bandwidth-consumption problem. A static route to a null next hop would black-hole all of that subscriber's traffic entirely rather than merely rate-limiting it, which is a far more drastic and inappropriate remedy for someone who is simply using more bandwidth than their neighbors, not someone whose traffic needs to be blocked outright. Creating a separate routing instance to isolate the subscriber addresses routing-table separation and multi-tenancy concerns, not per-subscriber throughput on a shared port, and is a disproportionate and unrelated tool for this problem. The filter-plus-policer combination keeps the fix scoped precisely to the offending subscriber's traffic while leaving routing and forwarding for everyone else on the port untouched. To verify the fix, the NOC can monitor the policer's discard or markdown counters via the filter and confirm neighboring subscribers' measured throughput returns to expected levels once the cap is in place.