Policy engine

The policy engine decides what happens to every message: whether it is forwarded, where to, and whether it is dropped. Rules are per interface and per direction, and they are evaluated in priority order.

An access rule

Field	Meaning
interface_id	which interface this rule belongs to
direction	ingress or egress; a rule applies to one, never both
priority	lower numbers are evaluated first, default 100
action	forward, drop or log
forward_to	the destination interface when forwarding
filters	what the message must match
schedule_type	when the rule is in force at all
qos_level	delivery quality for the forwarded copy
rate_limit_per_min	ceiling on how often this rule may fire
enabled	off without deleting it

Object groups

filter_node_group, filter_sender_group and filter_portnum_group point at object groups: named, reusable sets of nodes, senders or port numbers. Define the set once and reference it from every rule that needs it, rather than repeating a list in each and having them drift apart.

Direction is not symmetric

A rule is ingress or egress, never both, and the same interface usually needs different rules in each direction. What you accept from a mesh is not what you are willing to send back out over a satellite link that costs money per message.

Scheduling

A rule can be limited to a time window. Outside that window, it does not match. This does not automatically queue a message for the next window: other matching rules and the ingress default still determine what happens. Use the delivery and scheduling controls when a message must wait.

Rate limits

rate_limit_per_min bounds how often a single rule fires. It exists because a chatty mesh node can turn one enthusiastic sensor into a satellite bill. A rate limit on a rule is a spend control, not a performance control.