Cisco network engineering is no longer just interface configuration and routing protocols. Enterprise networks now combine identity-based access, automation, model-driven telemetry, internet and cloud path visibility, multicast, QoS, segmentation, and multi-VRF routing with the familiar routing and switching control plane. The engineer still needs to understand packet forwarding, but the operating model increasingly depends on policy systems and programmable interfaces that can change many devices at once.
This hub organizes that system for the Cisco ecosystem. The first support cluster covers wired 802.1X with Cisco ISE, Ansible for IOS XE, BGP best-path decisions, Cisco IP SLA tracking, ThousandEyes path analysis, PIM Sparse Mode, QoS queueing on Catalyst, gNMI telemetry, TrustSec Scalable Group Tags, and VRF-Lite. Later H16 pages extend the cluster into VXLAN underlay/overlay, Wi-Fi 6E, Secure Client migration, Duo conditional access, ISE profiling, MPLS L3VPNs, Catalyst Center assurance, Cisco SD-WAN and network automation.
The existing Catalyst Center automation article provides controller-level context, while network automation provides the broader operational principle: automate decisions that are understood, observable, and reversible.
802.1X design starts with failure behavior, not only successful authentication
Cisco ISE provides the policy decision point for wired 802.1X, while Catalyst access switches act as authenticators and endpoints use supplicants. ISE 3.x organizes network access through policy sets, authentication rules, and authorization rules, and modern certificate-based designs often prefer EAP-TLS where certificate lifecycle and endpoint management support it.
802.1X Design with Cisco ISE focuses on certificates, policy-set structure, RADIUS/CoA, phased deployment, critical access, MAB exceptions, voice devices, and what happens when ISE or the endpoint supplicant is unavailable.
Existing material on 802.1X authentication provides the protocol foundation. Production design becomes reliable when “authentication server down,” “device has no supplicant,” and “certificate expired” are explicit operating states rather than surprises.
Ansible should make IOS XE changes idempotent and reviewable
Modern Ansible network automation for Cisco IOS/IOS XE uses the cisco.ios collection, with network_cli or other supported transport patterns and modules such as ios_config, ios_interfaces, ios_l3_interfaces, ios_bgp_global, and related resource modules. The current collection is installed separately from ansible-core when it is not included through the broader Ansible package.
Ansible for Cisco IOS XE explains inventory design, credential handling, resource modules versus raw configuration, diff/check workflows, backups, idempotency, staged rollout, validation, and rollback.
The existing REST APIs and network automation article is useful context because Ansible should fit into a broader source-of-truth and change pipeline rather than become a large collection of device-specific command snippets.
BGP best-path analysis should separate policy from tie-breakers
Cisco BGP implementations select one best path by evaluating route validity and configured/learned attributes such as weight, local preference, local origination, AS-path length, origin, MED, eBGP versus iBGP, next-hop cost, and final tie-breakers. Platform families can add features that alter or extend the normal sequence, so operators should confirm the algorithm for the actual software train.
BGP Best-Path Decisions focuses on how to reason from the BGP table toward the active route without memorizing attributes in isolation. The existing BGP path selection article provides broader cross-platform context.
Good routing policy is deliberate: local preference expresses outbound policy across an AS, MED can influence entry among comparable paths, communities carry policy metadata, and route maps should encode business routing intent rather than “fix one prefix” emergency logic that nobody can explain later.
IP SLA turns active measurement into routing and availability decisions
Cisco IP SLA generates active probes and measures reachability or performance, while enhanced object tracking can turn an IP SLA operation into a state consumed by static routes, first-hop redundancy, Embedded Event Manager, and other clients. Current IOS XE still distinguishes tracking state from tracking reachability, which matters when an operation is over threshold but still reachable.
Cisco IP SLA Tracking covers probe design, source/VRF selection, object tracking, delay timers, floating routes, FHRP integration, threshold interpretation, and false failover prevention.
The existing IP SLA alerts article provides monitoring context. The engineering goal is to measure the dependency users care about rather than merely ping the next-hop interface.
ThousandEyes shows the network path beyond the enterprise edge
Cisco ThousandEyes combines agent-based synthetic tests, path visualization, application/network measurements, BGP visibility, and endpoint telemetry to reveal what happens across enterprise, ISP, internet, SaaS, and cloud infrastructure that traditional device monitoring cannot observe directly.
Cisco ThousandEyes Path Analysis focuses on path-visualization hops, latency/loss patterns, agent placement, bidirectional tests, routing changes, internet-provider boundaries, and how to avoid treating every nonresponsive hop as packet loss.
Existing ThousandEyes material provides product context. Path analysis becomes useful when the engineer correlates hop behavior with end-to-end transaction failure and routing evidence instead of reading the visualization as a literal traceroute scoreboard.
PIM Sparse Mode separates multicast source discovery from receiver interest
PIM Sparse Mode assumes multicast receivers are distributed sparsely, builds shared trees around Rendezvous Points, and relies on explicit receiver interest rather than flooding multicast everywhere. The RP enables initial source/receiver discovery, while traffic can move to shortest-path trees depending on platform/configuration and group behavior.
Multicast PIM Sparse Mode explains RP placement, RPF, IGMP/PIM state, source registration, join/prune behavior, Anycast-RP design, SSM migration, and multicast troubleshooting from receiver to source.
The existing multicast in the enterprise article is the right conceptual starting point: PIM does not discover receivers or fix broken unicast routing; it builds distribution state on top of those foundations.
Catalyst QoS queueing begins after classification and marking
Catalyst 9000 QoS combines classification, marking, policing, shaping, buffering, queueing, scheduling, and congestion avoidance. On current Catalyst 9300 IOS XE guides, egress queueing supports bandwidth allocation, priority queues, weighted tail drop, queue buffers, and WRED-related behavior, with platform defaults that should be understood before custom policy is added.
QoS Queueing on Cisco Catalyst focuses on what happens during congestion: which traffic enters which queue, which queue receives strict/priority treatment, how buffers and WTD thresholds affect drops, and how to validate actual hardware queue counters.
The existing QoS queueing basics article provides the broader principle. Priority marking has little value when the trust boundary is wrong or the egress queue policy does not map that marking to intended treatment.
gNMI telemetry makes network state streamable and model-driven
Current IOS XE model-driven telemetry streams YANG-modeled data through standards-based interfaces including gNMI, with dynamic dial-in and configured dial-out subscription models plus periodic and on-change update modes where supported. Subscription and model support remain platform-dependent and should be validated before fleet-wide collector design.
Network Telemetry with gNMI covers YANG paths, subscription types, sampling/on-change semantics, TLS/authentication, collector scaling, path/version compatibility, timestamping, and the difference between configuration APIs and operational-state telemetry.
The existing network assurance and telemetry article provides the signal-quality perspective. Streaming more data is not useful if the organization cannot identify source device, path, schema version, collection lag, and ownership.
TrustSec makes role identity portable across topology
Cisco TrustSec classifies users and devices into Scalable Groups, represents that classification with a Security Group Tag (SGT), and can enforce communication policy through Security Group ACLs (SGACLs) at enforcement points. Cisco ISE can act as the centralized policy/SGT authority, while SGT information can be propagated inline or through mechanisms such as SXP where inline tagging is unavailable.
TrustSec Scalable Group Tags focuses on classification, SGT transport, SGACL policy, ISE integration, SXP fallback, policy matrix design, logging, and migration from IP/subnet-centric ACLs.
The existing zero-trust access in Cisco environments article provides broader context. SGTs make role portable, but they still depend on trustworthy authentication/classification and explicit enforcement policy.
VRF-Lite provides routing separation without MPLS in the campus
VRF-Lite creates multiple independent routing and forwarding tables on the same Cisco device and associates Layer 3 interfaces or SVIs with one VRF. It can support overlapping addresses and separate routing domains without requiring MPLS in the local campus device.
VRF-Lite Design covers route separation, route leaking, shared services, VRF-aware management/AAA/DHCP/PBR, routing-protocol instances, observability, and operational pitfalls when engineers troubleshoot the global table while the interface belongs to another VRF.
The existing VRF segmentation article provides the conceptual model. VRF-Lite is effective when route boundaries remain explicit and any inter-VRF communication is an intentional policy decision rather than accidental leakage.
Cisco network engineering is mature when intent, state, and user experience can be reconciled
ISE policy, Ansible source, BGP route policy, IP SLA probes, ThousandEyes paths, multicast state, hardware queues, gNMI streams, TrustSec tags, and VRF tables are different representations of one network service. Operations succeeds when the team can move between them without losing context.
The goal of this hub is therefore not product memorization. It is to make network behavior explainable: who or what is allowed, which route wins, what path users take, how congestion is treated, how state is observed, how segmentation is enforced, and how automated changes are validated and reversed.
That operating model also gives the team a common release discipline: identity policy, route policy, automation code, telemetry schema, queue policy, multicast state, and segmentation rules all need versioned intent plus post-change evidence. The network becomes easier to scale when every subsystem has an owner, source of truth, observable state, and tested rollback path.
That maturity also depends on shared operational language. Routing, switching, wireless, automation, and assurance teams should be able to describe the same failure in terms of intent, observed state, blast radius, and recovery evidence, even when different platforms are involved.
