Skip to main content

Director and rWeb

Director synchronizes configuration with rWeb, pulling in the sets of Groups and Zones in order to minimize the amount of effort needed to maintain consistent network routing and mitigation behavior. Because rWeb is primarily concerned with managing RIOS filter devices, which are handling traffic mitigation for network links they are deployed on, there are a few concepts that should be reviewed in the context of Director, which is receiving traffic samples from other network devices and actively making traffic steering directions.

rWeb Configuration Polling​

By default, Director will periodically synchronize its Group and Zone configuration by polling rWeb every five minutes. No network event detection or configured actions will fire until Director has synchronized at least once. The current state of synchronization will be reflected within the status bar shown in the Director CLI. Director can be configured to use a different polling period using the poll-time rWeb configuration key.

Whenever Director has booted and successfully polled rWeb configuration at least once, it will continue running with its last retrieved configuration if any future poll operations (manual or automatic) fail.

rWeb's Default Zone and Network Address Space​

rWeb's Default Zone comes with two pre-defined prefixes: 0.0.0.0/0 for IPv4 and ::/0 for IPv6. This ensures that RIOS devices have a baseline default configuration on how to mitigate incoming traffic that does not have a more specific Zone specified. Since a RIOS device only filters traffic it is observing in the WAN to LAN direction, it is always able to derive how to handle incoming traffic on its WAN ports by examing the destination IP on that port.

Director, by contrast, is receiving arbitrary network traffic samples from other network devices. These samples could be from either a WAN or a LAN port, so the destination IP by itself is not enough to determine the directionality of a given sample. For this reason, Director strips out the 0.0.0.0/0 and ::/0 prefixes from the Default Zone, as otherwise it could end up using outbound traffic for incoming rate calculations.

This means that you should ensure your network routes are all present and accounted for in an rWeb Zone (which is recommended practice to begin with) so that Director can correctly calculate incoming traffic based on received samples.

Detection and Zone Boundaries​

In rWeb, the Zone with the most specific prefix will track incoming traffic and manage how any RIOS devices mitigate that traffic. Director mirrors this concept by compiling network statistics for incoming flow samples against the most specific Zone. This means that any individual hosts will be represented with accurate statistics within their assigned Zone.

However, while Zone tracking and mitigation behavior is unified on rWeb and RIOS (as all mitigation is done against specific victim destination addresses), in Director Zone-wide worfklow triggers could affect other Zones besides the one triggering the workflow. A Zone-wide trigger will initiate an action using all of the Zone's prefixes, not just an individual host. When using Zone-wide triggers, potential prefix overlaps should be reviewed to avoid potential complications.

Redirection and Zone Boundaries​

rWeb Zones can have routes specific up to the host (/32 for IPv4 and /128 for IPv6), and RIOS filter devices will use that configuration to handle mitigation with a very high level of granularity. Since this is all inline behavior for those devices, there's no external traffic effects.

Director is capable of redirecting traffic in your network, unlike a purely inline rWeb and RIOS deployment. Moreover, BGP redirection can affect traffic on the public Internet, which comes with some conventional restrictions. Typically most BGP peers will only accept announcements of subnets with a minimum size (/24 or larger for IPv4, /48 or larger for IPv6). This means it is possible to have Zones with routes configured that are smaller than this announcement size.

If you intend to make public announcements, this means you should review Zones that are under this minimum size, to understand when an announcement meant for one Zone may end up affecting multiple Zones (e.g. two distinct /26 Zones fall under the same /24 subnet that would be announced).

This can also affect Zones larger than the minimum subnet size if one Zone's announcement could encompass another (e.g. a /24 Zone falls under a /22 Zone, and you make a /22 announcement for the latter).

Reviewing the Zone routes against the announcements you could be making will be very specific to your deployment and configuration, and is a manual process you should perform prior to making any public announcments. It may be helpful to use the no-op flag for troubleshooting any BGP or BGP Flowspec actions.