Routing for HPE7-A01

Routing is 13 percent of the current HPE7-A01 blueprint and provides the Layer 3 structure that connects campus segments without extending one broadcast domain everywhere. On AOS-CX, candidates should be able to implement routing topologies and functions, then verify the actual route selection and troubleshoot when forwarding does not match the design.

The live HPE7-A01 target is not a pure routing exam, so the emphasis is practical campus integration. Routing decisions sit next to VLANs and SVIs, resilient uplinks, wireless gateway paths, security policy, VRFs, monitoring, and change management. A route that exists in the table is only useful if the packet can reach its next hop and the return path also works.

Study routing as a sequence of evidence: what prefixes should be known, where should they come from, which route should win, which next hop should be selected, and how will the network react when the topology changes.

Connected routes begin with correct Layer 3 interfaces

A routed campus starts with interfaces that have valid addressing and operational state. An SVI becomes the gateway for a VLAN; a routed physical interface or LAG can provide point-to-point connectivity between network devices. When the interface comes up with an IP prefix, the switch installs a connected route for that network.

This is the first routing checkpoint in troubleshooting. If the connected prefix is missing, do not investigate OSPF first. Check whether the interface exists, whether it is administratively enabled, whether its underlying VLAN or physical link is up, and whether the address is configured in the expected VRF.

The discipline is simple: verify the most local source of routing information before blaming a dynamic protocol. Many scenario questions become easy when you ask which route should exist even if every routing neighbor is down.

Static and default routes solve simple, stable reachability problems

A static route explicitly maps a destination to a next hop or outgoing interface. It is useful when topology is simple, when a device has one predictable upstream path, or when a specific route should not depend on a dynamic protocol. A default route provides a catch-all path for destinations not otherwise known.

The trade-off is adaptability. Static routes do not automatically follow topology changes unless the design adds tracking or an alternate mechanism. A route can remain configured while the next hop is no longer usable, creating a black hole. That is why professional troubleshooting checks both the routing table and next-hop reachability.

AOS-CX also supports static routes inside VRFs. Always include the routing context in your reasoning. The same prefix can legitimately have different next hops in different VRFs, and checking only the default table can hide the real problem.

OSPF adds topology awareness and convergence

OSPF allows routers or Layer 3 switches to exchange reachability and compute paths based on a shared link-state view. On AOS-CX, an OSPF process can be created within a VRF, assigned a router ID, and associated with the relevant interfaces and areas. The current platform supports multiple processes per VRF on supported models, but exam readiness depends more on understanding neighbor formation and path selection than on memorizing maximum values.

A working OSPF adjacency requires several pieces to align: interfaces must reach each other, area and network-type assumptions must be compatible, authentication must match where used, and timers or MTU-related settings must not prevent adjacency. Once neighbors form, route type and metric determine which prefixes are installed.

Review routing and convergence fundamentals until you can separate “neighbor is down,” “route was never advertised,” and “route was learned but lost selection.” Those are different fault classes.

Router IDs, areas, and default-route propagation are design decisions

An OSPF router ID uniquely identifies the routing process and should be stable. Areas reduce the scope of link-state information in larger designs, with area 0 serving as the backbone in conventional multi-area OSPF. In a small campus, extra areas can create complexity without adding value; in a large design, they can help constrain flooding and summarization boundaries.

Default-route origination is another deliberate decision. Advertising 0.0.0.0/0 tells downstream routers that this OSPF speaker is a path for otherwise unknown destinations. The AOS-CX command normally originates the default when it exists in the local routing table. If that local default disappears, downstream behavior may change even though OSPF neighbors remain healthy.

The exam-level habit is to ask what business path each advertisement enables. A protocol configuration is only correct when it reflects the intended topology and failure behavior.

VRFs create separate routing worlds on the same switch

Virtual Routing and Forwarding separates routing tables so traffic domains can use independent prefixes and policies. This is useful for management, tenants, guests, or other segmentation requirements where Layer 3 isolation must persist even if the same physical infrastructure is shared.

Troubleshooting VRFs requires discipline because a command run in the wrong context can appear to prove that a route is missing when it actually exists elsewhere. Verify the interface-to-VRF association, check the route table in that VRF, and confirm that any inter-VRF route leaking is explicitly designed and controlled.

This is also a security boundary. Creating a VRF does not automatically create permitted paths between VRFs; if interconnection is required, the architecture should specify how and where it occurs. That keeps segmentation intentional rather than accidental.

Route selection must be read from the table, not inferred from configuration

Multiple routing sources can know the same destination. Connected, static, OSPF, and other protocols each contribute candidates. The device selects the best route according to prefix length, route preference or administrative distance, and protocol-specific metrics. Equal-cost paths may support ECMP when the platform and route conditions allow it.

