Question 1

WAN technologies (Frame Relay): By default, a Frame Relay WAN is categorized as what type of Layer 2 physical topology?

Accepted Answer

Introduction / Context: Legacy WAN services like Frame Relay shaped many CCNA-era designs. Understanding their logical/physical characteristics is key to choosing routing protocols and neighbor discovery behavior. Given Data / Assumptions: Technology: Frame Relay (L2 WAN service with PVCs). “Default” behavior as seen by routing protocols. Concept / Approach: Frame Relay is a Non-Broadcast Multi-Access (NBMA) network. Multiple nodes share the provider cloud, but the medium does not support broadcast/multicast natively across all neighbors. This affects protocols like OSPF/EIGRP, which may need manual neighbor statements or special network types. Step-by-Step Solution: Classify the medium: multi-access (many routers can attach).Note that it does not inherently forward L2 broadcast to all peers.Therefore, it is NBMA by default. Verification / Alternative check: Classic certification texts state “Frame Relay is NBMA,” guiding choices like OSPF point-to-multipoint or static neighbor settings. Why Other Options Are Wrong: Point-to-point: Only if configured as such per PVC; not the default. Broadcast multi-access: Contradicts NBMA nature. Non-broadcast multipoint: Terminology mix; standard term is NBMA. Ring: Not applicable. Common Pitfalls: Assuming Ethernet-like broadcast behavior; forgetting to adapt routing protocol settings for NBMA. Final Answer: Non-broadcast multi-access

Question 2

Choosing a scalable WAN for many branches: HQ has one router interface left and must connect six existing branches (plus six more soon) economically. Which WAN technology best fits a hub-and-spoke design with many spokes from a single HQ interface?

Accepted Answer

Introduction / Context: When many branches need to connect to a single HQ, classic hub-and-spoke WANs used technologies that allowed multiple logical circuits over one physical interface, reducing port costs at HQ. Given Data / Assumptions: One HQ router interface available. Six current branches; more expected. Goal: economic scalability from one physical port. Concept / Approach: Frame Relay supports multiple permanent virtual circuits (PVCs) on a single physical interface using multiple DLCIs. This lets you connect many branch spokes to one HQ hub without additional physical interfaces. (In modern networks, MPLS L3VPN plays a similar role, but classic exam answers emphasize Frame Relay.) Step-by-Step Solution: Identify need: many logical links from one physical port.Match feature: Frame Relay PVCs/DLCIs over a single serial interface.Conclude Frame Relay as the intended answer for a hub-and-spoke design. Verification / Alternative check: Traditional CCNA/CCNP materials present Frame Relay as the scalable choice compared to multiple PPP/HDLC leased lines. Why Other Options Are Wrong: PPP/HDLC: One link per interface per circuit; not scalable with one port. ISDN: Dial-up, expensive per minute, not suited for many permanent spokes. MPLS L3VPN: Viable modern option, but not among the provided classic solutions; also managed by providers. Common Pitfalls: Thinking more physical ports are required; overlooking virtual circuit multiplexing. Final Answer: Frame Relay

Question 3

Remote dial-up services choice: Acme needs remote employees to dial in; the solution must support multiple routed protocols, user authentication, and callback to reduce long-distance charges. Which protocol is the best fit?

Accepted Answer

Introduction / Context: Dial-up remote access historically relied on protocols that could carry multiple Network layer protocols, authenticate users, and offer enhancements like callback. Point-to-Point Protocol (PPP) became the de-facto standard. Given Data / Assumptions: Remote employees connect over dial-up. Multiple routed protocols must be supported. User authentication is required. Callback support desired to control toll charges. Concept / Approach: PPP provides Link Control Protocol (LCP) for link setup and options (including callback) and Network Control Protocols (NCPs) for carrying multiple Layer-3 protocols (e.g., IPCP for IP, IPXCP for IPX back in the day). PPP also supports PAP and CHAP for authentication. Step-by-Step Solution: Map requirements to PPP features: multi-protocol via NCP, authentication via PAP/CHAP, and optional callback via LCP extensions.Eliminate technologies that do not meet all requirements.Select PPP as the comprehensive dial-up solution. Verification / Alternative check: Documentation for PPP lists multilink, authentication, encryption options, and callback control in various implementations. Why Other Options Are Wrong: 802.1: IEEE category, not a specific dial-up protocol. Frame Relay: WAN service, not dial-up RAS protocol. HDLC: Cisco proprietary on serial links; lacks standardized authentication/callback/NCP suite. PAP: Only an authentication method; does not define the whole data link. Common Pitfalls: Confusing PPP (the link protocol) with PAP/CHAP (authentication mechanisms used by PPP); assuming HDLC suffices for multi-protocol RAS. Final Answer: PPP

