--- name: panos-mcp-routing-and-zone-reconciliation description: Reconcile the routing table, static routes, interfaces, zones and VLANs of one PAN-OS firewall against each other to find dead static routes, subnets with no route, and interfaces or VLANs in the wrong zone, before or after a change. Use when the user asks why traffic is not routed, wants to check routes against zones, asks for a routing or zoning audit, or wants to know whether a subnet is reachable through the right interface. --- # Reconcile routing and zones This job asks one question: **does every subnet the firewall serves have a correct path, and does every path land in a zone that policy expects?** It is a consistency check across tables, not a policy review (that is `security-rule-audit`) and not a health check (that is `firewall-health-check`). Most findings are mismatches between two lists that were each correct when written. ## 1. Confirm the device and freeze the picture Name the firewall in scope before any call. If the user has not named one, ask. Read the interfaces (`get_interfaces`), zones (`get_zones`) and VLANs (`get_vlans`) first, so that every later finding can name an interface and a zone. Record the device name and the time of the read in the report, because routing tables change. ## 2. Build the interface-to-zone map From `get_interfaces` and `get_zones`, write one line per interface: interface, zone, addresses, and whether it is a layer 3 interface, a VLAN member, or a subinterface. Then check the map itself: - An interface with an address but no zone is a finding. Traffic on it cannot match zone-based policy. - A zone with no interfaces is either dead configuration or a zone meant for future use. Note it, do not call it an error. - A VLAN listed in `get_vlans` whose interface is not in the zone map is a gap. Check whether the VLAN's subinterface exists before reporting it. ## 3. Compare the routing table with the subnets you expect Read `get_routing_table` and `get_arp_table`. For each connected subnet from step 2, confirm there is a connected route out of the interface that owns it. A subnet that has an address on the firewall but no connected route is the strongest signal of a broken interface or a misconfigured address. Then go the other way: for each route in the table, can you tie its next hop to a subnet on a connected interface? A next hop that matches no connected subnet is unreachable from the firewall's own view and should be flagged. ## 4. Audit static routes as a separate list Read `get_static_routes` and compare it against the routing table. Three patterns matter: - **Dead static route.** It is configured but absent from the active routing table, or its next hop sits on an interface that is down or has no address. Find the cause before recommending removal; a route can be missing because its interface is down, which is a health problem, not a routing one. - **Shadowed static route.** A more specific route for the same prefix is already present from another source. The static route does nothing and may be a leftover from an old design. - **Default route check.** Confirm that exactly one default route exists for the expected egress interface. Zero is an outage waiting to happen; two with equal metrics is a load-sharing decision someone should own. Do not assume that a route absent from the table is a mistake. Ask whether it was meant to be conditional (for example tied to a tunnel or a second link) before classifying it. ## 5. Check zones against what routing says Zones are where policy attaches, so verify the zone of every routed path: - A subnet routed out of a zone that is not the one its clients live in means traffic crosses a zone boundary policy may not expect. Name the source and destination zones. - Two interfaces carrying the same subnet in different zones is an ambiguity to report, not to resolve. - Interfaces in the same zone with routes between them need no change, but note them if the user is looking for intra-zone isolation. Use `get_dns_proxy`, `get_dhcp_leases` and `get_arp_table` only to confirm that a subnet has live hosts behind it. A subnet with no hosts and no route is low priority. A subnet with live hosts and no route is urgent. ## 6. Separate findings by certainty Before writing up, sort each finding into one of three bins: - **Confirmed:** you can point at both sides of the mismatch in the tool output. - **Likely:** one side is clear, the other depends on intent you cannot see (a design note, a planned link). - **Needs the owner:** only a person who knows the network design can decide. Never present a "likely" item as confirmed. Never recommend removing a static route in this job; hand that to `static-route-change`, which has its own approval gate. ## Common patterns and traps - **Connected route missing, interface looks up.** Usually the address was moved or the subinterface tag does not match the VLAN. Check the VLAN ID on both sides. - **Static route present, next hop is the firewall's own address.** It loops or is never used. Look at the route's egress interface first. - **Route exists, traffic still fails.** The routing table is only half the path. Note that zone policy and asymmetric return routing are outside this job and hand off to `security-rule-audit`. - **Two defaults after a migration.** The old one was left in place. This is the most common finding and the easiest to explain. - **Empty ARP table for a routed subnet.** Could be no hosts, could be a stale view. Say which you think and why. - **Tool result shows a list cut short.** The connector may paginate or truncate. If counts look suspiciously round, re-read and say so rather than reporting a total you cannot confirm. - **Zone is named but has no interfaces, and a rule refers to it.** Policy refers to a zone that routes nothing. Report it as a dead reference. ## Output ``` Device: Read at: