Hard — 300-410 Practice Quiz

Question 1

Two routers, R1 and R2, connect an EIGRP domain (AS 100) to an OSPF domain. Both routers perform mutual redistribution between EIGRP and OSPF. Network 10.50.0.0/24 originates natively in EIGRP. Users report intermittent reachability to 10.50.0.0/24 from the OSPF domain, and R2's routing table shows 10.50.0.0/24 pointing back into OSPF instead of via its native EIGRP path. The redistribution is configured with default settings and no route tagging or filtering is applied. What is the MOST likely cause?

Accepted Answer

The route was redistributed into OSPF as an external (O E2) route on R1, and because external OSPF (AD 110) is preferred over EIGRP external (AD 170) on R2, R2 installs the OSPF path, creating a feedback loop.

Answer

OSPF external E2 routes carry a metric of 20 by default, which is lower than the EIGRP composite metric, so R2 always prefers the OSPF path regardless of administrative distance.

Answer

EIGRP auto-summary is enabled, causing 10.50.0.0/24 to be summarized to 10.0.0.0/8 and suppressing the more specific route on R2.

Answer

Split horizon on the EIGRP interface between R1 and R2 prevents R2 from learning 10.50.0.0/24 via EIGRP, forcing it to use the OSPF path.

Question 2

A network engineer configures mutual redistribution between BGP (AS 65100) and EIGRP (AS 10) on two border routers, R1 and R2, that both connect to the same BGP and EIGRP domains. External EIGRP routes learned from BGP on R1 are being redistributed back into BGP on R2, then re-advertised and reinjected into EIGRP, causing intermittent routing loops. The engineer wants to prevent routes that originated in BGP from being redistributed back into BGP. Which configuration on both routers best prevents this loop?

Accepted Answer

Apply a route map on redistribution from EIGRP into BGP that matches and denies routes tagged when they were redistributed from BGP into EIGRP, and set that tag during the BGP-to-EIGRP redistribution.

Answer

Increase the administrative distance of external EIGRP routes to 255 on both routers so they are not installed in the routing table.

Answer

Enable auto-summary in the EIGRP process so that the more specific BGP-origin routes are suppressed before redistribution.

Answer

Configure split horizon on the EIGRP interfaces facing the BGP border so the routes are not advertised back out.

Question 3

A network engineer configures policy-based routing on R2 to forward all HTTP traffic sourced from 10.1.1.0/24 out a backup ISP link. The route-map is applied inbound on the LAN interface and contains: 'match ip address HTTP_ACL' and 'set ip next-hop 203.0.113.5'. The primary default route via 198.51.100.1 remains active. After applying the policy, 'show route-map' shows zero policy matches even though users on 10.1.1.0/24 are actively browsing HTTP sites. The ACL correctly permits tcp any eq 80. What is the most likely reason PBR is not matching the traffic?

Accepted Answer

The ACL matches destination port 80 with 'eq 80' in the source position, so return traffic is matched instead of client requests, which arrive with a random source port and destination port 80

Answer

PBR only processes traffic that would otherwise be dropped, so packets with an existing default route bypass the route-map entirely

Answer

The 'set ip next-hop' address 203.0.113.5 must be directly connected; otherwise PBR silently ignores the route-map with no match counter increment

Answer

Route-maps applied inbound only evaluate routing-protocol updates, not data-plane packets, so 'ip policy route-map' must be used instead

Question 4

After applying a CoPP policy to a distribution router, network engineers report that EIGRP adjacencies over the LAN segments repeatedly drop and re-form. The CoPP configuration includes a class 'CLASS-ROUTING' matched with ACL 'ACL-ROUTING' that permits 'ip host 224.0.0.5 any' and a police rate that is generous. All other classes drop. SSH, SNMP, and BGP work fine. Which change to the ACL will restore stable EIGRP adjacencies?

Accepted Answer

Add 'permit ip any host 224.0.0.10' to match EIGRP multicast Hello traffic

Answer

Add 'permit eigrp any host 224.0.0.5' to match OSPF and EIGRP together

Answer