Question 4

WAN serial interfaces: Which encapsulation types can be configured on a Cisco serial interface? (Select the correct grouping from: Ethernet, Token Ring, HDLC, Frame Relay, PPP)

Accepted Answer

Introduction / Context: This networking question checks familiarity with data link encapsulations supported on routed serial interfaces. Knowing which technologies are valid on serial links is essential for WAN configuration and troubleshooting. Given Data / Assumptions: You are configuring a Cisco serial interface for a WAN connection. Candidate encapsulations listed: Ethernet, Token Ring, HDLC, Frame Relay, PPP. Assume typical IOS on routers (not switches) and physical serial interfaces (synchronous). Concept / Approach: Serial WAN interfaces operate at Layer 2 with WAN-focused encapsulations. On Cisco routers, the common serial encapsulations are HDLC (default), PPP, and Frame Relay. Ethernet and Token Ring are LAN technologies that require different physical interfaces and framing and are not configured as serial encapsulations. Step-by-Step Solution: Identify serial-friendly encapsulations: HDLC, PPP, Frame Relay are valid.Rule out LAN MAC-layer encapsulations: Ethernet and Token Ring are not serial encapsulations.Match to the option grouping that includes HDLC, Frame Relay, PPP → 3, 4 and 5. Verification / Alternative check: On a Cisco router interface, the command set includes 'encapsulation hdlc', 'encapsulation ppp', and 'encapsulation frame-relay'. There are no 'encapsulation ethernet' or 'encapsulation token-ring' commands for serial interfaces. Why Other Options Are Wrong: 1 and 4: Ethernet is not a serial encapsulation. 2 only: Token Ring is a LAN MAC, not used on serial. All of the above: Includes LAN encapsulations, which are invalid on serial. Common Pitfalls: Confusing physical media types with Layer 2 encapsulations and assuming any familiar LAN protocol can run over serial links. Final Answer: 3, 4 and 5

Question 5

Frame Relay point-to-point subinterfaces: When configuring point-to-point subinterfaces on a physical Frame Relay interface, which item must NOT be configured?

Accepted Answer

Introduction / Context: Point-to-point Frame Relay subinterfaces are a classic way to avoid split-horizon and simplify addressing in hub-and-spoke topologies. Correct placement of IP addressing and DLCIs is critical for proper operation. Given Data / Assumptions: Physical interface carries Frame Relay encapsulation. Subinterfaces are defined as point-to-point. Each subinterface binds to a single DLCI and has its own IP network. Concept / Approach: With Frame Relay subinterfaces, Layer 3 addressing belongs on the subinterface, not on the physical interface. The physical interface provides the Layer 2 service (Frame Relay encapsulation and LMI). Each point-to-point subinterface is treated like its own logical interface with a unique IP and a single DLCI mapping. Step-by-Step Solution: Enable Frame Relay on the physical interface (encapsulation frame-relay) → required.Create subinterfaces and set type point-to-point → required for p2p semantics.Assign a local DLCI under each subinterface → required to bind the PVC.Do NOT assign an IP to the physical interface because each subinterface requires its own IP. Therefore, the physical interface must have no IP address. Verification / Alternative check: Show run should display IP addresses under subinterfaces (e.g., Serial0/0.1, Serial0/0.2) and none under the parent interface; LMI runs on the parent. Why Other Options Are Wrong: Frame Relay encapsulation on the physical: Needed for the link-layer. Local DLCI on each subinterface: Required to identify the PVC. Subinterface type: Must be 'point-to-point' for p2p subinterfaces. Common Pitfalls: Accidentally configuring an IP on the physical interface causes addressing conflicts and breaks subinterface design. Final Answer: An IP address on the physical interface

Question 6

Layer 3 secure tunneling standard: Which option describes the industry-standard suite that secures data over IP networks at the OSI Network layer (Layer 3)?

Accepted Answer

