Destination Prefix
The address range the entry can match, such as a subnet, a sensor VLAN, or the default route.
4 Routing Tables and Route Types
routing
networking
iot
Keywords
routing table, route types, longest prefix match, route metric, administrative distance, static route, dynamic route, default route, RPL
4.1 Start With the Table Row
A routing table row is a promise about one kind of traffic. It says which destination or prefix is in scope, which next hop should receive the packet, where the route came from, and which metric or priority makes it preferable.
Read the table row as an operating record, not as decoration. In an IoT path, the row may sit on a sensor parent, border router, gateway, or cloud edge, so the useful question is always whether that row supports the traffic direction the deployment actually needs.
Overview: Routing Tables Are Forwarding Decisions
A routing table is the lookup information a router uses when it receives a packet. The table does not describe every possible path through the network. It records the local device's best forwarding decision for destination prefixes it knows about.
Each useful route entry answers a small contract: which destination prefix matches, where should the packet go next, which interface sends it, where did the route come from, and how preferred is it compared with alternatives that are otherwise comparable.
That contract is especially important at IoT boundaries. A sensor, mesh parent, border router, site router, and cloud edge may each hold a different part of the route story. The table entry should be read with the device role and traffic direction in mind.
That role check prevents overclaiming. A sensor default route may be enough for telemetry, while the border router still needs prefix, firewall, and return-path evidence before a cloud service can command the sensor.
Next Hop
The neighbor router or directly connected link used for the next forwarding step.
Route Source
The origin of the entry: connected, static, default, or learned by a routing protocol.
Metric
A comparison value used after the route is already comparable by prefix and source.
Default routes are fallbacks
An IPv4 default route, 0.0.0.0/0, or an IPv6 default route, ::/0, catches destinations that have no more specific match. It is not the best route by magic. It is the least-specific route that still gives the router somewhere to send otherwise unknown destinations.
Practitioner: Design Route State Around Boundaries
IoT routing-table design starts by naming the boundary. A constrained sensor, a mesh router, a border router, a site router, and a cloud or provider edge do not need the same route state. Put detailed route knowledge where it can be maintained and tested.
A small sensor can often use a default route toward a parent or gateway. A border router needs enough state to move traffic between the constrained network and the site or upstream network. A site router may summarize device networks, but the summary must not hide special inspection paths, migrations, or more-specific exceptions.
Keep route ownership in the record. Static routes need a maintainer and a cleanup trigger; learned routes need neighbor and policy evidence; default routes need a return-path check so they do not hide an unreachable sensor prefix.
For each exception, name who will remove or retest it after a gateway move, subnet migration, or routing-mode change.
Route type
Forwarding question
Review evidence
Connected
Which directly attached network can this interface reach?
Interface address, link state, prefix length, and packet test on the local link.
Static
Which stable path has an operator deliberately configured?
Configuration record, next-hop reachability, migration owner, and stale-route removal trigger.
Dynamic
Which protocol learned this route, and what policy accepted it?
Protocol neighbor state, advertised prefix, route source, metric, and failover behavior.
Default
Where should unmatched destinations go?
Gateway reachability, return path, security boundary, and evidence that no more-specific route should apply.
IoT routing-table record
For a reviewable design, record the traffic direction, destination prefix, selected route, next hop, route source, preference model, metric meaning, return path, and retest trigger. This keeps telemetry uplink, command downlink, firmware downloads, and management access from being treated as one generic path.
Under the Hood: Lookup Order Before Metrics
Routing mistakes often come from comparing the wrong fields first. A router does not normally pick the lowest metric across every route in the table. It first finds matching prefixes, prefers the most specific match, resolves route-source preference for comparable entries, and then applies the metric rules for routes that are still competing.
This lookup order explains many surprising gateway behaviors. A broad default path can be healthy while a more-specific stale static route steals traffic, or a correct RPL parent can still fail a downlink claim because the root lacks current route state.
The reviewer should therefore replay the lookup with the real destination address before judging the metric. That single step often separates a routing-table defect from a firewall, DNS, or application symptom.
1. Match prefixes
Find entries whose destination prefix includes the packet destination.
2. Choose specificity
Prefer the longest matching prefix, such as a sensor VLAN route over a broader site summary.
3. Resolve source
Use the platform's configured route-source preference when comparable routes exist.
4. Compare metrics
Use the metric meaning for that protocol or route source only after the earlier decisions are settled.
5. Forward and prove
Send to the next hop, decrement TTL or Hop Limit, and verify packet behavior in the needed direction.
RPL route evidence is separate
RPL parent choice, Rank, Objective Function state, and DAO route state are not interchangeable with a generic IP routing-table screenshot. For upward traffic, record the selected parent and metric reason. For downward traffic, record whether Storing or Non-Storing mode is in use and what route evidence proves reachability from the root toward the node.
Equal-cost paths, policy routes, firewall state, and NAT state can add more checks, but they do not remove the basic rule: the lookup result must be tied to the exact traffic direction under review. A telemetry success path does not automatically prove downlink command reachability.
4.2 Summary
Routing tables are local forwarding evidence. A route entry maps a destination prefix to a next hop or interface, records where the route came from, and gives comparison information for routes that are truly comparable. Longest-prefix match is the key lookup rule to check before arguing about metrics.
For IoT systems, route-table review should follow the boundary: sensor, parent, border router, site network, and upstream service. Keep constrained nodes simple, put detailed route state at maintainable boundaries, and prove both telemetry and command directions when the application depends on them.
4.3 Key Takeaway
A routing-table screenshot is not enough by itself. Turn it into a review record: exact destination prefix, selected next hop, route source, preference model, metric meaning, return path, failure behavior, and the retest trigger that keeps stale routes from surviving migrations.