Most firewalls give you one rulebook for everybody. Policy Manager gives you several — and a small set of rules decides which rulebook each person's traffic is judged by.
Before clicking anything, it helps to understand what a policy really is in this firewall, because the word is misleading. A policy here is not a single rule like "block Facebook". It is a complete, independent stack of apps — Arista's name for it is a rack. Your firewall ships with one rack, the default. Policy Manager lets you build more racks, and then, for every new connection, it picks exactly one rack to process it. Everything else in this topic — inheritance, rule order, reports — follows from that one idea.
In a normal single-policy setup, the rack on your screen holds apps like Web Filter, Application Control and Firewall, and every user's traffic passes through those exact instances. When you create a second policy, you are not adding a note to that rack — you are building a second rack with its own Web Filter instance, its own block lists, its own everything. That is why two groups can have genuinely opposite rules on one box: students' Web Filter blocks a category that the staff Web Filter, a completely separate instance, allows.
The default rack is not a fallback screen or an error state. It is a full policy that comes pre-installed, and at first it processes 100 percent of your traffic. When you add Policy Manager rules, you are not turning the default off — you are peeling specific groups away from it. Whatever is left over still lands there. Experienced admins therefore treat the default rack as the policy for unknown devices: guests who were never registered, a brand-new laptop, anything unexpected. Configure it like you mean it, because something you care about will end up there sooner or later.
Building every rack from zero would mean reinstalling and reconfiguring every app for every group. That is why each new policy asks for a parent rack. The child policy inherits the parent's apps and their settings as its starting point. Create a Students policy with the default as parent, and it begins life behaving exactly like the default — then you tighten only the two or three things that make it a student policy, such as stricter Web Filter categories. Inheritance is a starting template, not a live link: after creation, the child has its own instances, so editing the child does not change the parent, and later edits to the parent do not silently rewrite the child.
The choice of rack happens once, when a session begins. The firewall reads the Policy Manager rules from the top, finds the first rule whose conditions match the new session — its source address, MAC address, username, time of day and similar attributes — and hands the session to that rule's rack. Every packet of that session is then processed by that rack's apps. Two honest consequences follow. First, a session already open keeps its original policy until it ends, even if you edit the rules mid-day. Second, there is no such thing as "a bit of both policies" — overlaps are always settled by rule order, never merged.
This rack model matches how organisations actually think. A school does not want slightly different rules for 400 individual children; it wants three rulebooks — students, teachers, office staff — and a reliable way to sort people into them. An office wants HR, accounts, guests and servers separated, not one giant rule list where a change for one department risks breaking another. Because each rack is independent, you can tighten the guest rack aggressively without any fear of touching the staff rack. The cost of that independence is discipline: more racks means more Web Filter instances to keep updated and more reports to read, which is why three to five well-named policies beat fifteen forgotten ones.
The video shows the Policies screen, the parent policy setting and how a new rack appears next to the default — watch it once and this model becomes obvious.
▶️ Watch Full VideoThere is no small fixed limit that matters for a typical office or school — you can create many racks. In practice, keep the count low. Every rack is a separate set of apps to configure, update and report on, so three to five clear groups work better than a rack per person.
No. The parent is a starting template. The child inherits the parent's apps and settings at creation time, but from then on it has its own instances. Editing the parent later does not change existing child policies, and editing the child never changes the parent.
Only the apps you install into that rack. A rack shows the apps added to it — installing Web Filter into the HR policy does not add it to the student policy. Each installation is a separate instance with its own settings, and licensed apps are covered by your subscription rather than bought per rack.