Introduction / Context: Secure site-to-site and remote-access connectivity often relies on standards at Layer 3. The question differentiates between a generic concept (VPN) and the specific standardized protocol suite used to implement secure IP-layer protection. Given Data / Assumptions: OSI Network layer (Layer 3) focus. Looking for an industry-wide standard suite, not merely a service concept. Transport medium may be the public Internet or private IP networks. Concept / Approach: IP Security (IPSec) is a suite of protocols (AH, ESP, and related key management like IKE) providing confidentiality, integrity, and authentication at Layer 3. While VPN is the broader concept of creating private networks over shared infrastructure, IPSec is the standard mechanism used at the IP layer to realize that goal. Step-by-Step Solution: Eliminate non-security transport technologies: HDLC, Cable, xDSL are link access technologies.Identify the security suite at Layer 3: IPSec meets the requirement (AH/ESP, IKE).Note that 'VPN' is a service concept; the question asks for the 'suite of protocols' → IPSec. Verification / Alternative check: Standards documents define IPSec operating at the IP layer, independent of applications, protecting any IP traffic. Why Other Options Are Wrong: VPN: A concept; can be implemented via IPSec, SSL/TLS, GRE+IPSec, etc. HDLC/Cable/xDSL: Physical/link-layer technologies without built-in IP-layer security suite. Common Pitfalls: Equating the service name 'VPN' with a specific protocol suite. Always distinguish the concept from the implementing protocols. Final Answer: IPSec

Question 7

VPN concept: What term best describes creating private networks across the Internet that provide privacy and can tunnel non-TCP/IP protocols?

Accepted Answer

Introduction / Context: This item distinguishes the general concept of Virtual Private Networks (VPNs) from specific technologies. A VPN is a method of using shared networks to provide private connectivity with encapsulation and security. Given Data / Assumptions: The network is the public Internet or other shared IP backbone. Goal: privacy and the ability to tunnel traffic, including potentially non-TCP/IP protocols depending on encapsulation. Concept / Approach: VPN is a broad term that encompasses technologies allowing creation of logical private links over public infrastructure. Features include tunneling (encapsulation), authentication, integrity, and often encryption. Implementations may use IPSec, SSL/TLS, GRE combined with IPSec, or MPLS-based L3VPN/L2VPNs, among others. Step-by-Step Solution: Identify the generic description: 'private networks across the Internet' and 'tunneling' → fits VPN.Exclude link/physical technologies (HDLC, Cable, xDSL) that do not inherently provide privacy over the Internet.Exclude IPSec since it is a specific suite; the question asks for the overall concept. Verification / Alternative check: Common deployments label SSL remote-access and IPSec site-to-site solutions collectively as VPNs; GRE tunnels can carry non-IP protocols over IP and are often protected by IPSec. Why Other Options Are Wrong: IPSec: A specific standard protocol suite, not the umbrella concept. HDLC/Cable/xDSL: Access technologies, not privacy/tunneling solutions across the Internet. Common Pitfalls: Confusing IPSec (implementation) with VPN (service/concept). The question wording favors the concept. Final Answer: VPN

Question 8

Interoperable Frame Relay to non-Cisco peer: Which encapsulation command should be set on the Cisco WAN interface?

Accepted Answer

Introduction / Context: Frame Relay encapsulation has vendor-specific and standards-based variants. When peering with non-Cisco devices, selecting the interoperable framing ensures successful data exchange. Given Data / Assumptions: You are configuring a Cisco router's serial interface for Frame Relay. The remote DTE is a non-Cisco device. Goal: choose an encapsulation that works across vendors. Concept / Approach: Cisco supports 'frame-relay cisco' (proprietary) and 'frame-relay ietf' (standards-based, RFC 1490/2427). For interoperability with other vendors, use the IETF encapsulation. ANSI or q933a refer to LMI types (signaling), not payload encapsulation. Step-by-Step Solution: Determine requirement: interoperate with non-Cisco → must use standards.Identify command for standards encapsulation: 'encapsulation frame-relay ietf'.Remember: LMI types (ansi, q933a, cisco) are configured separately with 'frame-relay lmi-type' if needed; they are not the encapsulation for user data. Verification / Alternative check: Show interface after configuration should display 'Encapsulation FRAME-RELAY IETF'; data then exchanges with third-party peers correctly. Why Other Options Are Wrong: frame-relay cisco: Proprietary encapsulation, not recommended for multi-vendor links. ansi/q933a: LMI types, not encapsulation. They govern status messages with the switch, not payload framing. Common Pitfalls: Confusing LMI type with encapsulation; both may need configuration, but only 'ietf' addresses the multi-vendor payload format. Final Answer: Router(config-if)#encapsulation frame-relay ietf

