Visit here for our full Juniper JN0-664 exam dumps and practice test questions.
Question 46
Which BGP attribute is used to prevent routing loops in AS confederations?
A) AS_PATH
B) AS_CONFED_SEQUENCE
C) LOCAL_PREF
D) ORIGINATOR_ID
Answer: B
Explanation:
The AS_CONFED_SEQUENCE attribute is specifically used in BGP confederations to track the path through confederation sub-autonomous systems and prevent routing loops within the confederation structure. This attribute functions similarly to the standard AS_PATH attribute but operates within the confederation boundary, recording the sequence of member autonomous systems that a route has traversed without exposing internal confederation structure to external peers.
When a confederation member AS advertises routes to another member AS within the same confederation, it prepends its member AS number to the AS_CONFED_SEQUENCE attribute rather than the regular AS_PATH. This allows BGP speakers within the confederation to detect and reject routes that have already passed through their own member AS, preventing loops. The confederation structure appears as a single AS to external BGP peers, maintaining the abstraction while providing internal loop prevention.
The AS_CONFED_SEQUENCE attribute is removed when routes are advertised to external BGP peers outside the confederation, replaced by the confederation identifier in the standard AS_PATH attribute. This removal ensures that the internal confederation structure remains hidden from the external internet while standard AS_PATH loop prevention mechanisms apply to inter-AS routing. Within the confederation, both AS_CONFED_SEQUENCE and AS_CONFED_SET attributes may be present.
The standard AS_PATH attribute prevents loops between true autonomous systems rather than within confederations. LOCAL_PREF influences path selection within an AS but does not prevent loops. ORIGINATOR_ID is used in route reflector environments for loop prevention. AS_CONFED_SEQUENCE specifically addresses loop prevention within the confederation member AS structure.
Question 47
In Junos OS, which routing policy action causes the router to evaluate the next term in the policy?
A) accept
B) reject
C) next term
D) No action specified
Answer: D
Explanation:
When no explicit action is specified in a routing policy term, Junos OS continues evaluating subsequent terms in the policy, allowing for complex multi-stage policy logic where multiple terms can match and modify a route before a final acceptance or rejection decision is made. This default behavior differs from some other routing platforms and enables flexible policy construction where route attributes can be modified incrementally through multiple matching terms.
A routing policy term consists of match conditions and actions. When a route matches the conditions in a term but the term contains only modification actions like setting local preference or community attributes without an explicit accept or reject statement, the route continues to the next term with its modified attributes. This allows building policies where early terms classify and tag routes while later terms make final forwarding decisions based on those classifications.
This behavior enables sophisticated policy designs such as applying different modifications to routes based on multiple criteria, implementing hierarchical policy structures where general rules are applied first and specific exceptions later, and creating modular reusable policy components that can be combined. The implicit continuation ensures that routes are not accidentally accepted or rejected without explicit intent.
The accept action terminates policy evaluation and accepts the route into the routing table. The reject action terminates evaluation and discards the route. While next term exists as an explicit action, the default behavior when no action is specified achieves the same result. Understanding this implicit continuation is essential for constructing correct routing policies that avoid unintended route acceptance or rejection.
Question 48
What is the purpose of the MPLS explicit null label?
A) To indicate that no label should be pushed
B) To preserve QoS information during PHP
C) To signal an error condition
D) To indicate the end of the label stack
Answer: B
Explanation:
The MPLS explicit null label preserves quality of service information encoded in the MPLS experimental bits during penultimate hop popping operations, ensuring that QoS classifications are maintained through the entire label switched path including the final hop. When penultimate hop popping is used, the second-to-last router pops the transport label before forwarding the packet to the egress router, potentially losing QoS markings if the packet becomes a pure IP packet.
Explicit null labels with values 0 for IPv4 and 2 for IPv6 are distributed by the egress label edge router instead of implicit null labels when QoS preservation is required. The penultimate router pops the transport label stack but leaves the explicit null label which carries the EXP bits containing QoS information. The egress router receives the packet with the explicit null label, reads the QoS markings, pops the explicit null label, and forwards the IP packet with appropriate QoS treatment.
This mechanism is particularly important when different QoS treatments are applied to traffic within the MPLS core versus the IP access network. Without explicit null, QoS information encoded in MPLS EXP bits would be lost during PHP, forcing the egress router to reclassify traffic based on IP headers alone. Explicit null ensures that QoS decisions made at ingress or within the core are honored at egress.
Explicit null is not used to prevent label pushing or signal errors. While it does appear at the bottom of the stack with the S bit set, this is not its primary purpose. The preservation of QoS information through PHP is the specific problem that explicit null addresses in service provider networks where quality of service guarantees are contractual requirements.
Question 49
Which OSPF LSA type is used to advertise external routes into an NSSA area?
A) Type 4
B) Type 5
C) Type 7
D) Type 9
Answer: C
Explanation:
Type 7 LSAs are specifically designed for advertising external routes into Not-So-Stubby Areas in OSPF, providing a mechanism for injecting external routing information into areas that are otherwise configured to block Type 5 external LSAs. NSSA areas represent a compromise between totally stubby areas that accept no external routes and regular areas that receive all external routing information from autonomous system boundary routers.
When an ASBR exists within an NSSA area and needs to advertise external routes it has learned through redistribution from other protocols, it generates Type 7 LSAs that flood throughout the NSSA area. These Type 7 LSAs are similar to Type 5 LSAs in that they describe external destinations but are confined to the NSSA area boundaries. The ABR connecting the NSSA to the backbone area performs translation, converting Type 7 LSAs into Type 5 LSAs for advertisement into other areas.
This translation process at the ABR allows the NSSA to maintain stub-like characteristics by not accepting Type 5 LSAs flooded from other areas while still permitting local external route injection. The ABR may suppress translation of certain Type 7 LSAs based on the P-bit in the LSA which indicates whether the route should be propagated beyond the NSSA. Multiple ABRs on an NSSA use the forwarding address field and metric type to determine which ABR performs translation.
Type 4 LSAs advertise ASBR locations to enable reachability to ASBRs. Type 5 LSAs advertise external routes in regular areas. Type 9 LSAs are opaque LSAs for link-local scope. Type 7 LSAs uniquely enable external route advertisement within NSSA areas while maintaining stub area characteristics for routes external to the NSSA.
Question 50
In IS-IS, what is the purpose of the Overload bit?
A) To indicate the router is congested
B) To signal that the router should not be used for transit traffic
C) To prioritize routing updates
D) To enable fast convergence
Answer: B
Explanation:
The Overload bit in IS-IS signals that a router should not be used for transit traffic forwarding, indicating that while the router can reach its directly connected networks and should remain in the topology for those destinations, it should be avoided for through traffic between other routers. This mechanism allows routers experiencing resource constraints, maintenance conditions, or controlled introduction into the network to participate in routing without being overwhelmed by transit traffic.
When a router sets the Overload bit in its LSP advertisements, other routers in the IS-IS domain include it in their shortest path calculations for reaching its directly attached prefixes but exclude it from paths to other destinations. This ensures that traffic destined for networks directly connected to the overloaded router can still reach those networks, but traffic between other routers finds alternate paths that avoid the overloaded router when possible.
Common use cases for the Overload bit include gracefully introducing new routers into production networks where initial testing and validation should occur without full transit traffic load, performing maintenance activities where reduced traffic load is needed but maintaining connectivity to directly attached customers, responding to resource constraints like memory or CPU exhaustion, and implementing hitless upgrades where routing participation is maintained while transit traffic is temporarily diverted.
The Overload bit does not indicate current congestion levels which are handled by traffic engineering mechanisms. It does not prioritize routing updates which follow standard IS-IS flooding procedures. Fast convergence features are separate mechanisms. The Overload bit specifically provides controlled exclusion from transit forwarding paths while maintaining reachability to directly connected destinations.
Question 51
Which BGP attribute must be present in all BGP updates?
A) LOCAL_PREF
B) MED
C) ORIGIN
D) COMMUNITY
Answer: C
Explanation:
The ORIGIN attribute is a mandatory well-known BGP attribute that must be present in every BGP update message, indicating how the route was originally introduced into BGP. This attribute provides fundamental information about route provenance that influences path selection and helps BGP speakers understand the reliability and trustworthiness of routing information during best path calculations.
The ORIGIN attribute has three possible values: IGP indicating the route was learned from an interior gateway protocol within the originating AS and is considered most reliable, EGP indicating the route was learned from the legacy Exterior Gateway Protocol and is considered less reliable, and Incomplete indicating the route was introduced through redistribution or other means where the origin is uncertain. During best path selection, routes with IGP origin are preferred over EGP origin, which are preferred over Incomplete origin when all other attributes are equal.
Routes originating from network statements in BGP configuration receive IGP origin, routes learned through redistribution from IGPs typically receive Incomplete origin unless explicitly configured otherwise, and routes injected through aggregation inherit the most preferred origin of their component routes. The ORIGIN attribute travels with the route as it propagates through BGP autonomous systems, providing consistent information about route source.
LOCAL_PREF is well-known but not mandatory and only has meaning within an AS. MED is optional and used for inter-AS path selection. COMMUNITY is an optional transitive attribute. ORIGIN is the only attribute from the standard BGP path attributes that is mandatory and must appear in every BGP update carrying reachability information.
Question 52
What is the primary purpose of BGP route refresh capability?
A) To reset BGP sessions faster
B) To request updated routes from a peer without resetting the session
C) To compress routing updates
D) To authenticate routing information
Answer: B
Explanation:
BGP route refresh capability enables a BGP speaker to request that a peer resend all routing information without tearing down and re-establishing the BGP session, providing a non-disruptive method for applying new routing policies or recovering from routing inconsistencies. This capability eliminates the need for hard or soft resets that either disrupt traffic flow through session interruption or consume large amounts of memory through route storage.
Before route refresh capability, applying new import policies required either hard reset that tore down the BGP session causing routing disruption and traffic loss, or soft reconfiguration that required storing original unmodified routes from all peers consuming significant memory resources. Route refresh allows the router to send a route refresh message requesting the peer to resend all routes, which are then processed against current policies without storing duplicate route information.
The capability is negotiated during BGP session establishment through capability advertisement. When both peers support route refresh, either can send a route refresh request when policy changes require route re-evaluation. The peer receiving the request resends all routes it previously advertised using current policy, allowing the requesting router to rebuild its routing table with new policy applications. This process maintains session stability and avoids convergence delays.
Route refresh does not accelerate session reset procedures which follow standard BGP timers. It does not compress updates which may use other mechanisms. Route authentication uses other BGP capabilities like MD5 signatures or TCP-AO. Route refresh specifically addresses the operational need for policy application without session disruption or excessive memory consumption in large-scale service provider networks.
Question 53
In MPLS VPN, what is the purpose of the Route Distinguisher (RD)?
A) To filter routes between VPN sites
B) To create unique VPNv4 addresses from overlapping customer IPv4 addresses
C) To establish label switched paths
D) To authenticate VPN customers
Answer: B
Explanation:
The Route Distinguisher creates unique VPNv4 addresses by prepending a 64-bit value to 32-bit IPv4 addresses, enabling multiple VPN customers to use overlapping or identical IP address spaces while maintaining distinct routes within the provider network. This addressing mechanism is fundamental to MPLS Layer 3 VPN operation where service providers must support many customers who may all use common private address ranges like 10.0.0.0/8 or 192.168.0.0/16.
The RD transforms a potentially duplicate IPv4 prefix into a globally unique VPNv4 prefix within the provider’s BGP infrastructure. For example, if two customers both use 10.1.1.0/24, the provider might assign RD 100:1 to the first customer creating VPNv4 address 100:1:10.1.1.0/24 and RD 100:2 to the second customer creating 100:2:10.1.1.0/24. These unique VPNv4 routes coexist in the provider edge router’s global BGP table without conflict.
The RD format typically uses autonomous system number colon value or IP address colon value notation. The choice of RD is locally significant to the provider network and does not need coordination between providers. Different PE routers can use different RDs for the same VPN as long as Route Targets properly control route import and export. The RD’s sole purpose is ensuring uniqueness in the BGP table rather than controlling route distribution.
Route filtering between sites is accomplished by Route Targets rather than RDs. Label switched path establishment uses LDP, RSVP-TE, or segment routing protocols. Customer authentication is handled by access control mechanisms. The RD specifically solves the address uniqueness problem that enables MPLS VPN scalability in service provider environments supporting thousands of customers.
Question 54
Which IS-IS metric type is supported by default in Junos OS?
A) Narrow metrics only
B) Wide metrics only
C) Both narrow and wide metrics
D) External metrics only
Answer: C
Explanation:
Junos OS supports both narrow and wide IS-IS metrics simultaneously by default, providing compatibility with legacy implementations using narrow metrics while enabling modern deployments to benefit from the extended range of wide metrics. This dual support ensures that Junos routers can interoperate in mixed environments where some routers have been upgraded to support wide metrics while others continue using narrow metrics.
Narrow metrics use a 6-bit value allowing maximum interface costs of 63 and maximum path costs of 1023, which proved insufficient for large modern networks where more granular cost differentiation is needed. Wide metrics use 24-bit values supporting interface costs up to 16,777,215 and path costs exceeding 4 billion, providing the range necessary for traffic engineering, large-scale networks, and precise path control based on bandwidth, delay, or administrative policies.
When both metric types are configured, IS-IS includes both narrow and wide metric TLVs in LSP advertisements. Routers supporting only narrow metrics ignore wide metric TLVs and make routing decisions using narrow metrics. Routers supporting wide metrics preferentially use wide metrics for path calculation when available, falling back to narrow metrics only when necessary for backward compatibility. This ensures optimal routing while maintaining network-wide reachability.
The default configuration in Junos includes both metric types to maximize interoperability. Administrators can explicitly configure wide-metrics-only mode when all routers in the domain support wide metrics and narrow metric compatibility is no longer required. This dual support during transition periods prevents network partitioning while enabling gradual adoption of modern IS-IS capabilities.
Question 55
What is the purpose of the BGP Add-Path capability?
A) To increase BGP session security
B) To advertise multiple paths for the same prefix to a peer
C) To reduce BGP convergence time
D) To compress BGP updates
Answer: B
Explanation:
The BGP Add-Path capability enables a BGP speaker to advertise multiple distinct paths for the same network prefix to its peers, overcoming the traditional BGP limitation where only the single best path per prefix is advertised. This capability improves routing diversity, enhances convergence characteristics, and provides receiving routers with path alternatives that enable better traffic engineering and faster failover when primary paths become unavailable.
In traditional BGP, route reflectors and confederations can hide valid alternate paths from route reflector clients because the reflector selects only its single best path for reflection. Add-Path allows the reflector to advertise its best path plus additional diverse paths, giving clients visibility into multiple routes. Similarly, a router with multiple equal-cost or nearly-equal-cost paths can advertise all qualifying paths rather than selecting one arbitrarily.
The capability is negotiated per address family during session establishment. When enabled, BGP updates include a path identifier that uniquely identifies each path for the same prefix, allowing the receiving router to distinguish between multiple advertisements for the same destination. This enables the receiver to maintain multiple paths in its routing table and select among them based on local policy or use them for load balancing across diverse paths.
Add-Path does not directly affect session security which relies on authentication mechanisms. While it can improve convergence by providing pre-installed backup paths, this is a consequence rather than the primary purpose. Update compression is handled by other mechanisms. Add-Path specifically addresses the fundamental architectural limitation where BGP’s single-best-path-per-prefix model restricts routing flexibility and path diversity in complex networks.
Question 56
In Junos OS, which statement is true about martian addresses?
A) They are automatically advertised to BGP peers
B) They are considered invalid and ignored by the routing protocol process
C) They require special licensing to configure
D) They are used for load balancing
Answer: B
Explanation:
Martian addresses in Junos OS are network prefixes considered invalid or illegal that are automatically rejected by the routing protocol process, preventing clearly incorrect or potentially harmful routes from being installed in the routing table. This protective mechanism acts as a sanity check against routing misconfigurations, route leaks, or malicious route injections that could disrupt network operations or create security vulnerabilities.
The default martian address list includes prefixes that should never appear in legitimate routing updates such as the 0.0.0.0/8 network reserved for hosts on this network, 127.0.0.0/8 loopback addresses intended only for local use, 224.0.0.0/4 multicast addresses not appropriate for unicast routing, 240.0.0.0/4 reserved address space, and extremely specific routes like /32 host routes for certain protocols where they are inappropriate.
Administrators can modify the martian address list to accommodate legitimate use cases in specific environments, such as allowing certain multicast or reserved ranges when required by network design. However, the default settings provide strong protection against common routing errors. When a martian address is received through a routing protocol, Junos logs a warning message and discards the route without installing it or propagating it to other routers.
Martian addresses are specifically prevented from BGP advertisement rather than automatically advertised. They do not require licensing and are not related to load balancing functionality. The protection against invalid route installation is the fundamental purpose that helps maintain routing table integrity and protects against routing table corruption in service provider networks.
Question 57
What is the function of the MPLS TTL field?
A) To provide QoS classification
B) To prevent forwarding loops and provide traceroute functionality
C) To authenticate MPLS packets
D) To determine label stack depth
Answer: B
Explanation:
The MPLS TTL field serves dual purposes of preventing forwarding loops by limiting packet lifetime in the network and enabling traceroute functionality for troubleshooting label switched paths. Similar to the IP TTL field, the MPLS TTL is decremented at each hop through the MPLS network, and packets with TTL reaching zero are discarded with ICMP time exceeded messages sent to the source.
TTL handling in MPLS networks can operate in two modes: uniform mode where IP TTL is copied into the MPLS TTL field at ingress, decremented at each label switching hop, and copied back to IP TTL at egress, providing end-to-end TTL transparency; and pipe mode where MPLS TTL is set to a configured value at ingress regardless of IP TTL, decremented within the MPLS core, but not copied back to IP TTL at egress, hiding the MPLS network topology from traceroute.
Traceroute functionality relies on TTL behavior where packets with progressively increasing TTL values elicit time exceeded responses from successive routers along the path. In uniform mode, traceroute reveals all routers including those within the MPLS core. In pipe mode, the MPLS core appears as a single hop, concealing internal provider topology. This TTL handling flexibility allows providers to balance operational troubleshooting needs against security concerns about topology disclosure.
QoS classification uses the EXP bits rather than TTL. MPLS does not include native authentication mechanisms which rely on underlying transport security. Label stack depth is determined by the bottom-of-stack bit rather than TTL. The TTL field specifically provides loop prevention and traceroute capabilities essential for operational MPLS network management.
Question 58
Which BGP community is used to signal that a route should not be advertised to any peer?
A) NO_EXPORT
B) NO_ADVERTISE
C) NO_EXPORT_SUBCONFED
D) LOCAL_AS
Answer: B
Explanation:
The NO_ADVERTISE well-known community signals that a route should not be advertised to any BGP peer, including iBGP and eBGP neighbors, effectively preventing the route from propagating beyond the router that receives it. This community provides the most restrictive control over route advertisement, ensuring that routes tagged with this community remain local to the receiving router while still being eligible for local routing table installation.
When a BGP speaker receives a route with the NO_ADVERTISE community attached, it processes the route normally including running it through import policies and considering it for best path selection. If the route is selected as best and installed in the routing table, it can be used for forwarding local traffic. However, the router will not include this route in any BGP updates sent to other peers regardless of their relationship or policy configurations.
This community is useful for scenarios where routes should influence forwarding on specific routers without propagating through the network, such as traffic engineering where particular routers need specific routing information for local path selection, blackhole routing where attack traffic should be dropped at specific locations without wider advertisement, or route redistribution scenarios where routes from one protocol should influence BGP path selection locally without entering BGP distribution.
NO_EXPORT prevents advertisement beyond the local AS or confederation but allows sharing with iBGP peers and confederation members. NO_EXPORT_SUBCONFED prevents advertisement beyond the local confederation member AS. LOCAL_AS prevents advertisement beyond the local AS to external peers but permits internal advertisement. NO_ADVERTISE provides the most complete advertisement restriction by preventing all propagation regardless of peer type.
Question 59
In OSPF, what is the purpose of virtual links?
A) To connect remote offices directly
B) To connect a non-backbone area to the backbone through another area
C) To provide redundant paths
D) To enable multicast routing
Answer: B
Explanation:
OSPF virtual links provide connectivity between the backbone area and non-backbone areas that cannot be directly connected to Area 0, enabling OSPF to maintain its hierarchical design requirement that all areas must have direct connectivity to the backbone. Virtual links create logical point-to-point connections through transit areas, allowing remote areas to function as if they have direct backbone attachment even when physical topology makes direct connection impractical.
Virtual links are configured between two area border routers where one ABR connects to the backbone and the other connects to the isolated area, with both routers sharing a common area that serves as the transit area. The virtual link appears as an unnumbered point-to-point link belonging to the backbone area, carrying Type 1 Router LSAs and Type 2 Network LSAs between the backbone and the isolated area through the transit area.
Common scenarios requiring virtual links include temporary situations during network migration where areas are being reorganized, redundancy configurations where area 0 becomes partitioned and virtual links restore logical backbone continuity, and situations where geographic or organizational constraints make direct backbone connectivity impossible. However, virtual links are generally considered a temporary solution because they add complexity and troubleshooting difficulty.
Virtual links do not provide general remote office connectivity which uses normal OSPF or other routing protocols. While they may participate in redundancy, this is not their primary purpose. They do not enable multicast routing which requires separate PIM or other multicast protocols. Virtual links specifically solve the hierarchical connectivity problem where areas cannot directly attach to the backbone due to physical topology constraints.
Question 60
What is the purpose of the BGP AIGP attribute?
A) To provide authentication for BGP sessions
B) To carry accumulated IGP metric across autonomous systems
C) To compress large BGP updates
D) To enable IPv6 support
Answer: B
Explanation:
The Accumulated IGP Metric attribute enables BGP to carry interior gateway protocol metric information across autonomous system boundaries, providing a mechanism for making consistent routing decisions in environments where multiple autonomous systems are under common administrative control and should make path selections based on cumulative IGP cost rather than standard BGP attributes. AIGP extends IGP-based path selection across AS boundaries where traditional BGP metrics like MED apply only within limited scope.
AIGP is particularly valuable in large service provider networks using BGP confederations or multiple connected autonomous systems where end-to-end IGP metric-based routing is desired but AS path length or other BGP attributes would normally take precedence. Each router adds its local IGP cost to the AIGP value as routes propagate, creating an accumulated metric that represents total IGP cost from origination to current location.
The attribute is optional non-transitive, meaning routers not supporting AIGP ignore it without causing routing failures. For AIGP to function correctly, all routers in the path must support the attribute and be configured to enable it on appropriate sessions. Path selection using AIGP occurs early in the BGP decision process, before MED comparison, allowing IGP-cost-based routing across administrative boundaries while maintaining BGP’s stability and policy capabilities.
AIGP does not provide session authentication which uses TCP MD5 or other security mechanisms. It does not compress updates which may use route refresh or other optimization techniques. IPv6 support uses multiprotocol BGP extensions rather than AIGP. The accumulated IGP metric functionality specifically addresses routing optimization in large multi-AS environments under common administrative control where IGP-metric-based path selection should span AS boundaries.