The troubleshooting mistake is to see a configured route and assume it is active. Read the RIB or route table and identify the selected entry, next hop, outgoing interface, source protocol, and metric. Then confirm that forwarding has a valid neighbor or adjacency for that next hop.

This evidence-first method is more reliable than mentally reconstructing every configuration stanza. It also helps you notice stale assumptions after a topology or metric change.

Resiliency depends on convergence and return reachability

A redundant campus may have multiple upstream paths, dual core or aggregation devices, and several candidate routes. The routing design should define which path is preferred under normal conditions and which path becomes active after a failure. Convergence speed matters, but stable behavior matters more than chasing the smallest timer.

Always test the reverse direction. Forward traffic can leave through one path and fail on return because the remote network lacks a route back, a VRF boundary differs, or security policy blocks asymmetric traffic. A ping failure is therefore not proof that the outgoing route is wrong.

The broader secure network design principle applies: availability, segmentation, routing, and control have to be evaluated as one system.

Show commands and telemetry turn routing theory into diagnosis

Useful routing evidence includes interface state, ARP or neighbor entries, the IPv4/IPv6 route tables, OSPF process state, area information, neighbors, LSAs where necessary, and path tests such as ping or traceroute. On AOS-CX, show commands can be scoped to specific VRFs and OSPF processes, which is important in multi-context designs.

Monitoring should establish a baseline. If a route count changes sharply, an OSPF adjacency flaps, or latency increases on one uplink, operators need historical context to know whether the event is new. Network observability connects those protocol signals to broader service impact.

During an incident, collect before changing. A route table captured before remediation often explains the root cause later, while immediate configuration changes can erase the evidence.

Use a three-router campus lab to practice OSPF and static-route interaction. Put the access layer in one VRF, establish OSPF between distribution devices, and configure a default route toward an upstream firewall. Then remove the upstream default while leaving OSPF adjacencies intact. The downstream switches may still show healthy neighbors even though internet-bound traffic fails. This scenario teaches an important lesson: protocol health and service reachability are related but not identical.

Create a second failure by moving an SVI into the wrong VRF. The interface can be up, the endpoint can have an IP address, and the expected route can even exist in another routing table, yet traffic fails because the lookup occurs in the wrong context. Troubleshooting becomes fast when every command is scoped to the correct VRF and you verify the local connected route before investigating dynamic advertisements.

OSPF metric changes are also useful practice. Give two equal-cost paths to a destination, confirm ECMP behavior, then change the cost on one interface. The route table should reveal the preferred path and make the control-plane decision visible. If forwarding does not follow the expected route, inspect adjacency, next-hop resolution, or policy rather than immediately changing metrics again.

Finally, test return reachability. Trace traffic from a client VLAN to a remote service and then reason through the return route to the client prefix. Many campus incidents are asymmetric: the outbound path is correct, but the remote side sends return traffic somewhere else. Professional routing diagnosis always considers both directions and the security devices that may react differently to asymmetric flows.

Routing incidents are easier to solve when the engineer separates control-plane state from forwarding symptoms. OSPF can have healthy neighbors while the required prefix is absent because it was never advertised, filtered, or installed. The route can exist in the local table while end-to-end traffic still fails because the next hop is unreachable from the correct VRF, the return route is missing, or policy blocks the path. Read the routing table first, then validate the next hop, then test the return direction. That sequence keeps troubleshooting grounded in evidence instead of protocol guesswork.

A useful HPE7-A01 lab is to build two routed distribution switches and an access segment, advertise the access prefix through OSPF, and provide a default route toward an upstream edge. Record the normal route table and neighbor state. Then introduce one fault at a time: wrong area, duplicate router ID, missing default advertisement, incorrect VRF assignment, or a failed transit link. The exercise is complete only when you can explain not just which command reveals the fault, but why the observed route selection follows from the configuration.

HPE7-A01 routing questions reward layered reasoning

The HPE Aruba Networking Certified Professional – Campus Access path assumes candidates can implement and fix a real network. The fastest way to prepare is to build small topologies and deliberately break one element at a time: remove a VLAN, change a static next hop, misplace an OSPF area, alter a metric, move an interface into the wrong VRF, or withdraw a default route.

For each fault, predict which evidence will change before you inspect the switch. That trains the distinction between configuration knowledge and diagnostic reasoning. If the neighbor is full but the route is missing, the problem is different from a neighbor that never leaves an early adjacency state.

A strong routing answer explains both the control plane and the forwarding outcome: why the prefix should be learned, why one route should win, and how a packet should move through the campus when the network is healthy or degraded.