Change the entry to 'permit tcp any any eq 88' to allow EIGRP over TCP

Answer

Add 'permit udp any any eq 88' to permit EIGRP Hello packets

Question 5

After applying a new CoPP policy on a core router, users report that large file transfers through the router intermittently stall, while small pings and normal browsing work fine. Investigation shows the router must generate ICMP 'fragmentation-needed' (Type 3, Code 4) messages for a path with a smaller MTU, but Path MTU Discovery is failing end-to-end. The CoPP policy includes a class matching ICMP that is police-limited to a very low rate with 'exceed-action drop'. Which action best resolves the issue?

Accepted Answer

Create a dedicated CoPP class that matches ICMP unreachable/fragmentation-needed traffic and allow it at an adequate rate rather than lumping it into a tightly policed generic ICMP class

Answer

Remove the ICMP class entirely so all ICMP is placed in class-default and forwarded without policing

Answer

Increase the interface MTU on the transit link so fragmentation is never required

Answer

Change the exceed-action from drop to transmit on the existing generic ICMP class only during peak hours

Question 6

A network engineer configures CoPP on an ISR to protect the router. A policy-map named CONTROL-PLANE-POLICY classifies and polices SNMP, SSH, and OSPF traffic and is applied with 'service-policy input CONTROL-PLANE-POLICY' under control-plane. Users report that the router is no longer sending SNMP traps to the NMS, although SNMP GET polling from the NMS still works and traps were confirmed working before CoPP was applied. What is the MOST likely cause?

Accepted Answer

SNMP traps are router-generated (egress) traffic and are not evaluated by an input CoPP policy; another feature or ACL is dropping them.

Answer

The SNMP class in the input CoPP policy is policing the outbound traps below the required rate, causing them to be dropped.

Answer

Traps require the policy to be applied with 'service-policy output' on the control plane, which was omitted.

Answer

The class map matching UDP 161 does not include UDP 162, so the input policy silently drops all trap packets.

Question 7

A three-tier campus network uses a Layer 3 distribution switch as a DHCP relay agent. Access switches insert DHCP Option 82 (relay information) as packets pass through them. When clients on VLAN 30 request addresses, the central IOS DHCP server logs show the requests arriving, but no DHCPOFFER reaches the clients. Debugging on the relay shows: 'DHCPD: relay information option exists, but giaddr is zero' followed by the packet being dropped. The relay agent has 'ip helper-address' configured correctly on the VLAN 30 SVI. What is the most likely cause?

Accepted Answer

The relay agent needs 'ip dhcp relay information trust-all' or per-interface 'ip dhcp relay information trusted' to accept the pre-inserted Option 82 with giaddr 0

Answer

The relay agent's default 'ip dhcp relay information policy replace' behavior is discarding packets that already contain Option 82 from an untrusted downstream device with a zero giaddr

Answer

The DHCP server pool is missing the 'network' statement for the VLAN 30 subnet

Answer

The access switch is not configured as a DHCP snooping trusted port toward the relay

Question 8

A network engineer deploys a Phase 2 DMVPN with a single hub and several spokes using EIGRP as the routing protocol. Spoke-to-spoke traffic is functional in some cases but fails in others. On a spoke, 'show ip route' displays remote spoke LAN subnets with the hub's tunnel IP as the next hop rather than the destination spoke's tunnel IP. What must be configured on the HUB tunnel interface to allow spokes to build direct spoke-to-spoke tunnels in this Phase 2 design?

Accepted Answer

Disable EIGRP next-hop-self with 'no ip next-hop-self eigrp <AS>' on the hub tunnel interface

Answer

Enable 'ip nhrp redirect' on the hub tunnel interface

Answer

Configure 'ip nhrp shortcut' on the hub tunnel interface

Answer

Disable EIGRP split horizon with 'no ip split-horizon eigrp <AS>' on the hub tunnel interface

Question 9

