75 of 76 questions · Page 1/2 · Route Maps and Route Filtering · Answers revealed
What is the default maximum hop count for RIP routes in Cisco IOS?
Correct. 15 is the maximum hop count; 16 is considered infinity.
Why this answer
RIP uses a hop count metric with a maximum of 15 hops; 16 indicates an unreachable route. This is a fundamental loop prevention mechanism.
An EIGRP network is experiencing a stuck-in-active (SIA) condition for a route 192.168.1.0/24. R1 has the following configuration: router eigrp 100 network 10.0.0.0 distribute-list prefix PL-FILTER in. R2 shows: 'show ip eigrp topology 192.168.1.0/24' is in active state, and 'show ip eigrp events' shows that R1 sent a query but never received a reply. R1's prefix-list PL-FILTER permits only 10.0.0.0/8. What is the root cause?
EIGRP distribute-lists applied inbound also filter queries. Since the prefix 192.168.1.0/24 is not permitted by PL-FILTER, R1 drops the query and does not send a reply, leaving R2 in active state.
Why this answer
The distribute-list prefix PL-FILTER in on R1 filters incoming routes, but it also affects queries. When R2 sends a query for 192.168.1.0/24, R1 receives it but the distribute-list filters the query (since the prefix is not permitted), so R1 does not process it and does not send a reply. This causes R2 to wait indefinitely for a reply, leading to an SIA condition.
The distribute-list should be applied outbound or should permit the necessary prefixes to allow queries to be processed.
Drag and drop the steps to verify and validate Route Maps and Route Filtering operational state into the correct order, from first to last.
Drag steps to the numbered slots on the right, or tap a step then tap a slot.
Why this order
First, display the route-map configuration and statistics with show route-map. Second, check which route-map is applied to interfaces or routing protocols using show ip policy. Third, verify the filtered prefixes in the BGP table with show ip bgp.
Fourth, confirm the impact on routing table entries with show ip route. Finally, test connectivity end-to-end using ping or traceroute.
A network engineer is troubleshooting a PBR route-map that is supposed to set the next-hop for traffic from a specific source to a different next-hop. The route-map is applied to the incoming interface, and the ACL matches the traffic. However, the engineer notices that the traffic is still being forwarded using the routing table. The engineer checks the route-map and sees that the 'set ip next-hop' command points to an IP address that is not reachable. What is the most likely result?
Correct because PBR uses the routing table if the next-hop is unreachable.
Why this answer
If the next-hop in a PBR set command is not reachable (i.e., not in the routing table), PBR will fall back to the routing table for forwarding. PBR does not drop the packet; it uses the default routing decision.
Which BGP attribute is considered 'well-known mandatory' and must be present in all BGP update messages?
Correct. AS_PATH is well-known mandatory.
Why this answer
The AS_PATH attribute is well-known mandatory, meaning it must be included in all BGP updates. Other well-known mandatory attributes include NEXT_HOP and ORIGIN.
A network engineer runs the following command on Router R1: R1# show ip ospf database OSPF Router with ID (10.1.1.1) (Process ID 1) Router Link States (Area 0) Link ID ADV Router Age Seq# Checksum Link count 10.1.1.1 10.1.1.1 100 0x80000001 0x00A0B0 1 10.2.2.2 10.2.2.2 200 0x80000003 0x00C0D0 2 Net Link States (Area 0) Link ID ADV Router Age Seq# Checksum 10.1.1.2 10.1.1.2 150 0x80000001 0x00E0F0 R1# show ip route ospf 10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks O 10.2.2.0/24 [110/20] via 10.1.1.2, 00:10:00, FastEthernet0/0 Based on this output, what is a likely issue?
The database has more routes than the routing table, indicating filtering.
Why this answer
The OSPF database shows two routers and a net link, but only one OSPF route is in the routing table. This could be due to a route-map filtering OSPF routes. The correct answer is that a route-map may be filtering some OSPF routes from being installed.
Which TWO statements about route-maps used for route filtering are true? (Choose TWO.)
A deny statement explicitly denies the route when the match conditions are satisfied.
Why this answer
Route-maps permit or deny routes based on match conditions, and an implicit deny all exists at the end. If no match is found, the route is denied. The sequence number determines the order of evaluation; lower numbers are processed first.
The 'continue' clause allows jumping to a different sequence, not the next sequence automatically. A route-map can be used with multiple protocols, but it is not protocol-specific by default.
A network engineer runs the following command to troubleshoot a route filtering issue: R1# debug ip bgp updates BGP(0): 10.1.1.2 rcvd UPDATE w/ attr: nexthop 10.1.1.2, origin i, metric 0, path 65001 65002 BGP(0): 10.1.1.2 rcvd UPDATE about 192.168.100.0/24 -- DENIED due to: community no-export; What does this output indicate?
The debug output explicitly shows that the update is denied due to the no-export community.
Why this answer
The debug output shows that BGP received an update for prefix 192.168.100.0/24 from neighbor 10.1.1.2, but the update was denied because the prefix has the community 'no-export'. This indicates that an inbound route-map or filter is configured to deny routes with the no-export community.
An enterprise is using CoPP to protect the control plane. R1 has the following configuration: access-list 100 permit udp any any eq 179 class-map match-any BGP match access-group 100 policy-map COPP class BGP police 100000 20000 conform-action transmit exceed-action drop. Router R2 shows: 'show ip bgp summary' indicates the BGP session to R1 is flapping every 30 seconds. R1's 'show policy-map control-plane' shows drops for class BGP. What is the root cause?
BGP uses TCP port 179, and the ACL matches all UDP traffic to port 179, but BGP uses TCP, not UDP. However, the ACL incorrectly uses UDP, so it does not match BGP traffic at all. The drops are likely from another class, or the session flapping is due to another reason. Wait, the ACL uses UDP, so it does not match BGP (TCP). The correct answer should be that the ACL is misconfigured.
Why this answer
CoPP is rate-limiting BGP traffic (TCP port 179) to 100 kbps with a burst of 20 kbps. BGP keepalives and updates can exceed this rate, especially if there are many prefixes or if the session is flapping. The drops cause BGP packets to be lost, leading to hold timer expiry and session flapping.
The root cause is that the police rate is too low for the BGP traffic volume. The correct fix is to increase the police rate or add a more specific match to only rate-limit certain BGP packets.
Which THREE commands can be used to verify the effects of a route-map applied to a BGP neighbor for outbound route filtering? (Choose THREE.)
Correct. This shows the routes actually advertised to the neighbor, reflecting the outbound route-map filtering.
Why this answer
To verify outbound route-map filtering on a BGP neighbor, you can check the route-map itself, the BGP table for routes that should be filtered, and the neighbor's advertised routes. show ip bgp neighbor advertised-routes shows what the router is actually sending. show route-map displays the route-map configuration and match counts. show ip bgp shows the BGP table with path attributes. show ip bgp neighbors displays neighbor information but not the filtered routes. show ip prefix-list shows prefix-list entries but not the route-map application.
A network engineer runs the following command on Router R1: R1# show ip route vrf CUSTOMER_A Routing Table: CUSTOMER_A Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP a - application route + - replicated route, % - next hop override Gateway of last resort is not set 10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks B 10.10.10.0/24 [200/0] via 192.168.1.2, 00:10:00 B 10.20.20.0/24 [200/0] via 192.168.1.2, 00:10:00 R1# show ip bgp vpnv4 vrf CUSTOMER_A BGP table version is 6, local router ID is 10.1.1.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 100:1 (default for vrf CUSTOMER_A) *> 10.10.10.0/24 192.168.1.2 0 0 65001 i *> 10.20.20.0/24 192.168.1.2 0 0 65001 i *> 10.30.30.0/24 192.168.1.2 0 0 65001 i Based on this output, what is the likely issue?
BGP table has three routes, but routing table only has two, indicating filtering.
Why this answer
The VRF routing table shows only two routes, but the BGP table shows three routes for the VRF. This indicates that a route-map is filtering one of the routes from being installed in the routing table. The correct answer is that a route-map is filtering the route 10.30.30.0/24.
A network engineer runs the following command to verify CoPP (Control Plane Policing) with route-maps: R1# show policy-map control-plane input class class-default Control Plane Service-policy input: CoPP Class-map: class-default (match-any) 12234 packets, 1234567 bytes 5 minute offered rate 1000 bps, drop rate 0 bps Match: any police: cir 8000 bps, bc 1500 bytes, be 1500 bytes conformed 12234 packets, 1234567 bytes; actions: transmit exceeded 0 packets, 0 bytes; actions: drop violated 0 packets, 0 bytes; actions: drop What does this output indicate?
All packets have conformed to the police rate and have been transmitted, with no drops.
Why this answer
The output shows the CoPP policy applied to the control plane. The class-default matches all traffic and polices it at 8000 bps. All packets have conformed and been transmitted, with no drops.
This indicates that the CoPP policy is working and not dropping any traffic.
Consider the following configuration on router R2: !--- R2 configuration ip prefix-list FILTER seq 5 deny 10.1.0.0/16 le 24 ip prefix-list FILTER seq 10 permit 0.0.0.0/0 le 32 ! route-map BGP-IN permit 10 match ip address prefix-list FILTER ! router bgp 65000 neighbor 192.168.1.1 route-map BGP-IN in ! What is the effect of this configuration?
Correct. The prefix-list denies 10.1.0.0/16 le 24, which includes /16 to /24 subnets; all other prefixes are permitted.
Why this answer
The prefix-list FILTER denies any prefix within 10.1.0.0/16 with a mask length less than or equal to 24 (i.e., 10.1.0.0/16 through 10.1.255.0/24). The permit statement allows all other prefixes. The route-map BGP-IN calls this prefix-list; since there is only one permit sequence, routes that match the deny statement in the prefix-list are implicitly denied by the route-map.
Therefore, routes like 10.1.0.0/16, 10.1.1.0/24, etc., are filtered out.
A network engineer is troubleshooting reachability issues in a VRF-lite environment. R1 has the following configuration: ip vrf BLUE rd 100:1 route-target export 100:1 route-target import 100:1. R2 has: ip vrf BLUE rd 100:2 route-target export 100:2 route-target import 100:2. Both routers are connected via a link in the global routing table and are running OSPF in the VRF. R1 shows: 'show ip route vrf BLUE' has a route to 10.1.1.0/24 via OSPF, but R2 shows: 'show ip route vrf BLUE' does not have this route. What is the root cause?
VRF-lite relies on route-target matching for route import/export. Since the RTs differ, R2 does not import any routes from R1, even though OSPF is running in the VRF. OSPF only propagates routes within the same VRF, not between VRFs.
Why this answer
In VRF-lite, route leaking between VRFs is not automatic; it requires explicit configuration using route-map or VRF import/export policies. The RT values on R1 and R2 are different (100:1 vs 100:2), so even if OSPF is running within the VRF, routes are not shared because the route-target import/export do not match. OSPF in a VRF only propagates routes within the same VRF; it does not automatically leak routes to other VRFs.
The correct configuration would be to either use the same RT on both routers or configure a route-map to leak routes.
Examine the following configuration on R6: !--- R6 configuration route-map FILTER deny 10 match tag 50 ! route-map FILTER permit 20 ! router eigrp 200 distribute-list route-map FILTER in ! What is the effect of this configuration?
Correct. Sequence 10 denies routes with tag 50; sequence 20 permits everything else.
Why this answer
The distribute-list route-map FILTER in is applied to EIGRP updates received on all interfaces (since no interface is specified). Sequence 10 denies any route with tag 50. Sequence 20 permits all other routes.
Therefore, routes with tag 50 are filtered out (not installed in the routing table), while all other routes are accepted.
A network engineer is troubleshooting a route filtering problem with prefix-lists. Router R6 is using a prefix-list to filter routes from a BGP neighbor. The prefix-list is configured to permit only 192.168.0.0/16 and 192.168.1.0/24, but routes with prefix 192.168.2.0/24 are also being accepted. The engineer checks the prefix-list configuration and sees only two permit statements. What is the most likely cause?
Correct because if the prefix-list is not applied, no filtering occurs.
Why this answer
Prefix-lists have an implicit deny at the end, but if the prefix-list is not applied correctly (e.g., to the neighbor inbound direction), or if the prefix-list has a 'ge' or 'le' operator that is too broad, it could permit more than intended. However, the most common issue is that the prefix-list is not applied at all, or the neighbor is using a different filter.
Consider the following configuration on R5: !--- R5 configuration ip prefix-list PL-2 seq 5 permit 10.0.0.0/8 ge 16 le 24 ! route-map RMAP permit 10 match ip address prefix-list PL-2 set community 100:100 ! router bgp 65200 neighbor 192.168.1.2 route-map RMAP out ! What is the effect of this configuration?
Correct. The prefix-list permits 10.0.0.0/8 ge 16 le 24; matching routes get community set and are advertised.
Why this answer
The prefix-list PL-2 permits prefixes that match 10.0.0.0/8 with a mask length greater than or equal to 16 and less than or equal to 24. So, for example, 10.1.0.0/16, 10.1.1.0/24 are permitted, but 10.0.0.0/8 itself (mask 8) is not. The route-map RMAP sets community 100:100 on matching routes.
Routes that do not match the prefix-list are not processed by this route-map (since there is only one sequence), so they are denied (not sent to neighbor).
Examine the following partial configuration on R1: !--- R1 configuration route-map RMAP permit 10 match ip address prefix-list PL-1 set metric 100 ! route-map RMAP permit 20 set metric 200 ! router eigrp 100 network 10.0.0.0 redistribute ospf 1 metric 1000 100 255 1 1500 route-map RMAP ! What is the effect of this configuration?
Correct. Sequence 10 matches PL-1 and sets metric 100; sequence 20 matches all other routes and sets metric 200.
Why this answer
The route-map RMAP has two permit sequences. The first matches prefix-list PL-1 and sets metric to 100. The second is a catch-all permit with no match, setting metric to 200.
All redistributed OSPF routes will match either sequence and have their metric set accordingly. If a route matches the first sequence, its metric is set to 100; otherwise, it matches the second and gets metric 200. There is no deny sequence, so no routes are filtered.
A network engineer runs the following command on Router R1: R1# show bgp ipv4 unicast 10.10.10.0/24 BGP routing table entry for 10.10.10.0/24, version 5 Paths: (1 available, best #1, table default) Advertised to update-groups: 1 Refresh Epoch 1 Local 10.1.1.2 from 10.1.1.2 (10.2.2.2) Origin IGP, metric 0, localpref 100, valid, external, best rx pathid: 0, tx pathid: 0x0 (received-only) Based on this output, what does the "(received-only)" flag indicate?
The received-only flag means the route is not used, often due to filtering.
Why this answer
The "(received-only)" flag indicates that the route was received from a neighbor but is not installed in the routing table, often due to a route-map filtering or a prefix-list. The correct answer is that a route-map is likely filtering this route from being installed.
An OSPF network is experiencing routing loops between two routers. R1 has the following configuration: interface GigabitEthernet0/0 ip address 10.1.1.1 255.255.255.0 ip ospf network point-to-point. R2 has: interface GigabitEthernet0/0 ip address 10.1.1.2 255.255.255.0 ip ospf network broadcast. Both routers are in area 0. R1 shows: 'show ip ospf neighbor' lists R2 as FULL/DR, but R2 shows R1 as FULL/DROTHER. Traffic between two subnets behind each router is looping. What is the root cause?
R1's point-to-point configuration means it does not participate in DR election, so R2 becomes DR. R1 treats the link as a point-to-point link and may not advertise the correct type 2 LSA, while R2 advertises a type 2 LSA. This mismatch can cause R1 to learn routes via R2 and R2 to learn routes via R1, creating a loop.
Why this answer
OSPF network type mismatch on a multi-access link can cause adjacency issues. R1 is configured as point-to-point, which does not participate in DR/BDR election and expects a point-to-point link. R2 is configured as broadcast, which expects a DR/BDR election.
This mismatch can cause both routers to form an adjacency (since OSPF still works), but they have different views of the network. R1 thinks the link is point-to-point and does not expect a DR, so it may advertise the link as a stub network or with different metrics. R2 thinks it is the DR (since R1 is not participating in election), and it advertises the link as a transit network.
This inconsistency can cause routing loops because R1 may advertise a route via R2, and R2 may advertise the same route via R1, creating a loop. The correct fix is to match the network type on both ends.
A network engineer runs the following command on Router R1: R1# show ip bgp neighbors 192.168.1.2 advertised-routes BGP table version is 14, local router ID is 10.1.1.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 10.10.10.0/24 192.168.1.2 0 0 65001 i *> 10.20.20.0/24 192.168.1.2 0 0 65001 i Total number of prefixes 2 Based on this output, what is a likely issue?
Only two prefixes are advertised; a route-map applied to the neighbor could be restricting the advertisement.
Why this answer
The output shows only two prefixes advertised to the neighbor, but the network likely has more routes. The route-map applied to the neighbor may be filtering routes. The correct answer identifies that a route-map is likely filtering out other prefixes.
An engineer configures a route map to filter BGP routes based on AS-path using a regex. The route map is applied inbound to an eBGP neighbor. The engineer notices that routes with an AS-path containing the neighbor's AS are still being accepted. Which is the most likely explanation?
eBGP prepends the local AS before route map processing; the route map sees the modified path.
Why this answer
When an eBGP route is received, the router prepends its own AS to the AS-path before the route map is applied. Therefore, if the route map is trying to match the neighbor's AS in the AS-path, it will fail because the neighbor's AS is now the first AS in the path. The edge case is that the AS-path is modified before the route map is processed.
A large enterprise network is experiencing intermittent connectivity between Site A (R1) and Site B (R2) over an MPLS L3VPN. R1 has the following relevant configuration: route-map RMAP-IN permit 10 match ip address prefix-list PL-ALLOW set extcommunity rt 100:1. Router R2 shows: 'show bgp vpnv4 unicast all neighbors 10.1.1.1 received-routes' lists only the default route, but 'show ip route vrf CUSTOMER' shows no default route. What is the root cause?
The route-map has only one permit sequence matching the default route, so all other VPNv4 routes are denied by the implicit deny at the end of the route-map. This prevents R1 from receiving routes for other prefixes.
Why this answer
The route-map RMAP-IN on R1 is configured to set the route-target extended community (RT) on incoming BGP VPNv4 routes. However, the route-map is applied inbound on the BGP session, which means it modifies routes received from R2. The match condition uses prefix-list PL-ALLOW, which likely permits only the default route.
The set extcommunity rt 100:1 command overwrites or adds the RT, but if the route-map does not explicitly permit other routes (e.g., via a subsequent permit statement), those routes are denied by the implicit deny at the end of the route-map. This causes R1 to reject all routes except the default, but the default route may not be installed in the VRF due to missing RT matching or other VRF configuration issues. The correct fix is to add a permit statement for all necessary prefixes or remove the route-map from the neighbor statement.
A network engineer is troubleshooting a BGP route-map that is supposed to prepend AS-path to routes from a specific neighbor. The engineer configures a route-map with 'set as-path prepend 65001' and applies it outbound to the neighbor. After the configuration, the engineer checks the BGP table on the neighbor and sees that the AS-path does not include the prepended AS. What is the most likely cause?
Correct because a route-map without a match statement will not match any routes, so the set command is not executed.
Why this answer
The 'set as-path prepend' command must be used with 'ip as-path access-list' or in a route-map, but the route-map must be applied in the correct direction. If the route-map is applied outbound, it modifies the AS-path before sending. However, if the neighbor is an eBGP neighbor, the router will not prepend its own AS unless the AS is different from the neighbor's AS.
Also, the route-map must have a 'match' statement that matches the routes.
An engineer configures a DMVPN Phase 2 network. Spoke routers are configured with a route map that sets the next-hop to the tunnel interface for routes learned from the hub. This is intended to allow spoke-to-spoke direct communication. However, spoke-to-spoke traffic still goes through the hub. Which is the most likely explanation?
The hub must set the next-hop to the remote spoke's tunnel IP; the spoke cannot change the next-hop for routes received from the hub.
Why this answer
In DMVPN Phase 2, spoke-to-spoke direct communication requires that the spoke routers have a route with the next-hop set to the tunnel interface of the remote spoke. However, if the route map is applied inbound on the spoke from the hub, it sets the next-hop to the hub's tunnel interface, not the remote spoke. The correct approach is to use a route map on the hub that sets the next-hop to the spoke's tunnel IP when advertising routes, or to use the 'next-hop-self' command incorrectly.
The edge case is that the route map is applied on the spoke, not the hub.
In Cisco IOS-XE, what is the default behavior of the 'route-map' command when no 'match' or 'set' clauses are configured?
Correct. An empty permit route-map matches everything and does nothing.
Why this answer
A route-map without any match or set clauses is a permit statement that matches all routes and performs no modifications. This is a common source of unintended route filtering.
A network engineer is troubleshooting suboptimal routing in a DMVPN Phase 2 deployment. Hub router R1 has the following configuration: route-map SET-NEXT-HOP permit 10 match ip address prefix-list SPOKE-NET set ip next-hop 10.0.0.1. Spoke R2 shows: 'show ip route 192.168.1.0' points to the hub (R1) instead of directly to another spoke (R3). R2's NHRP shows 'show dmvpn' with no spoke-to-spoke tunnels established. What is the root cause?
By setting the next-hop to the hub, R2 sees R1 as the next-hop for 192.168.1.0, so it does not attempt to build a direct tunnel to R3. NHRP requires the next-hop to be the remote spoke's tunnel IP.
Why this answer
In DMVPN Phase 2, spoke-to-spoke tunnels require that the next-hop in the routing table not be changed to the hub. The route-map SET-NEXT-HOP on R1 is setting the next-hop to the hub's tunnel IP (10.0.0.1) for routes matching SPOKE-NET. This causes spokes to see the hub as the next-hop for other spoke networks, preventing NHRP from triggering a spoke-to-spoke tunnel.
The correct behavior is to not set the next-hop (or set it to itself) so that spokes use the original next-hop (the other spoke's tunnel IP) and NHRP can resolve it.
A network engineer runs the following command to troubleshoot IPsec with route-maps: R1# show crypto ipsec transform-set Transform set combined: { esp-aes 256 esp-sha-hmac } will negotiate = { Transport, } Transform set ESP-AES: { esp-aes 256 esp-sha-hmac } will negotiate = { Tunnel, } What does this output indicate?
The output shows two transform sets with different modes: transport and tunnel.
Why this answer
The output shows two IPsec transform sets: 'combined' and 'ESP-AES'. The 'combined' set uses transport mode, while 'ESP-AES' uses tunnel mode. This indicates that different transform sets are configured for different purposes.
Which of the following is true regarding the use of prefix-lists versus access-lists for route filtering?
Correct. Prefix-lists can specify both the prefix and a range of prefix lengths.
Why this answer
Prefix-lists are designed specifically for route filtering and can match on prefix length using ge and le operators. Access-lists match on source/destination IP and wildcard mask but do not have the ability to specify prefix length ranges. Prefix-lists are more efficient and flexible for route filtering.
A network engineer runs the following command to verify BGP route filtering: R1# show bgp ipv4 unicast 192.168.1.0/24 BGP routing table entry for 192.168.1.0/24, version 2 Paths: (1 available, best #1, table default) Advertised to update-groups: 1 Refresh Epoch 1 Local, (received & used) 10.1.1.2 (metric 20) from 10.1.1.2 (2.2.2.2) Origin IGP, metric 0, localpref 100, valid, internal, best rx pathid: 0, tx pathid: 0x0 Community: no-export What does the 'Community: no-export' indicate?
The no-export community tells BGP not to advertise the route to any eBGP peers.
Why this answer
The community 'no-export' indicates that this route should not be advertised to any eBGP peers. This is a well-known community that controls route propagation.
A network engineer is troubleshooting a redistribution loop between OSPF and EIGRP. Router R7 is redistributing EIGRP routes into OSPF, and also redistributing OSPF routes into EIGRP. The engineer notices that some OSPF routes are appearing in the EIGRP topology table with a higher metric than expected, causing suboptimal routing. What is the most likely cause?
Correct because route tags allow filtering to prevent redistribution loops.
Why this answer
Redistribution loops can cause routes to be re-injected with different metrics. The most common fix is to use route-maps with tags to prevent re-redistribution. Without proper tagging, routes can loop between the two protocols.
A network engineer runs the following command on Router R1: R1# show ip policy Interface Route-map FastEthernet0/0 PBR_MAP R1# show route-map PBR_MAP route-map PBR_MAP, permit, sequence 10 Match clauses: ip address prefix-list MATCH_HTTP Set clauses: ip next-hop 10.10.10.2 Policy routing matches: 0 packets, 0 bytes Based on this output, what is the most likely problem?
0 packets matched indicates no traffic matches the prefix-list.
Why this answer
The route-map PBR_MAP is applied to FastEthernet0/0 for policy routing, but the match counter shows 0 packets matched. This indicates that either the prefix-list MATCH_HTTP is not matching any traffic, or no traffic is hitting the interface. The correct answer is that the prefix-list may be misconfigured or not matching desired traffic.
Drag and drop the steps to apply a route-map to filter BGP prefix advertisements into the correct order, from first to last.
Drag steps to the numbered slots on the right, or tap a step then tap a slot.
Why this order
First, define the route-map with a permit or deny clause and match criteria. Second, configure the set actions to modify attributes. Third, apply the route-map to the BGP neighbor using the neighbor route-map command.
Fourth, clear the BGP session to activate the filter. Finally, verify the filtered prefixes using show ip bgp.
What is the default behavior of a route-map when a route does not match any match clause in any sequence?
Correct. If a route does not match any sequence, it is implicitly denied.
Why this answer
A route-map consists of sequences with permit or deny actions. If a route does not match any match clause in any sequence, it is implicitly denied. This is similar to an access-list: there is an implicit deny at the end of the route-map.
An engineer configures IPsec site-to-site VPN with a route map that defines interesting traffic using an extended access list. The VPN tunnel is established, but traffic from the local LAN to the remote LAN is not encrypted. The engineer verifies that the access list matches the traffic correctly. Which is the most likely explanation?
Crypto maps only support access lists for interesting traffic; route maps are not valid.
Why this answer
In IPsec, the crypto map applies to the interface, and the access list defines interesting traffic. However, if the route map is applied to the crypto map, it is not used for interesting traffic; route maps are not supported for defining interesting traffic in crypto maps. The correct method is to use an access list directly in the crypto map.
The edge case is that the engineer mistakenly used a route map instead of an access list.
Examine the following configuration on R3: !--- R3 configuration access-list 10 permit 192.168.0.0 0.0.255.255 access-list 10 deny any ! route-map OSPF-REDIST permit 10 match ip address 10 set metric-type type-1 ! router ospf 1 redistribute eigrp 100 subnets route-map OSPF-REDIST ! What is the effect of this configuration?
Correct. The ACL permits 192.168.0.0/16; the route-map sets metric-type type-1 for matching routes.
Why this answer
The ACL 10 permits only routes with source IP in the 192.168.0.0/16 range. The route-map OSPF-REDIST matches this ACL and sets the metric type to type-1. Only EIGRP routes that match the ACL (i.e., have a network starting with 192.168.x.x) are redistributed into OSPF as type-1 external routes.
Routes not matching the ACL are denied because the route-map has only one permit sequence and the ACL ends with deny any.
Drag and drop the steps to troubleshoot Route Maps and Route Filtering adjacency or connectivity failures into the correct order, from first to last.
Drag steps to the numbered slots on the right, or tap a step then tap a slot.
Why this order
Start by verifying BGP neighbor state with show ip bgp summary. Next, examine the route-map configuration for syntax errors using show route-map. Then, check if the route-map is applied correctly to the neighbor with show running-config.
After that, use debug ip bgp updates to see if prefixes are being filtered. Finally, adjust the route-map sequence or match criteria to resolve the issue.
In OSPF, what is the default hello interval on a point-to-point network type?
Correct. Point-to-point and broadcast networks use a 10-second hello interval.
Why this answer
OSPF default hello interval is 10 seconds for broadcast and point-to-point networks, and 30 seconds for NBMA networks. This is defined in RFC 2328.
An MPLS network is experiencing label distribution failures. Router R1 (LSR) has the following configuration: mpls ldp neighbor 10.0.0.2 password cisco. Router R2 shows: 'show mpls ldp neighbor' lists R1 as 'Oper Down' with reason 'TCP MD5 authentication failure'. R1's 'show mpls ldp neighbor' shows R2 as 'Oper Down' with the same reason. Both routers have the same password configured. What is the root cause?
The 'mpls ldp neighbor' command expects the neighbor's LDP transport address (usually the router ID). If R1 uses 10.0.0.2 but R2's transport address is different (e.g., 10.0.0.3), the TCP connection uses a different IP, and MD5 authentication fails because the password is associated with the wrong IP.
Why this answer
LDP uses TCP for session establishment, and MD5 authentication is configured via the 'mpls ldp neighbor' command. However, the password must match on both ends, and the command must specify the correct neighbor IP. If the IP address specified is incorrect (e.g., using a loopback IP instead of the transport address), the authentication will fail.
Additionally, the 'mpls ldp password' command under the interface or global configuration may be required. In this scenario, the root cause is likely that the neighbor IP in the command does not match the actual LDP transport address (e.g., R1 uses 10.0.0.2 but R2's LDP transport address is 10.0.0.3).
In BGP, what is the effect of using a route-map with a set community command but without the additive keyword?
Correct. Without additive, set community replaces the community attribute.
Why this answer
When set community is used without the additive keyword, it replaces any existing community attributes on the route with the specified community. With the additive keyword, the specified community is added to the existing communities.
What is the default administrative distance for routes learned via OSPF in Cisco IOS?
Correct. OSPF uses AD 110 by default.
Why this answer
OSPF has a default administrative distance of 110, as defined in Cisco IOS. This is used for route selection when multiple routing protocols provide the same prefix.
Which THREE symptoms indicate that a route-map applied to a redistribution configuration is not working as intended? (Choose THREE.)
This indicates the route-map is not denying the intended routes.
Why this answer
Common symptoms of misconfigured route-maps include missing routes in the routing table, routes with wrong metrics, and no change after modifying the route-map (due to route-map caching or not reapplying). Routes with correct next hops but wrong administrative distance usually indicate a different issue. Routes appearing in the routing table with correct attributes suggest the route-map is working.
Router R4 has the following configuration: !--- R4 configuration route-map SETTAG permit 10 match tag 100 set tag 200 ! route-map SETTAG permit 20 ! router bgp 65100 neighbor 10.0.0.1 route-map SETTAG in ! What is the effect of this configuration?
Correct. Sequence 10 changes the tag for routes with tag 100; sequence 20 permits all others.
Why this answer
The route-map SETTAG has two permit sequences. Sequence 10 matches routes with tag 100 and sets the tag to 200. Sequence 20 is a catch-all permit with no match or set statements.
Routes from neighbor 10.0.0.1 that have tag 100 will have their tag changed to 200; all other routes are permitted unchanged. No routes are filtered.
An engineer configures a BGP route reflector with a route map that sets a higher local preference on routes received from a client. The route map is applied to the neighbor statement for the client. Unexpectedly, the route reflector does not reflect the modified local preference to other clients. Which is the most likely explanation?
Outbound route maps affect routes sent to the neighbor, not routes received; reflection happens before outbound processing.
Why this answer
When a route map is applied to a BGP neighbor inbound, it modifies the route before it is installed in the BGP table. However, route reflectors reflect routes based on the best path selection, and if the local preference is set, it should be reflected. The issue is that the route map is applied outbound instead of inbound, or the route map does not explicitly set the local preference before the route is processed.
The most common edge case is that the route map is applied outbound, which does not affect the route before reflection.
In EIGRP, what is the default hello timer on a point-to-point interface?
Correct. Point-to-point links use a 5-second hello interval by default.
Why this answer
EIGRP uses a default hello interval of 5 seconds on high-speed interfaces (including point-to-point) and 60 seconds on low-speed NBMA interfaces (T1 or slower).
Which TWO commands can be used to verify the effect of a route-map applied to a BGP neighbor? (Choose TWO.)
This command shows the routes that are actually advertised to the neighbor after any outbound route-map filtering.
Why this answer
The commands 'show ip bgp neighbors x.x.x.x advertised-routes' and 'show ip bgp neighbors x.x.x.x routes' directly show the routes being sent or received after route-map filtering. 'show route-map' only displays the route-map definition, not its effect on a specific neighbor. 'show ip bgp' displays the BGP table without neighbor-specific filtering context. 'show ip bgp neighbors' alone does not show the filtered routes.
A network engineer runs the following command on Router R1: R1# show ip bgp neighbors 10.1.1.2 advertised-routes BGP table version is 10, local router ID is 10.1.1.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 10.10.10.0/24 0.0.0.0 0 32768 i *> 10.20.20.0/24 0.0.0.0 0 32768 i R1# show route-map route-map BLOCK_RFC1918, permit, sequence 10 Match clauses: ip address prefix-list RFC1918 Set clauses: Policy routing matches: 0 packets, 0 bytes route-map BLOCK_RFC1918, deny, sequence 20 Match clauses: Set clauses: Policy routing matches: 0 packets, 0 bytes R1# show ip prefix-list RFC1918 ip prefix-list RFC1918: 3 entries seq 5 deny 10.0.0.0/8 le 32 seq 10 deny 172.16.0.0/12 le 32 seq 15 deny 192.168.0.0/16 le 32 seq 20 permit 0.0.0.0/0 le 32 Based on this output, what is the most likely issue?
The prefix-list denies RFC 1918, but the route-map is not applied to the neighbor, so routes are advertised.
Why this answer
The route-map BLOCK_RFC1918 is applied to filter routes, but the advertised routes include 10.10.10.0/24 and 10.20.20.0/24, which are RFC 1918 addresses. The prefix-list RFC1918 should deny these, but the route-map is not being applied to the BGP neighbor, so routes are not filtered. The correct answer is that the route-map is not applied to the BGP neighbor.
A network engineer runs the following command on Router R1: R1# show ip bgp neighbors 192.168.1.2 BGP neighbor is 192.168.1.2, remote AS 65001, external link BGP version 4, remote router ID 10.2.2.2 BGP state = Established, up for 00:15:00 Last read 00:00:05, hold time is 180, keepalive interval is 60 seconds Neighbor sessions: 1 active, is multisession capable Neighbor capabilities: Route refresh: advertised and received(new) Four-octets ASN: advertised and received Address family IPv4 Unicast: advertised and received Enhanced Refresh: advertised Message statistics: InQ depth is 0 OutQ depth is 0 Sent Rcvd Opens: 1 1 Notifications: 0 0 Updates: 10 5 Keepalives: 15 15 Route Refresh: 0 0 Total: 26 21 Default minimum time between advertisement runs is 30 seconds For address family: IPv4 Unicast Session: 192.168.1.2 BGP table version 14, neighbor version 14/0 Output queue size : 0 Index 1, Advertise bit 0 1 update-group member Incoming update prefix filter list: FILTER_IN Outgoing update prefix filter list: FILTER_OUT Sent Rcvd Prefixes: 2 2 Updates: 10 5 Based on this output, what is the effect of the prefix lists?
The counters show 2 prefixes sent and received, matching the filter lists.
Why this answer
The output shows that incoming and outgoing prefix filters (FILTER_IN and FILTER_OUT) are applied. The prefixes sent and received are both 2, indicating that the filters are allowing exactly 2 prefixes in each direction. The correct answer is that the prefix lists are filtering routes to only 2 prefixes.
An engineer configures a route map to filter OSPF routes using a distribute-list in OSPF process 1. The distribute-list references a prefix-list that permits only the 10.0.0.0/8 network. After applying the distribute-list in, the engineer notices that the OSPF neighbor state remains stuck in EXSTART/EXCHANGE. Which is the most likely explanation?
MTU mismatch causes OSPF to get stuck in EXSTART/EXCHANGE because DBD packets are dropped.
Why this answer
OSPF distribute-list in only filters routes in the routing table, not LSAs. It does not affect the exchange of LSAs during adjacency formation. The adjacency stall is unrelated to the distribute-list; the issue is likely an MTU mismatch between the interfaces.
An engineer configures unicast Reverse Path Forwarding (uRPF) in strict mode on an interface connected to a service provider. The router has a default route pointing to the ISP. Traffic from the ISP is being dropped by uRPF. Which is the most likely explanation?
By default, strict mode ignores default routes; 'allow-default' includes them.
Why this answer
Strict mode uRPF checks that the source IP of incoming packets has a matching route in the routing table that points back to the same interface. If the router has a default route, it may not match the specific source IP, causing drops. However, the edge case is that the default route is not considered by strict mode unless the 'allow-default' option is configured.
Without 'allow-default', strict mode requires a specific route back to the interface.
An engineer configures Control Plane Policing (CoPP) with a policy map that includes a class-map matching BGP traffic. The policy map has a 'police' action that sets the rate-limit in bps. After applying the policy to the control plane, BGP sessions start flapping. Which is the most likely explanation?
bps rate-limit can drop many small packets; pps is recommended for control plane traffic.
Why this answer
CoPP rate-limits are often configured in bps by default, but for control plane traffic, pps (packets per second) is more appropriate. If the rate-limit is set in bps, it may be too low for BGP keepalive packets, which are small. The edge case is that the engineer used bps instead of pps, causing the policer to drop BGP packets.
A network engineer runs the following command to verify MPLS LDP route filtering: R1# show mpls ldp bindings 192.168.10.0 255.255.255.0 lib entry: 192.168.10.0/24, rev 6 local binding: label: 21 remote binding: lsr: 2.2.2.2:0, label: 22 remote binding: lsr: 3.3.3.3:0, label: 23 What does this output indicate?
The output clearly shows the local binding label 21 and two remote bindings with labels 22 and 23.
Why this answer
The output shows the MPLS LDP label bindings for prefix 192.168.10.0/24. The local label is 21, and remote labels from two LSRs (2.2.2.2 and 3.3.3.3) are 22 and 23 respectively. This indicates that the prefix is known in the MPLS network and labels have been assigned.
A network administrator is troubleshooting BGP path selection for a dual-homed enterprise. Router R1 (AS 65001) has the following configuration: route-map SET-LOCAL-PREF permit 10 match ip address prefix-list PREFER set local-preference 200. Router R2 (AS 65002) shows: 'show bgp ipv4 unicast 10.1.1.0' has two paths: one via R1 with local pref 200, and one via R3 with local pref 100. However, 'show ip route 10.1.1.0' on R2 shows the path via R3 is installed. What is the root cause?
Local preference is a well-known mandatory attribute that is not passed between ASes. If the route-map is applied outbound on R1, it sets local preference in R1's BGP table, but when the route is sent to R2, the local preference is reset to 100 (default) because it is not sent in eBGP updates. R2 sees the path via R1 with local pref 100, not 200.
Why this answer
BGP path selection compares local preference first, so the path with local pref 200 should be preferred. However, if the route-map SET-LOCAL-PREF is applied inbound on R2 from R1, but the prefix-list PREFER does not match the route (e.g., incorrect prefix or mask), then the local preference is not set, and the default local preference (100) applies. The show bgp output shows local pref 200 for the path via R1, which suggests the route-map is applied correctly, but the route may be received from R1 with a different attribute (e.g., a higher MED or longer AS path) that overrides local preference after the fact.
Alternatively, if the route-map is applied outbound on R1, it would not affect R2's path selection. The root cause is that the route-map is applied on the wrong neighbor or direction.
A network engineer runs the following command on Router R1: R1# show ip eigrp topology 10.10.10.0/24 IP-EIGRP (AS 100): Topology entry for 10.10.10.0/24 State is Passive, Query origin flag is 1, 1 Successor(s), FD is 131072 Routing Descriptor Blocks: 10.1.1.2 (FastEthernet0/0), from 10.1.1.2, Send flag is 0x0 Composite metric is (131072/128256), Route is Internal Vector metric: Minimum bandwidth is 10000 Kbit Total delay is 100 microseconds Reliability is 255/255 Load is 1/255 Minimum MTU is 1500 Hop count is 1 R1# show ip route 10.10.10.0 Routing entry for 10.10.10.0/24 Known via "eigrp 100", distance 90, metric 131072, type internal Last update from 10.1.1.2 on FastEthernet0/0, 00:00:12 ago Routing Descriptor Blocks: * 10.1.1.2, from 10.1.1.2, 00:00:12 ago, via FastEthernet0/0 Route metric is 131072, traffic share count is 1 R1# show ip eigrp interfaces Interface Peers Xmit Queue Mean Pacing Time Multicast Pending Un/Reliable SRTT Un/Reliable Flow Timer Routes Fa0/0 1 0/0 10 0/10 50 0 Fa0/1 0 0/0 0 0/10 50 0 Based on this output, what is a likely issue?
FastEthernet0/1 has 0 peers, indicating no neighbor; a route-map could be blocking hello packets or updates.
Why this answer
The route is in the topology table and routing table, but the interface FastEthernet0/1 has 0 peers. This suggests that a route-map filtering EIGRP updates on FastEthernet0/1 may be preventing neighbor formation or route advertisement. The correct answer is that a route-map may be filtering EIGRP updates on FastEthernet0/1.
Which TWO statements about the behavior of route-map sequence numbers and the "continue" clause in Cisco IOS are true? (Choose TWO.)
Correct. If no match command is configured, the sequence matches all routes by default.
Why this answer
The continue clause allows a route-map to jump to a later sequence after a match, but not to an earlier one. If a sequence does not have a match statement, it matches all routes by default. The default action for an unmatched route is to deny (implicit deny).
The continue clause is processed only if the current sequence matches and the set actions are applied; it does not skip the current sequence's processing. Sequence numbers are evaluated in ascending order, and the first match wins.
What is the default maximum number of paths that BGP can install in the routing table using the 'maximum-paths' command in Cisco IOS?
Correct. BGP defaults to a single path unless explicitly configured otherwise.
Why this answer
By default, BGP installs only one best path (maximum-paths 1). This can be increased to allow load balancing, but the default is 1.
A network engineer runs the following command to verify redistribution with route-maps: R1# show ip route 10.10.10.0 255.255.255.0 Routing entry for 10.10.10.0/24 Known via "eigrp 100", distance 170, metric 2560002816 Tag 100, type internal Last update from 10.1.1.2 on GigabitEthernet0/0, 00:00:45 ago Routing Descriptor Blocks: * 10.1.1.2, from 10.1.1.2, 00:00:45 ago, via GigabitEthernet0/0 Route metric is 2560002816, traffic share count is 1 Total delay is 2000 microseconds, minimum bandwidth is 100000 Kbit Reliability 255/255, minimum MTU 1500 bytes Loading 1/255, Hops 1 What does the 'Tag 100' indicate?
The 'Tag 100' is a route tag, commonly set by a route-map to mark routes for filtering or administrative purposes.
Why this answer
The 'Tag 100' indicates that a route-map applied during redistribution set the tag to 100. Route tags are often used for filtering or administrative purposes during redistribution.
An engineer configures EIGRP named mode with an offset-list applied to the EIGRP topology table. The offset-list increases the metric of a route learned from a neighbor. However, the route is still used as the successor even though the offset-list increased its metric above the feasible distance (FD) of another route. Which is the most likely explanation?
Offset-list modifies the metric of the route but does not update the FD, which is the metric of the best path at the time of learning.
Why this answer
In EIGRP named mode, the offset-list is applied to the route's metric in the topology table, but it does not affect the feasible distance (FD) calculation. The FD is computed from the original metric before the offset. The successor is chosen based on the FD, not the offset metric, so the route remains the successor.
A network engineer runs the following command to troubleshoot OSPF route filtering: R1# show ip ospf database router 2.2.2.2 OSPF Router with ID (1.1.1.1) (Process ID 1) Router Link States (Area 0) LS age: 300 Options: (No TOS-capability, DC) LS Type: Router Links Link State ID: 2.2.2.2 Advertising Router: 2.2.2.2 LS Seq Number: 80000004 Checksum: 0x1234 Length: 48 Number of Links: 2 Link connected to: a Stub Network (Link ID) Network/subnet number: 10.1.1.0 (Link Data) Network Mask: 255.255.255.0 Number of TOS metrics: 0 TOS 0 Metrics: 10 Link connected to: a Transit Network (Link ID) Designated Router address: 10.1.1.2 (Link Data) Router Interface address: 10.1.1.1 Number of TOS metrics: 0 TOS 0 Metrics: 10 What does this output indicate?
The LSA shows two links: a stub network and a transit network. The stub network is 10.1.1.0/24.
Why this answer
The output shows the OSPF router LSA from router 2.2.2.2. It lists two links: one stub network (10.1.1.0/24) and one transit network (via DR 10.1.1.2). This is normal OSPF operation.
A network engineer is troubleshooting a BGP route filtering issue. Router R1 is advertising a prefix 10.1.1.0/24 to its eBGP neighbor R2, but R2 is not receiving it. The engineer checks R1's BGP configuration and sees a route-map named FILTER-OUT applied outbound to the neighbor. The route-map references an ACL that permits 10.1.1.0/24, but the prefix is still not being sent. What is the most likely cause?
Correct because route-maps without an explicit permit will implicitly deny all prefixes.
Why this answer
The route-map must have an explicit permit statement; if the route-map is missing the permit clause, or if the sequence number is incorrect, the implicit deny at the end of the route-map will filter all routes. The ACL permitting the prefix is necessary but not sufficient if the route-map itself does not have a permit action.
A network engineer is troubleshooting a PBR (Policy-Based Routing) issue on router R5. The engineer configured a route-map to set the next-hop for traffic from a specific source subnet. The route-map is applied to the incoming interface, but traffic from the source subnet is still being forwarded using the regular routing table. The engineer verifies that the ACL matches the traffic correctly. What is the most likely cause?
Correct because without a valid 'set' command, PBR does not alter forwarding.
Why this answer
PBR route-maps must have at least one 'match' and one 'set' statement. If the route-map has a 'match ip address' but no 'set ip next-hop' (or the next-hop is unreachable), PBR will not apply and traffic will use the routing table. Also, the route-map must be applied to the correct interface and direction.
Which TWO statements about the 'match ip address' command within a route-map are true? (Choose TWO.)
The command accepts access-list numbers/names and prefix-list names.
Why this answer
The 'match ip address' command can reference either a standard or extended access-list, or a prefix-list. It matches the destination network of the route. It cannot match source address (that would be 'match ip next-hop' or 'match ip route-source').
The command can be used in both permit and deny sequences. A single route-map sequence can have multiple match commands, but they are logically ANDed only if under the same match statement type.
A network engineer is troubleshooting a route filtering issue using distribute-lists under OSPF. Router R8 has a distribute-list out applied to the OSPF process to filter routes being advertised to a specific neighbor. The distribute-list references an ACL that denies a specific prefix, but the prefix is still being advertised to the neighbor. What is the most likely cause?
Correct because per-neighbor filtering requires the distribute-list under the neighbor command.
Why this answer
Distribute-lists under OSPF can be applied in or out, but the 'out' direction filters routes being advertised out of the OSPF process to all neighbors. However, if the distribute-list is applied to the OSPF process (not to a specific interface), it filters routes from the routing table into OSPF, not to a specific neighbor. To filter per neighbor, a distribute-list must be applied to the neighbor under the OSPF process using 'neighbor x.x.x.x distribute-list'.
Which TWO statements about using prefix-lists in conjunction with route-maps for filtering IPv4 routes are true? (Choose TWO.)
Correct. The ge (greater or equal) operator matches prefixes with a mask length >= the specified value.
Why this answer
Prefix-lists can match on prefix length and subnet mask using ge and le operators. A prefix-list entry can be configured to permit or deny. When used in a route-map, the match ip address prefix-list command references the prefix-list.
If the prefix-list denies, the route-map clause is not matched, and the route falls to the next clause. The prefix-list can also be used directly in a distribute-list without a route-map.
An engineer configures mutual redistribution between OSPF and EIGRP. A route map is used to set the OSPF metric type to type-1 when redistributing EIGRP routes into OSPF. However, the redistributed routes appear as type-2 in the OSPF database. Which is the most likely explanation?
OSPF may ignore the metric type if the metric is not explicitly set in the route map.
Why this answer
When redistributing into OSPF, the default metric type is type-2. If the route map sets the metric type but does not also set the metric, OSPF may ignore the metric type setting because the metric is not specified. In some IOS versions, the route map must set both the metric and metric type for the metric type to take effect.
Which TWO configuration steps are required to filter routes using a prefix-list in a route-map applied to a BGP neighbor? (Choose TWO.)
The prefix-list defines which prefixes to match.
Why this answer
To filter routes, you must define the prefix-list to match the desired prefixes, then create a route-map that uses the prefix-list in a match statement. The route-map is then applied to the BGP neighbor. Defining an access-list is an alternative but not required if using a prefix-list.
The 'network' command under BGP is for originating routes, not filtering. The 'distribute-list' command is a separate method and does not use a route-map.
A network engineer is troubleshooting a BGP route-map that is supposed to set a community value on routes from a specific neighbor. The engineer configures a route-map with 'set community 100:100' and applies it inbound to the neighbor. After the configuration, the engineer checks the BGP table on the local router and sees that the routes do not have the community set. What is the most likely cause?
Correct because communities are not exchanged without this command.
Why this answer
By default, BGP does not send or receive communities unless the 'neighbor send-community' command is configured. Even if the route-map sets the community, the router will not attach it to the routes unless the neighbor is configured to send communities.
Which statement correctly describes the behavior of the 'set metric' command in a route-map when applied to redistributed routes into OSPF?
Correct. The default metric for redistributed OSPF routes is 20.
Why this answer
When redistributing into OSPF, the 'set metric' command sets the metric type and value. The default metric type is E2 (external type 2), and the default metric value is 20.
A network engineer runs the following command on Router R1: R1# show route-map route-map FILTER_OSPF, permit, sequence 10 Match clauses: ip address prefix-list OSPF_ROUTES Set clauses: Policy routing matches: 0 packets, 0 bytes route-map FILTER_OSPF, deny, sequence 20 Match clauses: Set clauses: Policy routing matches: 0 packets, 0 bytes Based on this output, which statement is correct?
Sequence 10 permits matching routes; sequence 20 denies everything else.
Why this answer
The route-map FILTER_OSPF has two sequences: sequence 10 permits routes matching prefix-list OSPF_ROUTES, and sequence 20 denies all other routes (since no match clause). The match counters show 0 packets/bytes, indicating no traffic has been matched yet, but this is a route-map used for route filtering, not policy routing. The correct answer is that the route-map will deny all routes not matching the prefix-list.
Which TWO statements about using a route-map with the "set metric" command to influence route selection in EIGRP are true? (Choose TWO.)
Correct. EIGRP metric components can be set using set metric bandwidth delay reliability load mtu.
Why this answer
In EIGRP, the metric is composite (bandwidth, delay, etc.). The set metric command can modify these values. A route-map can be applied to redistribute routes into EIGRP or to filter outbound updates.
The set metric command can set multiple components. However, the route-map must be applied to the redistribution or neighbor statement to affect EIGRP. The set metric command does not affect the administrative distance.
Which TWO configuration changes will prevent a specific route from being redistributed from OSPF into EIGRP using a route-map? (Choose TWO.)
Correct. A deny clause in the route-map will prevent the route from being redistributed.
Why this answer
To block redistribution, you can either match the route with a deny clause in the route-map, or use a prefix-list that denies the route and reference it in a match clause. A distribute-list under EIGRP is not used for redistribution filtering. A route-map with a permit clause and no match will permit all routes.
A match ip address prefix-list with a permit entry will permit the route.
Which BGP attribute is used as the first tie-breaker in the route selection process when comparing routes from different peers?
Correct. Weight is the first attribute checked; it is Cisco proprietary.
Why this answer
The BGP best-path selection algorithm first prefers the path with the highest weight (Cisco proprietary), then highest local preference, then locally originated routes.
A network engineer is troubleshooting a redistribution issue between OSPF and EIGRP. Router R3 is redistributing OSPF routes into EIGRP, but some OSPF external routes are not appearing in the EIGRP topology table. The engineer checks the redistribute command under EIGRP and sees a route-map named RM-OSPF that uses a prefix-list to match specific prefixes. The missing routes are permitted by the prefix-list. What is the most likely cause?
Correct because EIGRP will not accept redistributed routes without an explicit metric.
Why this answer
The route-map may have a 'set metric' command that is misconfigured, or the route-map may be missing the 'set metric' command entirely, causing EIGRP to reject the route because it requires a metric for redistributed routes. Alternatively, the route-map might have a 'match route-type' that excludes external type-2 routes.
A network engineer runs the following command to troubleshoot DMVPN with NHRP filtering: R1# show ip nhrp detail 10.1.1.2/8 via 10.1.1.2, Tunnel0 created 00:10:00, expire 01:50:00 Type: dynamic, Flags: authoritative unique registered NBMA address: 192.168.1.2 (no-socket) (no-socket) What does this output indicate?
The entry shows a dynamic registration with the NBMA address, indicating successful NHRP registration.
Why this answer
The output shows an NHRP cache entry for a remote spoke (10.1.1.2) with NBMA address 192.168.1.2. The entry is dynamic and registered, indicating that the spoke has successfully registered with the hub.
An enterprise is redistributing EIGRP into OSPF on router R1. R1 has the following configuration: router eigrp 100 redistribute ospf 1 metric 10000 100 255 1 1500 route-map RMAP-OSPF. Router R2 (OSPF-only) shows: 'show ip route 10.1.1.0' as an O E2 route with metric 20, but 'show ip ospf database external 10.1.1.0' shows the forwarding address is 0.0.0.0. Router R3 (also OSPF) cannot reach 10.1.1.0. What is the root cause?
If the next-hop is not in OSPF, the forwarding address is set to 0.0.0.0, meaning the packet should be sent to the advertising router (R1). If R1's router ID is not reachable (e.g., R1's OSPF interfaces are not advertised correctly), R3 cannot reach the route.
Why this answer
When redistributing into OSPF, if the redistributed route's next-hop is not reachable via OSPF (e.g., it is an EIGRP-learned route with a next-hop that is not in the OSPF domain), the forwarding address is set to 0.0.0.0. This causes other OSPF routers to try to reach the originating router (R1) as the next-hop. However, if R1's OSPF router ID is not reachable or if there is a filtering issue, the route may be installed but unreachable.
In this scenario, the route-map RMAP-OSPF may be filtering the route or setting incorrect metrics, but the forwarding address issue suggests that the next-hop is not being advertised correctly. The root cause is likely that the redistributed route's next-hop is not in the OSPF domain, so R1 should use a route-map to set the forwarding address to itself (e.g., set forwarding-address 0.0.0.0 is default, but if the next-hop is reachable, it should be set to the router's own interface IP).
Ready to test yourself?
Try a timed practice session using only Route Maps and Route Filtering questions.