Visit here for our full Cisco 350-501 exam dumps and practice test questions.
Question 46:
What is the primary purpose of MPLS Traffic Engineering Fast Reroute (FRR)?
A) To provide load balancing
B) To enable sub-50 millisecond protection switching for link and node failures
C) To reduce bandwidth consumption
D) To simplify routing configurations
Answer: B
Explanation:
MPLS Traffic Engineering Fast Reroute provides sub-50 millisecond protection switching for link and node failures by pre-computing and pre-signaling backup Label Switched Paths that activate immediately when primary paths fail. This protection mechanism is critical for service provider networks carrying real-time applications like voice and video that cannot tolerate the convergence delays associated with traditional routing protocol recovery.
FRR operates through two primary protection methods including link protection where backup tunnels protect individual links by routing around failed links to next-hop routers, and node protection where backup tunnels bypass entire nodes providing protection against router failures in addition to link failures. Node protection offers superior resiliency by maintaining connectivity even when intermediate routers fail completely, though it requires more complex topology and may consume additional bandwidth.
The protection mechanism works through pre-established backup tunnels created during normal operation before failures occur. Point of Local Repair routers detect failures immediately through physical layer notifications or fast hello protocols, switch traffic to pre-computed backup paths within tens of milliseconds without waiting for control plane convergence, and signal failure information to ingress routers which can then establish new primary paths while backup paths carry traffic. This local repair ensures minimal packet loss during failures.
Configuration involves enabling FRR on primary tunnel interfaces, configuring backup tunnel attributes including bandwidth and priority, associating backup tunnels with protected interfaces, and optionally configuring node protection requiring additional signaling extensions. The RSVP-TE protocol signals backup path requirements using facility backup or one-to-one backup methods. Facility backup uses a single backup tunnel to protect multiple primary tunnels improving scalability.
FRR interacts with path computation ensuring backup paths avoid facilities that primary paths traverse, bandwidth admission control reserving bandwidth for backup tunnels, and failure notification mechanisms detecting failures rapidly through Bidirectional Forwarding Detection or other fast failure detection protocols. Proper design ensures backup paths have sufficient bandwidth and meet latency requirements when activated.
Load balancing (option A) uses different mechanisms, bandwidth reduction (option C) isn’t the goal, and configuration simplicity (option D) isn’t the purpose. Fast Reroute specifically provides rapid protection switching for failures.
Question 47:
Which BGP attribute is used to influence outbound traffic path selection in a multi-homed network?
A) Origin
B) AS_PATH prepending
C) Next-hop
D) Weight
Answer: B
Explanation:
AS_PATH prepending is the primary BGP attribute manipulation technique used to influence outbound traffic path selection in multi-homed networks by making certain routes appear less preferable to external autonomous systems. This traffic engineering method enables service providers and enterprises to control which upstream provider or peering point remote autonomous systems use when sending traffic toward the local network.
The mechanism operates by artificially lengthening the AS_PATH attribute for routes advertised to specific neighbors through repeatedly prepending the local AS number in the path. Since BGP prefers routes with shorter AS paths when other attributes are equal, prepending makes routes less attractive to receiving routers. The prepending can be applied selectively to specific prefixes, specific neighbors, or conditionally based on routing policies enabling granular traffic engineering control.
Common use cases include balancing inbound traffic across multiple upstream providers where primary circuits advertise routes with normal AS paths while backup circuits advertise routes with prepended paths discouraging their use except during primary failures, implementing active-standby configurations for disaster recovery links, steering traffic away from congested or expensive transit links, and working around asymmetric routing problems by influencing return path selection.
Configuration involves route maps or routing policies that match prefixes or BGP communities and apply AS_PATH prepending before advertising to external BGP peers. The prepend count determines influence strength with more repetitions creating stronger preference against the path. Typical deployments use 1-3 prepends for minor preference adjustments and 4-6 prepends for significant depreference. Excessive prepending beyond 6-8 repetitions generally provides diminishing returns and can cause operational issues.
Limitations include that AS_PATH prepending only influences path selection at autonomous systems that receive the advertisements, intermediate autonomous systems may override preferences with local policies, and some networks filter routes with excessively long AS paths viewing them as anomalous. Prepending works best when coordinated with upstream providers who honor the preference signals and don’t override with local policy.
Origin (option A) indicates route source, Next-hop (option C) specifies forwarding address, and Weight (option D) is Cisco-specific local preference. AS_PATH prepending specifically influences external path selection.
Question 48:
What is the purpose of the BGP Local Preference attribute?
A) To influence inbound traffic from external peers
B) To determine the preferred exit point for outbound traffic within an autonomous system
C) To set route origin
D) To modify AS_PATH
Answer: B
Explanation:
BGP Local Preference attribute determines the preferred exit point for outbound traffic within an autonomous system by indicating which route should be used when multiple exit points offer paths to the same destination. This attribute is fundamental to traffic engineering within service provider and enterprise networks, enabling administrators to explicitly control which border router or upstream connection handles traffic for specific destinations.
The attribute operates as a well-known discretionary attribute that is exchanged between iBGP peers within the same autonomous system but is not propagated to eBGP peers in other autonomous systems. Routes with higher Local Preference values are preferred over routes with lower values during BGP best path selection process. The default Local Preference value is 100 on Cisco routers, with higher values indicating more preferred paths.
Common deployment scenarios include preferring one upstream provider over another for cost optimization where expensive transit links receive lower Local Preference than cheaper alternatives, implementing primary and backup egress configurations where primary paths have higher preference, balancing outbound traffic across multiple exit points by setting different preferences for different destination prefixes, and influencing traffic to use specific peering interconnections for performance optimization.
Configuration typically involves inbound route maps on border routers that set Local Preference based on various criteria including source neighbor identifying which upstream provider advertised the route, destination prefix or prefix-length for per-destination traffic engineering, BGP communities enabling remote sites to signal preferred paths, and AS_PATH characteristics identifying transit providers or path length. The modified Local Preference then propagates through iBGP to all routers in the autonomous system.
The attribute’s position in BGP best path selection algorithm is second only to Weight, evaluated after Weight but before AS_PATH length and other tie-breaking attributes. This high priority ensures Local Preference effectively controls outbound path selection. Proper use requires consistent iBGP mesh or route reflector infrastructure ensuring all routers receive Local Preference values.
Inbound traffic (option A) uses AS_PATH prepending or MED, Origin (option C) indicates route source, and AS_PATH modification (option D) is separate attribute. Local Preference specifically controls outbound path selection.
Question 49:
Which IS-IS protocol feature enables routing between different routing levels?
A) Adjacency
B) Route leaking
C) Flooding
D) Authentication
Answer: B
Explanation:
Route leaking in IS-IS enables routing between different levels of the two-level hierarchy by selectively redistributing routes from one level into another, typically leaking routes from Level 2 backbone into Level 1 areas. This feature is essential for providing reachability to external destinations for routers in Level 1 areas while maintaining the hierarchical scalability benefits of the two-level IS-IS architecture.
IS-IS hierarchical design consists of Level 1 areas similar to OSPF areas containing routers that maintain detailed topology within the area, and Level 2 backbone connecting Level 1 areas through routers that maintain inter-area routing information. By default, Level 1 routers route traffic destined outside their area toward the nearest Level 1-2 router using a default route, and Level 1-2 routers do not advertise specific Level 2 routes into Level 1 preventing detailed external routing information from flooding areas.
Route leaking breaks this default behavior by allowing specific Level 2 routes to be advertised into Level 1 areas. Common use cases include advertising external routes learned from BGP into Level 1 areas enabling optimal exit point selection for internet-bound traffic, advertising routes for data centers or service platforms allowing Level 1 routers to choose best paths, and providing redundancy where multiple Level 1-2 routers serve an area and specific routes influence which router Level 1 devices prefer.
Configuration involves enabling route leaking on Level 1-2 routers, specifying which Level 2 routes should leak into Level 1 using prefix lists or route policies, optionally modifying metric for leaked routes to influence path selection, and controlling which Level 1 areas receive leaked routes. Care must be taken to avoid excessive route leaking which undermines hierarchy benefits by increasing Level 1 link-state database size and flooding overhead.
Route leaking can also work in reverse where Level 1 routes leak into Level 2, though this is less common and typically used in specific migration or interconnection scenarios. Bidirectional leaking requires careful policy to prevent routing loops and suboptimal routing. Modern deployments often use IS-IS route leaking in conjunction with BGP for external routes and pure IS-IS for internal infrastructure.
Adjacency (option A) establishes neighbor relationships, Flooding (option C) distributes LSPs, and Authentication (option D) secures routing. Route leaking specifically enables inter-level routing.
Question 50:
What is the purpose of MPLS LDP session protection?
A) To encrypt label distribution protocol packets
B) To maintain LDP sessions during temporary link failures by using targeted LDP sessions
C) To prevent unauthorized label allocation
D) To compress LDP messages
Answer: B
Explanation:
MPLS LDP session protection maintains LDP sessions during temporary link failures by using targeted LDP sessions as backup communication paths between routers. This feature prevents LDP session teardown and label binding loss when direct physical connectivity between LDP peers fails temporarily, avoiding the label reconvergence delays that would otherwise occur when sessions reestablish.
The protection mechanism works by establishing targeted LDP sessions in addition to normal link LDP sessions. Targeted sessions use multi-hop TCP connections that can route through the IGP network rather than requiring direct physical connectivity. When the direct link between LDP peers fails, the targeted session continues operating using alternate paths through the network, maintaining label bindings and preventing session timeout. This allows LDP to ride out short-duration failures that the IGP routes around.
Configuration involves enabling session protection globally or for specific neighbors, setting a duration for how long to protect sessions before allowing timeout, configuring which peers should have protected sessions typically done for critical adjacencies or those prone to flapping, and ensuring IGP is configured to provide alternate paths between peers. The targeted session establishes during normal operation remaining idle while the link session handles label distribution.
Benefits include preventing traffic disruption during transient failures avoiding the label withdrawal and advertisement cycle that disrupts packet forwarding, reducing convergence time by eliminating LDP session re-establishment overhead, improving stability in networks with link quality issues or frequent maintenance events, and providing graceful degradation where MPLS forwarding continues even during physical topology changes as long as IGP converges.
Session protection is particularly valuable in service provider networks where MPLS VPN services, traffic engineering tunnels, or other MPLS-based services depend on stable label bindings. The feature complements IGP fast convergence and MPLS Traffic Engineering FRR by maintaining control plane stability during failures. Some deployments use session protection for all core adjacencies while others apply it selectively to critical links.
Encryption (option A) is separate security function, authorization (option C) uses different mechanisms, and compression (option D) isn’t applicable. Session protection specifically maintains sessions during link failures.
Question 51:
Which OSPF LSA type is used to advertise external routes into the OSPF domain?
A) Type 1 Router LSA
B) Type 2 Network LSA
C) Type 5 AS External LSA
D) Type 3 Summary LSA
Answer: C
Explanation:
Type 5 AS External LSA advertises external routes into the OSPF domain, carrying routing information for destinations outside the OSPF autonomous system such as routes learned from BGP, static routes, or other routing protocols. These LSAs are originated by Autonomous System Boundary Routers and flood throughout the OSPF domain except into stub areas, providing reachability information for external destinations to all OSPF routers.
The LSA structure contains critical information including the external destination network prefix and mask identifying the external route, the forwarding address specifying the next-hop for reaching the destination which can be the ASBR itself or an external next-hop, the external route type indicating Type 1 external routes where OSPF adds internal cost to external metric or Type 2 external routes where only external metric is considered, and the external metric representing the cost to reach the destination.
Route type selection affects path calculation where Type 1 external routes combine the OSPF internal cost to reach the ASBR with the external metric enabling consideration of internal path cost when selecting best external routes, while Type 2 external routes compare only the external metrics regardless of internal cost, using internal cost only as tiebreaker when external metrics are equal. Service providers typically use Type 2 for BGP routes to avoid internal topology changes affecting external route selection.
Type 5 LSAs propagate through regular OSPF areas but are blocked at stub, totally stubby, and NSSA area boundaries. NSSA areas use Type 7 LSAs for external routes within the area which convert to Type 5 at the NSSA ABR before propagating into regular areas. This area design enables limiting external route flooding in portions of the network while maintaining external reachability.
Configuration involves redistributing external routes into OSPF on ASBR routers, setting appropriate metrics and route types, optionally setting forwarding addresses for optimal routing, and applying route filtering to control which external routes advertise. Large service provider networks often use route summarization with Type 5 LSAs to reduce routing table and link-state database size.
Type 1 LSAs (option A) describe router links, Type 2 LSAs (option B) describe multi-access networks, and Type 3 LSAs (option D) describe inter-area routes. Type 5 LSAs specifically carry external routes.
Question 52:
What is the primary function of a Route Reflector in BGP?
A) To filter routes based on communities
B) To reduce the number of required iBGP peering sessions in large networks
C) To translate between IPv4 and IPv6
D) To aggregate routes
Answer: B
Explanation:
Route Reflectors reduce the number of required iBGP peering sessions in large networks by relaxing the full-mesh iBGP requirement, instead allowing route reflectors to receive routes from some iBGP peers and reflect them to other iBGP peers. This scalability solution addresses the n(n-1)/2 peering requirement of full-mesh iBGP which becomes unmanageable in networks with hundreds or thousands of routers.
The architecture introduces two roles where route reflectors are specially configured routers that reflect routes between clients, and route reflector clients are routers that peer with route reflectors rather than forming full mesh with all other iBGP routers. Clients need only peer with route reflectors which handle route distribution, dramatically reducing configuration complexity and TCP session overhead. Route reflectors typically peer with each other in full mesh for redundancy.
Route reflection operation follows specific rules including advertising routes learned from clients to all other clients and non-clients, advertising routes learned from non-clients to clients only, and preserving BGP attributes during reflection with specific cluster attributes added to prevent loops. The ORIGINATOR_ID and CLUSTER_LIST attributes track route reflection preventing routing loops where a route reflector receives back a route it reflected.
Design considerations include determining route reflector placement typically positioning them in core or central locations for optimal connectivity, planning redundancy using multiple route reflectors for availability with clients peering to multiple reflectors, organizing clients into clusters where each cluster has dedicated route reflectors, and preventing loops through proper cluster configuration and attribute checking.
Hierarchical designs implement multiple route reflection levels where regional route reflectors serve local clients and peer with backbone route reflectors creating scalable multi-level hierarchies. This approach supports very large service provider networks with tens of thousands of routers. Route reflectors often run on dedicated control plane hardware separate from forwarding path routers for stability.
Route filtering (option A) uses policies, protocol translation (option C) requires gateways, and aggregation (option D) uses summarization. Route Reflectors specifically provide iBGP scaling.
Question 53:
Which BGP path attribute takes precedence in the BGP best path selection algorithm?
A) AS_PATH length
B) Weight (Cisco-specific)
C) Origin
D) MED
Answer: B
Explanation:
Weight is the first attribute evaluated in Cisco’s BGP best path selection algorithm, taking precedence over all other path attributes when determining which route to install in the routing table. This Cisco-proprietary attribute is locally significant to the router where it is configured and is not advertised to any BGP peers, making it useful for local path preference without affecting other routers’ decisions.
The attribute ranges from 0 to 65535 with higher values indicating more preferred paths. Routes learned from BGP peers have default weight of 0 while routes originated locally by the router have default weight of 32768. Weight is commonly used to implement local routing policies that override all other BGP path selection criteria, ensuring specific paths are always preferred regardless of other attributes.
Weight configuration typically occurs through route maps applied to BGP neighbors or specific routes, enabling administrators to set weights based on various criteria including neighbor address to prefer routes from specific peers, destination prefix to route specific traffic through particular paths, BGP communities for policy-based routing, or AS_PATH characteristics to prefer certain transit providers. The weight manipulation affects only the local router’s forwarding decisions.
The complete BGP path selection algorithm evaluates attributes in order including Weight first (Cisco-specific, not evaluated on non-Cisco routers), Local Preference second for autonomous system-wide policy, AS_PATH length third preferring shorter paths, Origin fourth with IGP better than EGP better than incomplete, MED fifth for inter-AS link selection, preferring eBGP over iBGP routes, lowest IGP metric to next-hop, and finally router ID or neighbor address as tiebreakers.
Understanding attribute precedence is essential for effective BGP traffic engineering as earlier attributes in the selection algorithm override later attributes. Administrators must configure attributes with appropriate precedence to achieve desired routing behavior. Weight’s position at the beginning of the algorithm makes it powerful for local overrides but its local-only scope limits applicability to per-router policies.
AS_PATH (option A) is evaluated third, Origin (option C) is evaluated fourth, and MED (option D) is evaluated fifth. Weight specifically is first in Cisco’s path selection.
Question 54:
What is the purpose of MPLS VPN Route Distinguisher (RD)?
A) To encrypt VPN traffic
B) To create unique VPNv4 or VPNv6 addresses for overlapping customer prefixes
C) To determine routing protocol metrics
D) To establish MPLS tunnels
Answer: B
Explanation:
Route Distinguisher creates unique VPNv4 or VPNv6 addresses for potentially overlapping customer prefixes by prepending a 64-bit value to IPv4 or IPv6 addresses, converting them into globally unique address families. This mechanism is fundamental to MPLS Layer 3 VPN operation, enabling service providers to support multiple customers who may use identical private IP address spaces without conflicts in the provider’s routing infrastructure.
The RD structure consists of 64 bits formatted in several possible ways including ASN:nn format where a 2-byte AS number precedes a 4-byte number, IP:nn format where a 4-byte IP address precedes a 2-byte number, or 4-byte ASN:nn format for 4-byte AS numbers. The RD itself has no routing significance and only serves to create unique address space; routing policy is controlled by separate Route Target extended communities.
RD assignment strategies include unique RD per VRF ensuring every customer VPN instance has unique RD making all routes globally unique, unique RD per customer with same RD across all PE routers serving that customer enabling route summarization, or unique RD per PE router creating unique VPNv4 space per router. Each approach has tradeoffs between operational simplicity, troubleshooting clarity, and optimization capabilities.
In VPN operation, PE routers import customer routes into VRFs associating them with configured RDs to create VPNv4/VPNv6 routes, advertise these extended routes via MP-BGP to other PE routers, and at receiving PE routers convert VPNv4 routes back to IPv4 when placing in appropriate VRFs based on Route Target import policies. The RD enables this conversion process by maintaining uniqueness throughout the provider backbone.
Troubleshooting benefits from understanding RD operation as VPNv4 routes in BGP tables show the RD:prefix format enabling identification of which VRF and customer the route belongs to. Misconfigured RDs can cause routes from one customer to appear as different routes even when they represent the same prefix, leading to suboptimal forwarding or unreachability.
Encryption (option A) uses IPsec or other security protocols, metrics (option C) use routing protocol attributes, and tunnel establishment (option D) uses RSVP-TE or LDP. RD specifically creates unique VPN address space.
Question 55:
Which mechanism does Segment Routing use for forwarding packets?
A) IP address lookup
B) Label stack with segment identifiers
C) MAC address forwarding
D) Port-based forwarding
Answer: B
Explanation:
Segment Routing uses a label stack with segment identifiers to forward packets through the network along explicitly defined paths. This forwarding mechanism enables source routing where the ingress router determines the complete path by stacking labels representing different segments, and intermediate routers simply forward based on the top label without maintaining per-flow state or signaling protocols.
Segment Routing architecture defines segments as instructions encoded in labels where adjacency segments represent specific links between routers for strict forwarding paths, prefix segments represent destination prefixes enabling forwarding to specific routers via shortest path, and anycast segments represent groups of routers for load balancing or service insertion. The segment list in the label stack defines the complete path the packet follows.
Forwarding operation follows MPLS dataplane mechanics where the ingress router imposes a label stack representing the desired path through the network, transit routers perform top label lookup and swap forwarding standard MPLS operations, and at segment endpoints routers pop labels exposing next segment instructions. This stateless operation requires no per-tunnel state in the network core simplifying operations and improving scalability.
Label stack construction enables sophisticated traffic engineering where multiple labels represent waypoints through the network, creating paths that avoid congestion or traverse specific network elements, implementing strict or loose source routes depending on segment type granularity, and inserting service segments directing traffic through firewalls, load balancers, or optimization appliances. The label stack essentially programs the forwarding path.
Segment Routing benefits include eliminating signaling protocols like RSVP-TE reducing control plane overhead, removing per-tunnel state from transit routers improving scalability, enabling instant path setup without signaling delays, and simplifying traffic engineering through source-based path control. The architecture is foundational to modern service provider networks supporting 5G slicing, network automation, and application-aware networking.
IP lookup (option A) is traditional routing, MAC forwarding (option C) is layer 2 switching, and port-based forwarding (option D) is basic switching. Label stacks specifically implement Segment Routing forwarding.
Question 56:
What is the primary purpose of BGP Graceful Restart?
A) To speed up BGP convergence
B) To maintain forwarding during BGP control plane restart without disrupting traffic
C) To reduce routing table size
D) To filter BGP updates
Answer: B
Explanation:
BGP Graceful Restart maintains packet forwarding during BGP control plane restarts without disrupting traffic flow by preserving the forwarding table while the control plane recovers. This mechanism is critical for service provider networks where routing protocol restarts due to software upgrades, process restarts, or route processor switchovers must not cause traffic outages affecting customer services.
The graceful restart process involves coordination between restarting and helper routers. When a router begins graceful restart, it notifies BGP peers through graceful restart capability exchange, helper peers preserve routes learned from the restarting router and continue forwarding using existing forwarding entries, the restarting router maintains its forwarding table from before restart, and after restart completes, routers exchange routing information converging to consistent state. This cooperation prevents blackholing traffic during control plane unavailability.
Capability negotiation occurs during BGP session establishment where routers advertise graceful restart capability including supported address families, restart time indicating maximum time the router needs to restart, and restart flags indicating graceful restart awareness. Both peers must support graceful restart for the mechanism to activate. The capability advertisement enables helper routers to distinguish between graceful and non-graceful failures.
Restart timers control the graceful restart process including restart time advertised by the restarting router indicating how long helpers should wait, stale route timer controlling how long helpers retain routes from the restarting router, and deferral timer on the restarting router delaying routing updates until complete BGP session state is recovered. Proper timer configuration balances between allowing sufficient restart time and detecting true failures requiring immediate reconvergence.
Graceful restart limitations include dependence on forwarding plane hardware state preservation which may not survive all failure types, potential for stale routes if restart exceeds timers, and requirement for peer support limiting deployment in mixed vendor environments. Non-Stop Forwarding extends graceful restart concepts providing similar benefits with improved reliability in platforms supporting stateful switchover.
Fast convergence (option A) uses different mechanisms, table size reduction (option C) uses summarization, and filtering (option D) uses policies. Graceful Restart specifically maintains forwarding during control plane restart.
Question 57:
Which IS-IS packet type is used to discover neighbors and establish adjacencies?
A) Link State PDU
B) Complete Sequence Number PDU
C) Hello PDU
D) Partial Sequence Number PDU
Answer: C
Explanation:
Hello PDUs are used in IS-IS to discover neighbors and establish adjacencies between routers. These packets are exchanged periodically on all IS-IS enabled interfaces allowing routers to detect directly connected neighbors, verify bidirectional communication, and maintain adjacency state. Hello PDUs are fundamental to IS-IS operation as they establish the neighbor relationships necessary for subsequent link-state database synchronization and routing information exchange.
IS-IS defines multiple Hello PDU types for different network environments including Level 1 LAN Hello for discovering Level 1 neighbors on broadcast networks, Level 2 LAN Hello for discovering Level 2 neighbors on broadcast networks, and Point-to-Point Hello for discovering neighbors on point-to-point links. The distinction between Hello types enables IS-IS’s two-level hierarchy where routers form appropriate adjacency levels based on configuration and network design.
Hello packet contents include critical information for adjacency establishment including the source system ID uniquely identifying the sending router, circuit ID identifying the link, holding time indicating how long neighbors should maintain the adjacency without receiving subsequent Hellos, priority value for designated router election on broadcast networks, and supported address families indicating IPv4, IPv6, or both. Area addresses in Hello packets verify that neighbors belong to compatible areas.
Adjacency state machines track neighbor relationships through states including Down when no Hellos are received, Init when unidirectional communication is detected, and Up when bidirectional communication is confirmed. On broadcast networks, additional states support designated router election. The adjacency must reach Up state before link-state information exchange begins. Adjacency establishment time affects network convergence with faster Hello timers enabling quicker failure detection but generating more control traffic.
Hello intervals and multipliers are configurable parameters balancing between fast failure detection and control overhead. Typical deployments use 10-second Hello intervals with 3x multipliers resulting in 30-second hold times, though critical links may use subsecond Hello intervals with BFD for rapid failure detection. Aggressive Hello timers combined with fast SPF computations enable subsecond convergence in modern IS-IS implementations.
LSPs (option A) carry link-state information, CSNPs (option B) synchronize databases, and PSNPs (option D) acknowledge LSPs. Hello PDUs specifically establish adjacencies.
Question 58:
What is the purpose of MPLS Penultimate Hop Popping (PHP)?
A) To add an additional label
B) To remove the MPLS label at the second-to-last router before the destination
C) To encrypt MPLS packets
D) To change label values
Answer: B
Explanation:
Penultimate Hop Popping removes the MPLS label at the second-to-last router in the Label Switched Path, one hop before the egress Label Edge Router, reducing processing burden on the egress router by eliminating the need for it to perform both label lookup and IP lookup for the same packet. This optimization improves egress router performance particularly important for high-capacity edge routers handling large traffic volumes.
PHP operation occurs when the penultimate router receives a packet with a label, performs label lookup discovering the label maps to the directly connected egress router, pops the label exposing the IP packet, and forwards the IP packet to the egress router which performs only IP forwarding lookup. This contrasts with traditional label switching where every router including the egress performs label operations before accessing the IP header.
Label distribution signaling indicates PHP capability through implicit null label advertisement where egress routers advertise the special implicit null label value instead of a regular label for their connected prefixes. When penultimate routers receive implicit null labels in label bindings, they understand that PHP should occur and configure forwarding to pop the label before forwarding. The implicit null label never actually appears in forwarded packets.
PHP scenarios include standard MPLS forwarding where it’s typically enabled by default for optimal performance, MPLS VPN egress where the PE router benefits from reduced lookup operations, and traffic engineering tunnel endpoints where PHP reduces processing on tunnel termination routers. Some deployments disable PHP using explicit null labels when egress routers require MPLS QoS information for proper handling of IP packets.
Explicit null labels serve as PHP alternatives in scenarios requiring the egress router to see MPLS headers for QoS marking or when TTL propagation must occur. The explicit null label forces a label lookup at the egress router but still identifies the packet as local improving processing compared to arbitrary label values. Service providers choose between implicit and explicit null based on operational requirements.
Adding labels (option A) occurs at ingress, encryption (option C) is separate function, and label swapping (option D) occurs at transit hops. PHP specifically removes labels at penultimate routers.
Question 59:
Which OSPF area type blocks external LSAs but allows summary LSAs?
A) Backbone area
B) Standard area
C) Stub area
D) Totally stubby area
Answer: C
Explanation:
Stub areas block Type 5 AS External LSAs from flooding into the area while still allowing Type 3 Summary LSAs to provide inter-area routing information. This area type reduces link-state database size and SPF computation overhead in areas that don’t require complete external routing information, improving router performance and reducing memory requirements while maintaining full connectivity through default routing to external destinations.
The stub area design principle recognizes that many areas, particularly those at network edges or with stub characteristics containing primarily user access networks, don’t benefit from complete external routing information and can route all external traffic through a default route to Area Border Routers. By blocking external LSAs, routers in stub areas maintain smaller link-state databases focusing on intra-area topology and inter-area summary routes.
Area Border Routers generate a Type 3 default route LSA into stub areas replacing the blocked external routes. This default route enables stub area routers to reach external destinations by forwarding to the ABR which has complete routing information. The default route cost can be configured on the ABR to influence which ABR stub area routers prefer when multiple ABRs serve an area.
Configuration requires enabling stub area mode on all routers within the area including internal routers and ABRs. Mismatched configuration where some routers are configured for stub and others are not prevents adjacency formation protecting against routing inconsistencies. Stub areas cannot contain ASBRs since external route origination is incompatible with blocking external LSAs.
Stub area variants include basic stub areas allowing summary LSAs and generating default route, totally stubby areas (Cisco proprietary) blocking both external and summary LSAs providing maximum link-state database reduction, and Not-So-Stubby Areas allowing external routes within the area while blocking external routes from the OSPF domain backbone. Each variant addresses specific network design requirements.
Backbone (option A) and standard areas (option B) allow all LSA types, and totally stubby areas (option D) also block summary LSAs. Stub areas specifically block external LSAs while allowing summaries.
Question 60:
What is the primary purpose of BGP Route Refresh capability?
A) To restart BGP sessions
B) To request updated routing information from peers without resetting the BGP session
C) To filter routes
D) To aggregate routes
Answer: B
Explanation:
BGP Route Refresh capability enables routers to request updated routing information from BGP peers without tearing down and reestablishing the BGP session. This capability is essential for operational flexibility, allowing administrators to modify import or export policies and immediately apply them to existing BGP sessions without the traffic disruption and convergence delays associated with session resets.
Prior to route refresh capability, any BGP policy change required either resetting the BGP session causing complete route withdrawal and re-advertisement with associated traffic disruption, or using soft reconfiguration inbound which stored received routes before policy application consuming significant memory. Route refresh capability provides a lightweight alternative where routers simply request peers to resend their routing advertisements.
The refresh process involves the requesting router sending a Route Refresh message to its peer specifying which address family requires refresh, the peer responding by resending all routes for the requested address family as if the session just established, and the requesting router applying current policies to the received routes updating its routing table accordingly. The entire process occurs without affecting the TCP session or causing route withdrawals.
Common use cases include applying modified import policies after changing route maps or prefix lists allowing immediate activation without session disruption, implementing export policy changes where route refresh requests enable quick validation, troubleshooting routing issues by refreshing routes to observe policy behavior, and operational procedures during maintenance windows where route refresh provides controlled route updates without full convergence events.