Question 9

Which technology encapsulates PPP frames inside Ethernet frames, preserving PPP features such as authentication, compression, and (optionally) encryption?

Accepted Answer

Introduction / Context: Broadband last-mile access often needs PPP's features (authentication, accounting) over Ethernet access networks. Different PPP variants adapt PPP framing to various lower layers. Given Data / Assumptions: PPP features desired: authentication (PAP/CHAP/EAP), compression, optional encryption. Access media is Ethernet on the customer side. Concept / Approach: PPP over Ethernet (PPPoE) wraps PPP frames inside Ethernet frames, allowing ISPs to leverage PPP's session and AAA capabilities over Ethernet distribution. PPPoA instead encapsulates PPP over ATM AAL5, not Ethernet. Plain PPP applies to point-to-point links (serial) without Ethernet framing. Step-by-Step Solution: Determine required lower layer: Ethernet → requires PPPoE.Verify features: PPPoE maintains PPP's authentication, compression, and session control.Exclude PPPoA and Token Ring based on medium mismatch. Verification / Alternative check: Client configuration shows a PPPoE session (PPPoE discovery and session stages), and RADIUS/MFA can be integrated through PPP authentication. Why Other Options Are Wrong: PPP: Not inside Ethernet by itself. PPPoA: Uses ATM, not Ethernet. Token Ring: Legacy LAN MAC protocol unrelated to PPP encapsulation. Common Pitfalls: Confusing PPPoA vs PPPoE due to similar names; always tie the suffix to the underlying medium (A for ATM, E for Ethernet). Final Answer: PPPoE

Question 10

DSL access and the DSLAM: Which access technology uses ATM as the Data Link protocol and terminates at a DSLAM in the provider network?

Accepted Answer

Introduction / Context: Understanding how last-mile technologies are delivered helps with selecting CPE, configuring encapsulations, and troubleshooting. The DSL Aggregation device in the provider network is the DSLAM. Given Data / Assumptions: We are looking for a technology that commonly uses ATM at Layer 2. Provider infrastructure terminates customer loops on a DSLAM (Digital Subscriber Line Access Multiplexer). Concept / Approach: Many xDSL variants (especially ADSL) historically used ATM over the copper loop, with PVCs from the CPE to the DSLAM/BRAS. PPPoE or PPPoA may run on top, but the underlying aggregation at Layer 2 is ATM toward and within the access network. Step-by-Step Solution: Associate 'DSLAM' with DSL access networks.Recognize ATM as common Data Link in DSL backhaul and aggregation.Exclude Frame Relay, T1, PPPoE, and Wireless as they do not define the DSL/DSLAM ATM aggregation model. Verification / Alternative check: Provider documentation of ADSL often references ATM PVCs (VPI/VCI) parameters on modems/routers, confirming ATM usage beneath PPPoE/PPPoA. Why Other Options Are Wrong: PPPoE: A session protocol that can run over DSL, not the access medium itself. Frame Relay/T1: Different WAN services not associated with DSLAMs. Wireless: Not terminated on DSLAMs and not necessarily ATM-based. Common Pitfalls: Confusing PPPoE (session) with the physical/media technology (DSL). DSLAM is a strong hint pointing directly to DSL. Final Answer: DSL

Question 11

Static Frame Relay addressing: If Inverse ARP is not operational, which command must be configured to ensure Layer 3 connectivity over Frame Relay?

Accepted Answer