You are troubleshooting an EIGRP named-mode deployment. R1 runs a legacy classic-mode EIGRP configuration for autonomous system 100, while its neighbor R2 has recently been migrated to EIGRP named mode using the same AS. The two routers form an adjacency and exchange routes, but you notice that the metrics for the same destinations differ significantly between the two routers, and traffic engineering based on delay is not behaving as expected. The link between them is a 10 Gbps interface. Which explanation best accounts for the metric discrepancy?

Accepted Answer

Named mode uses 64-bit wide metrics by default, so R2 scales the composite metric differently than R1's classic 32-bit metric for high-bandwidth interfaces

Answer

The adjacency should not have formed at all because classic and named mode routers cannot become neighbors within the same AS

Answer

R2 in named mode automatically disables auto-summary while R1 leaves it enabled, causing the metrics to be recalculated

Answer

Named mode changes the default K-values to K1=1, K2=1, K3=1, K4=1, K5=1, which changes the composite metric calculation

Question 10

Two routers, R1 and R2, both redistribute routes bidirectionally between OSPF and EIGRP at different points in the network. After the change, users report intermittent connectivity to the 172.16.50.0/24 network, and traceroutes show traffic occasionally looping between R1 and R2. You confirm the route originated in OSPF. Which configuration approach at the redistribution points will BEST prevent routes from being re-injected back into their protocol of origin?

Accepted Answer

Tag routes with a route map as they are redistributed from OSPF into EIGRP, then deny routes carrying that tag when redistributing from EIGRP back into OSPF

Answer

Increase the administrative distance of external EIGRP routes to 255 on both R1 and R2

Answer

Enable split horizon on the EIGRP interfaces between R1 and R2 to stop the routes from being advertised back

Answer

Configure manual summarization of 172.16.50.0/24 on both redistribution points to hide the specific route

Question 11

An engineer wants R1 to load-balance traffic to the 10.50.0.0/16 network across two EIGRP paths. The primary path via R2 has a feasible distance of 3072000, and the alternate path via R3 has a computed metric of 5120000 with a reported distance of 2560000. The engineer configures 'variance 2' under the EIGRP process, but the path through R3 is still not installed in the routing table. What is the reason R3's path is excluded?

Accepted Answer

R3's reported distance (2560000) is less than R1's feasible distance (3072000), making it a feasible successor, and 5120000 is within 2 x 3072000; the path should install, so the omission points to a 'traffic-share' or 'maximum-paths' limitation rather than variance.

Answer

R3's path is not a feasible successor because its reported distance (2560000) is not less than the feasible distance (3072000)... wait, it is less, so variance must be increased to at least 2.

Answer

R3's advertised metric (5120000) exceeds the feasible distance (3072000) multiplied by the variance value (2 x 3072000 = 6144000), so it should be installed; the real issue is the path fails the feasibility condition check.

Answer

R3's path does not meet the feasibility condition because although 5120000 is within variance range, EIGRP still requires the alternate path to be a feasible successor, and R3's reported distance meets that requirement, so it should install.

Question 12

A network engineer configured EIGRP named mode for VRF CUSTOMER_A on two PE routers connected back-to-back over a physical link. The EIGRP adjacency in the VRF forms successfully, and both routers show each other as neighbors under 'show eigrp address-family ipv4 vrf CUSTOMER_A neighbors'. However, routes learned from the remote PE do not appear in 'show ip route vrf CUSTOMER_A'. The interfaces belong to the correct VRF, and the autonomous-system number matches. What is the MOST likely cause?

Accepted Answer

A distribute-list or route-map inbound under the VRF address-family is filtering the received routes

Answer

The 'autonomous-system' number under the address-family does not match, preventing route exchange

Answer

The VRF route distinguisher (RD) differs between the two PE routers, so EIGRP drops the routes

Answer

BFD is enabled on the interface, which suppresses EIGRP route installation until echo packets are validated

Question 13

You are deploying IPv6 First Hop Security on an access switch. After configuring an IPv6 snooping policy named PROT and enabling 'ipv6 source-guard attach-policy' on interface GigabitEthernet0/1, hosts on that port lose IPv6 connectivity. The command 'show ipv6 neighbors binding' shows an empty table even though hosts are actively sending traffic. You confirm the hosts have valid dynamically learned addresses. Which action most likely resolves the empty binding table so source guard can permit legitimate traffic?

