CCNP Enterprise 300-420 Full Course Free

BFD is the correct design feature for detecting a link failure within 200 ms or less without materially increasing OSPF control-plane load. Cisco uses Bidirectional Forwarding Detection as a fast, lightweight failure-detection protocol that can be associated with routing protocols such as OSPF. Instead of relying on aggressive OSPF hello and dead timers, BFD performs rapid forwarding-path checks and notifies OSPF when the path fails. This allows fast convergence while avoiding the additional routing-protocol overhead and instability that can come from very low hello timers. UDLD detects unidirectional Layer 2 fiber failures, but it is not the routing adjacency failure-detection mechanism requested here. Carrier delay can adjust interface state transition timing, but it does not provide a routing-protocol independent liveness session. Fast hellos can reduce detection time, but they increase protocol traffic and can affect overall performance. BFD is therefore the proper design choice for fast and efficient OSPF convergence. Reference topics: BFD, OSPF convergence, fast failure detection, routed campus resiliency, control-plane efficiency.

An end-to-end QoS strategy with an SLA is the best fit for an application that cannot tolerate drops and requires very low latency across countries. The customer is asking for guaranteed service behavior, not just local classification on one router. A service line with an SLA defines the expected treatment across the provider network, including bandwidth, delay, jitter, and loss commitments. This is especially important for industrial or manufacturing applications that process large data chunks and are sensitive to packet loss. A purely domain-based PHB design can mark and forward traffic differently at each hop, but it does not by itself guarantee the business outcome unless backed by an end-to-end service agreement. A flow-based approach with per-flow queuing on every ISP node would consume more provider resources and scale poorly. FEC can help selected traffic but does not replace a QoS service model. Reference topics: QoS design, service-level agreements, end-to-end QoS, low-latency applications, loss-sensitive traffic, provider WAN services.

In Cisco SD-Access, an intermediate node is an underlay transit device. Its responsibility is to provide IP reachability between fabric edge nodes, border nodes, and other fabric infrastructure roles. Intermediate nodes forward routed underlay traffic and do not perform endpoint registration, endpoint lookup, or VXLAN encapsulation for user traffic. Endpoint-to-location mapping is handled through the fabric control plane, which is based on LISP map-server and map-resolver functions. Fabric edge nodes identify connected endpoints, apply policy, act as anycast gateways, and encapsulate user traffic into VXLAN. Border nodes connect the fabric to external networks and handle traffic entering or leaving the fabric. The intermediate node is therefore comparable to a routed distribution or core transport device in a traditional hierarchical campus, except it is participating in the SD-Access underlay. It must provide stable Layer 3 reachability and appropriate MTU for encapsulated traffic but does not maintain the host tracking database or add security group information to VXLAN headers. The correct function is transporting IP packets between edge and border nodes.

BGP outbound route filtering is the correct solution because the enterprise wants control over which routes it receives without waiting for a provider change cycle each time the prefix set changes. Cisco BGP prefix-based ORF allows a receiving BGP speaker to send an inbound prefix-list filter to the remote peer, which then applies that list as an outbound filter. This reduces unwanted routing updates before they cross the session and lets the enterprise update the desired prefixes locally when business requirements change. Requesting only fixed prefixes from the ISP would work initially but fails the flexibility requirement because the provider has a two-week change process. Requesting a full table and filtering inbound would provide flexibility but wastes memory and CPU on the customer router because all routes are still received before filtering. A maximum-prefix limit does not select the correct routes. ORF is therefore the scalable operational design for receiving a default route and selected prefixes with minimal provider involvement. Reference topics: BGP ORF, prefix-based filtering, inbound route control, ISP peering design, routing table scale.