Introduction / Context: Inverse ARP dynamically discovers Layer 3 next-hop addresses from Frame Relay DLCIs. When it fails or is disabled (e.g., point-to-point subinterfaces, security policies), you must configure static mappings to maintain connectivity. Given Data / Assumptions: Frame Relay network with known DLCIs. Inverse ARP is not functioning. Goal: Bind Layer 3 addresses to DLCIs manually. Concept / Approach: The 'frame-relay map' command statically maps a Layer 3 protocol and address (e.g., IP 10.1.1.2) to a DLCI and can specify broadcast capability. LMI type selection (ansi, cisco, q933a) affects signaling, not address resolution. There is no 'frame-relay arp' command for this purpose. Step-by-Step Solution: Identify need: without Inverse ARP, the router lacks IP-to-DLCI bindings.Use 'frame-relay map ip broadcast' on the appropriate interface or subinterface.Verify mapping with 'show frame-relay map' and test reachability with ping. Verification / Alternative check: After configuring a static map, 'show frame-relay map' should display the IP–DLCI association as static; routing adjacency (if any) should form successfully. Why Other Options Are Wrong: frame-relay arp: Not a valid method for static IP-to-DLCI mappings. frame-relay interface-dci: Invalid syntax (likely typo for 'dlci'). frame-relay lmi-type: Sets LMI signaling type; does not create Layer 3 mappings. Common Pitfalls: Forgetting the 'broadcast' keyword, which is necessary for multicast/broadcast packets (e.g., routing protocols) to traverse the PVC. Final Answer: frame-relay map

Question 12

Frame Relay WAN clocking on a DTE interface When a router is connected to a Frame Relay wide area network (WAN) using a serial DTE (Data Terminal Equipment) interface, how is the clock rate for the link determined?

Accepted Answer

Introduction / Context: On serial WAN links, one side provides clocking (timing) and the other side follows that timing. In Frame Relay service from a carrier, the customer premises router typically connects via a CSU/DSU (Channel Service Unit/Data Service Unit). Understanding who provides the clock is essential for stable, error-free communications and to avoid slips or framing errors. Given Data / Assumptions: The router interface is configured as DTE on a Frame Relay WAN. A carrier-provided CSU/DSU or provider edge device is present. The link uses synchronous serial signaling that requires a reference clock. Concept / Approach: In a service-provider-provided WAN, the DCE side (CSU/DSU or provider edge) generates the line clock. The customer router, acting as DTE, recovers timing from the carrier and does not set its own clock rate. The IOS clock rate command is only used when the router is acting as DCE (for example, lab back-to-back serial connections). Step-by-Step Solution: Identify device roles: CSU/DSU = DCE, customer router = DTE.DCE generates and supplies clock; DTE receives and uses that clock.Confirm that no clock rate command is required on the DTE interface.Validate status with show controllers serial (should show DTE). Verification / Alternative check: On Cisco IOS, show controllers serial reveals DTE/DCE. If the router detects DTE, the clock rate command is not accepted or has no effect; timing originates from the CSU/DSU. Why Other Options Are Wrong: By the far end router: routers as DTEs do not provide network timing to each other through the carrier cloud. By the clock rate command: used only when the interface is DCE (for example, lab cable), not on a Frame Relay DTE link. By the Physical layer bit stream timing: vague; the Physical layer timing ultimately comes from the DCE (CSU/DSU), which is precisely option A. Negotiated by LCP during PPP setup: PPP authentication/negotiation does not set physical clocking. Common Pitfalls: Trying to set clock rate on a DTE interface; it will not solve timing issues. Confusing DCE/DTE roles; only the DCE supplies clock. Final Answer: Supplied by the CSU/DSU

Question 13

Seeing CHAP authentication live Which Cisco IOS command displays the CHAP authentication process as it occurs between two routers?

Accepted Answer

Introduction / Context: When troubleshooting PPP links, it is often necessary to observe authentication events in real time. CHAP (Challenge-Handshake Authentication Protocol) is supported over PPP and provides a secure challenge-response. Cisco IOS offers debug commands to watch the negotiation unfold, which is invaluable for diagnosing mismatched usernames, secrets, or hostname issues. Given Data / Assumptions: The link uses PPP encapsulation. Routers are configured for CHAP authentication. We want to see the authentication conversation as it happens. Concept / Approach: The IOS command debug ppp authentication prints live messages showing CHAP challenges, responses, and results (success or failure). It also shows PAP if configured. show commands display static summaries and interface status but do not provide live, event-by-event details the way debug does. Step-by-Step Solution: Enter privileged EXEC mode.Enable logging to the console or monitor session as needed.Issue: debug ppp authentication.Initiate the PPP session or flap the interface to trigger authentication; read the outputs. Verification / Alternative check: Use undebug all or no debug all to stop debugging after collecting evidence. For additional depth, debug ppp negotiation shows LCP/NCP events. Why Other Options Are Wrong: show chap authentication / show ppp negotiation detail: not valid IOS commands. show interface serial 0: provides status, not live authentication exchanges. debug chap authentication: not the standard IOS keyword; CHAP events are included under debug ppp authentication. Common Pitfalls: Running debugs on busy devices can be CPU intensive; use during maintenance windows or with care. For CHAP, the router's hostname and remote username must align; mismatches cause failures revealed by this debug. Final Answer: debug ppp authentication