Accepted Answer

Attach the IPv6 snooping policy PROT to interface GigabitEthernet0/1 with 'ipv6 snooping attach-policy PROT'

Answer

Enable 'ipv6 nd raguard' on the interface so router advertisements can populate the binding table

Answer

Add static binding entries for every host using 'ipv6 neighbor binding vlan' commands

Answer

Increase the binding table reachable lifetime with 'ipv6 neighbor binding max-entries'

Question 14

A customer running a traceroute across your MPLS L3VPN backbone reports that the provider's P routers are visible as hops in the output, exposing internal core topology. The service provider policy requires that the MPLS core appear as a single hop to CE devices while normal traceroute still works within customer sites. Which configuration on the PE routers achieves this?

Accepted Answer

no mpls ip propagate-ttl forwarded

Answer

mpls ip propagate-ttl local

Answer

no mpls ip ttl-expiration pop

Answer

mpls label protocol ldp explicit-null

Question 15

An MPLS L3VPN service provider connects two sites of customer 'Acme' using eBGP as the PE-CE routing protocol. Both Acme sites use AS 65200. The provider PE routers redistribute customer routes into MP-BGP normally, and VPNv4 routes are exchanged between PEs with correct route targets. However, Site B never learns the prefixes originated at Site A. The PE at Site B shows the Site A prefixes in its BGP table but marks them as not received/denied by the CE. What is the most likely cause and fix?

Accepted Answer

The CE at Site B rejects the routes because its own AS (65200) appears in the AS_PATH; enable 'neighbor <ce> as-override' on the Site B PE.

Answer

The route target import/export values are mismatched between the two VRFs; correct the RT under the VRF configuration on both PEs.

Answer

The route distinguisher is identical on both PEs, causing the routes to be treated as duplicates; assign a unique RD per PE.

Answer

MP-BGP is not carrying the VPN label; enable 'send-label' under the vpnv4 address family on both PEs.

Question 16

In a service provider MPLS L3VPN core, PE1 and PE2 exchange VPNv4 prefixes through a dedicated route reflector (RR) that is not in the data forwarding path. Customer routes appear in the BGP VPNv4 table on PE2 with the correct route target, but they never install into the customer VRF routing table on PE2. A show bgp vpnv4 unicast all reveals the routes are marked as inaccessible, and the next-hop of each VPNv4 prefix points to the RR's loopback rather than PE1's loopback. What is the most likely cause?

Accepted Answer

The RR is configured with 'neighbor next-hop-self' under the VPNv4 address family, rewriting the BGP next hop to itself

Answer

The route target import statement on PE2 does not match the export target on PE1

Answer

LDP is not enabled on the RR's loopback interface, so no label binding exists

Answer

The RD values on PE1 and PE2 are identical, causing the VPNv4 prefixes to be treated as duplicates

Question 17

A service provider runs an MPLS L3VPN backbone. Two customers, CustA and CustB, both use the overlapping prefix 10.1.1.0/24 within their own VRFs on the same PE router. The provider configures both VRFs with the same route distinguisher (RD) 65000:100 but with different route targets. After the configuration, CustB's site cannot reach several of its own prefixes, and the PE's BGP VPNv4 table appears to show only one instance of 10.1.1.0/24. What is the root cause of this problem?

Accepted Answer

Both VRFs share the same RD, so the resulting VPNv4 prefixes are not unique and one overlapping route is discarded as a duplicate in the BGP table

Answer

The route targets differ between the VRFs, which prevents the PE from importing either prefix into the VPNv4 table

Answer

A single RD cannot be assigned to any VRF; RDs must be globally unique per PE regardless of overlapping prefixes

Answer

The MP-BGP session is not using the extended community attribute, so RD values are ignored during route advertisement

Question 18

A service provider hosts a shared services VRF (SHARED) containing a DNS/NTP server at 10.100.100.10. Two customer VRFs (CUST_A and CUST_B) must reach this server, but CUST_A and CUST_B must NOT reach each other. The SHARED VRF uses RD 65000:100. On the PE, you configure route-target import/export values so the shared route is imported into both customer VRFs. Which route-target configuration on the SHARED, CUST_A, and CUST_B VRFs achieves reachability to the server while keeping the two customers isolated?

Accepted Answer

SHARED exports RT 65000:100 and imports 65000:1 and 65000:2; CUST_A exports 65000:1 and imports 65000:1 and 65000:100; CUST_B exports 65000:2 and imports 65000:2 and 65000:100

Answer

All three VRFs export and import the single RT 65000:100 so every VRF shares one common route target

Answer

SHARED, CUST_A, and CUST_B each export and import both 65000:1 and 65000:2 to guarantee the server is reachable from all sites

Answer

CUST_A and CUST_B export 65000:100 and import 65000:100; SHARED imports and exports only its own RD-derived RT 65000:100

Question 19

A network engineer configures Flexible NetFlow to export IPFIX records from a WAN edge router to a collector reachable only through a VRF named MGMT. The flow monitor is applied and 'show flow monitor WAN-MON cache' shows thousands of flows being captured correctly. However, the collector never receives any flow records, and 'show flow exporter WAN-EXP statistics' shows the packets-sent counter incrementing but 'export packets dropped' also increasing. The exporter is configured with 'destination 10.99.0.10' and 'source Loopback0'. Loopback0 is in the global routing table. What is the most likely cause?

Accepted Answer

The exporter lacks the 'destination ... vrf MGMT' option, so packets are routed via the global table where the collector is unreachable.

Answer

The exporter is missing an 'export-protocol ipfix' statement, so records are dropped before transmission.

Answer

The flow record is using 'match' fields that are incompatible with IPFIX and must be changed to 'collect' fields.

Answer

The active flow timeout is set too high, causing the cache to hold flows until they age out before export.

Question 20

A network engineer applies 'distribute-list 10 in' under the OSPF process on router R3 to prevent the 10.50.5.0/24 route (originated in area 0) from being installed. Access-list 10 correctly denies 10.50.5.0/24 and permits everything else. After the change, R3's routing table no longer shows 10.50.5.0/24, but R3's neighbors still learn and use 10.50.5.0/24 normally. However, a downstream router R4 (which relies on R3 to reach 10.50.5.0/24) now has a routing black hole. Why does R4 still install the route while R3 does not, and what causes the black hole?

Accepted Answer

The inbound distribute-list only filters route installation into R3's local RIB; it does not alter the OSPF LSDB, so LSAs still flood to all routers including R4, which continues to point at R3 as the next hop for a route R3 cannot forward.

Answer

The distribute-list removes the Type 3 summary LSA on R3, but R4 rebuilds it from its own SPF calculation, causing inconsistent databases and the black hole.

Answer

Inbound distribute-lists in OSPF filter LSAs during flooding, so R4 should not have the route; the black hole is caused by a mismatched area type between R3 and R4.

Answer

The distribute-list changes the administrative distance of the route on R3 to 255, but R4 retains AD 110, so only R4 installs it and forwards blindly.

Question 21

Two ASBRs (R1 and R2) both perform mutual redistribution between OSPF and RIP. After the change, a RIP-learned prefix 10.50.0.0/24 originated behind R1 is being reinjected back into RIP by R2, creating a routing loop that surfaces as intermittent reachability. You want to use OSPF route tagging to break the loop without static filters per-prefix. Which configuration correctly prevents routes that originated in RIP from being redistributed back into RIP by the other ASBR?

Accepted Answer

On redistribution from RIP into OSPF, set tag 100; on both ASBRs deny any OSPF external route with tag 100 when redistributing OSPF into RIP.

Answer

On redistribution from OSPF into RIP, set tag 100; then permit only routes with tag 100 when redistributing RIP into OSPF.

Answer

Configure a distribute-list on the OSPF process denying 10.50.0.0/24 inbound so the tag is never learned.

Answer

Set the OSPF external route type to E1 during redistribution so the accumulated metric prevents the loop automatically.

Question 22