Question 14

Frame Relay split horizon solution In a hub-and-spoke Frame Relay network, how should the router be configured to avoid split horizon blocking of routing updates?

Accepted Answer

Introduction / Context: Split horizon prevents a router from advertising a route back out the interface on which it was learned. In hub-and-spoke Frame Relay topologies using a single multipoint interface, split horizon can block spoke-to-spoke reachability for distance-vector protocols like RIP and EIGRP (when classic rules apply). The industry-standard fix is subinterfaces. Given Data / Assumptions: Frame Relay hub-and-spoke with multiple PVCs. Distance-vector or DV-like behavior that honors split horizon. Goal: allow proper routing updates to all spokes. Concept / Approach: Configure point-to-point subinterfaces, one per PVC, each with its own unique subnet and DLCI. This design treats each PVC as a separate interface, disabling split horizon constraints across spokes and allowing clean summarization and access control. It also improves broadcast/multicast handling for routing protocols. Step-by-Step Solution: Under Serial interface, create subinterfaces: interface s0/0.1 point-to-point, s0/0.2 point-to-point, etc.Bind each subinterface to a single DLCI with frame-relay interface-dlci .Assign a unique IP subnet to each subinterface.Enable the routing protocol; spokes now receive updates properly. Verification / Alternative check: Use show frame-relay pvc to verify PVCs, and confirm routing tables on spokes include all remote networks without manual split-horizon workarounds. Why Other Options Are Wrong: Option B is conceptually similar but vague; the concrete, canonical method is distinct point-to-point subinterfaces per PVC with unique subnets. Option C places many subinterfaces in the same subnet, reintroducing ambiguity and split-horizon issues. Option D multipoint subinterface with many PVCs retains split-horizon concerns. Inverse ARP suppression does not solve split horizon. Common Pitfalls: Leaving hub as multipoint with a single subnet; updates will not propagate between spokes. Forgetting to change from IETF to Cisco encapsulation as appropriate across vendors. Final Answer: Configure a separate subinterface for each PVC with a unique DLCI and subnet assigned to the subinterface.

Question 15

Exploring show frame-relay options When you enter the Cisco IOS command show frame-relay ?, which of the following subcommands are available: dlci, neighbors, lmi, pvc, map?

Accepted Answer

Introduction / Context: Knowing the correct IOS subcommands speeds up Frame Relay troubleshooting. The show frame-relay family exposes Local Management Interface (LMI) status, Permanent Virtual Circuit (PVC) health, and address maps. Recognizing legitimate subcommands avoids parser errors and focuses your diagnostics. Given Data / Assumptions: Candidate tokens listed: dlci (1), neighbors (2), lmi (3), pvc (4), map (5). We are using common Cisco IOS releases. We want valid subcommands following show frame-relay ?. Concept / Approach: Standard, widely supported subcommands include show frame-relay lmi, show frame-relay pvc, and show frame-relay map. These reveal LMI counters, PVC states, and the Layer-3-to-DLCI mappings respectively. Tokens like dlci and neighbors are not standard subcommands in this syntax across classic IOS images. Step-by-Step Solution: Enter privileged EXEC mode.Type: show frame-relay ?Observe valid options such as lmi, pvc, map and choose the one for your task.Run the chosen command and interpret results (for example, PVC ACTIVE/INACTIVE). Verification / Alternative check: Use context-sensitive help on a live device to confirm available options; you will consistently find lmi, pvc, and map. Some platforms may offer additional device-specific items, but dlci and neighbors are not standard here. Why Other Options Are Wrong: “1 only” or “2 and 4”: include invalid tokens. “All of the above”: incorrectly includes unsupported tokens. “4 and 5 only”: omits LMI, which is valid and commonly used. Common Pitfalls: Confusing show frame-relay map (L3-to-DLCI mapping) with routing adjacency tables. Ignoring LMI counters that quickly reveal link health and mismatched types. Final Answer: 3, 4 and 5

Wide Area Networks Questions