R1 and R2 both perform mutual redistribution between OSPF and EIGRP at two separate boundary points in the network. To prevent a routing loop, the design tags all routes learned from OSPF with tag 100 as they enter EIGRP, and a route-map on the OSPF-to-EIGRP redistribution is expected to deny any route carrying tag 100. After deployment, routes still loop back into OSPF. On R2 you run 'show route-map REDIST-TO-OSPF' and see the route-map has a single sequence: 'route-map REDIST-TO-OSPF deny 10' with 'match tag 100' but no permit sequence. What is the effect of this configuration?

Accepted Answer

The route-map denies routes tagged 100 but, lacking an explicit permit sequence, an implicit deny drops ALL other routes, so no OSPF redistribution occurs at all

Answer

The route-map permits all routes because a deny sequence with a match is treated as a pass-through when no permit exists

Answer

The route-map correctly permits untagged routes and denies tagged routes, so the loop must be caused elsewhere

Answer

The route-map denies tagged routes and automatically permits all remaining routes due to the implicit permit at the end of any redistribution route-map

Question 23

An engineer is troubleshooting an OSPF network with three areas: Area 0 (backbone), Area 1, and Area 2. Both Area 1 and Area 2 are non-backbone areas connected to Area 0 through separate ABRs. A user reports that a subnet learned via a Type 3 LSA originating in Area 1 is not being installed by routers in Area 2, even though the ABRs are fully adjacent and the backbone is stable. Which OSPF loop-prevention behavior best explains why the route from Area 1 reaches Area 2 only through the backbone and not directly?

Accepted Answer

An ABR only accepts Type 3 LSAs for the SPF calculation if they are received on a link belonging to Area 0, preventing inter-area routes from being learned across non-backbone areas.

Answer

Type 3 LSAs are flooded throughout the entire OSPF domain, so the route should appear in Area 2 regardless of the backbone; the issue must be an area authentication mismatch.

Answer

OSPF uses split horizon on Type 3 LSAs, so an ABR never re-advertises a summary LSA back into any area from which it was originally received.

Answer

Type 3 LSAs carry a DN (down) bit that, when set, blocks the receiving ABR from installing the route unless the routers share the same RID domain.

Question 24

R2 sits between an OSPF domain (area 0) and an EIGRP AS 100 domain and performs two-way redistribution. R4, also connected to both domains, redistributes as well. Users report that a subnet 10.10.50.0/24 originating in EIGRP is being learned in OSPF, then redistributed back into EIGRP through R4, causing a suboptimal path and intermittent reachability. Which action on R4 BEST prevents the original EIGRP route from being reinjected back into EIGRP as an external route?

Accepted Answer

Tag routes as they are redistributed from EIGRP into OSPF, and on redistribution from OSPF into EIGRP deny any route carrying that tag with a route map

Answer

Increase the administrative distance of external EIGRP routes to 255 on R4 so the routes are never installed

Answer

Enable split horizon on all EIGRP interfaces on both R2 and R4 to stop the route from being advertised back

Answer

Configure a summary route for 10.10.50.0/24 on R4 pointing to null0 to suppress the reinjection

Question 25

An enterprise runs OSPF with three ASBRs (R1, R2, R3) redistributing the same external network 172.20.0.0/16 into area 0. Users report that traffic to a host in 172.20.5.0/24 always egresses through R3, even though R1 offers a much shorter internal path. All three ASBRs redistribute with default settings and no route maps. You run 'show ip ospf border-routers' and 'show ip route 172.20.5.0' on a core router and see the route points to R3 as a Type 5 external (E2) with metric 20. What is the MOST likely reason the router selected R3?

Accepted Answer

For E2 routes with equal external metrics, OSPF selects the path with the lowest cost to the ASBR (forwarding metric); R3 has the lowest internal cost to reach it from this router.

Answer

E2 routes always prefer the ASBR with the highest router ID, and R3 has the highest router ID of the three ASBRs.

Answer

R3 is advertising the external route as E1, which is always preferred over the E2 routes from R1 and R2.

Answer

The external metric of 20 on R3 is lower than the default of 110 used by R1 and R2, so R3 wins.