Cisco Updated 300-410 Exam Questions and Answers by raul

According to this question, uRPF is running in strict mode because packets are dropped even

when that route exists in the routing table. Maybe packets are dropped because the receiving

interface is different from the interface the local router uses to send packets to that destination.

The ip verify unicast source reachable-via rx command enables Unicast RPF in strict mode.

To enable loose mode, administrators can use the any option (ip verify unicast source

reachable-via any). In loose mode, it doesn’t matter if we use this interface to reach the source

or not.

The allow-default option allows the use of the default

route in the source verification process.

From the output of the “show ip eigrp topology …” command, we notice network 192.168.13.0/24 was learned via two routes:+ From 192.168.23.3 (R3) with FD = 1075200 and AD = 281600+ From 192.168.12.1 (R1) with FD = 2611200 and AD = 281600

From the output of the “show ip route …” command, we learned that the best (and chosen) path is via 192.168.23.3 (R3).

To use both paths (called unequal cost load balancing) with EIGRP, the second path via R1 must satisfy the feasibility condition. The feasibility condition states that, theAdvertised Distance (AD) of a route must be lower than the feasible distance of the current successor route.

In this case, the second path satisfies the feasible condition as its AD (281600) is smaller than the FD (1075200) of the best path. Therefore we can configure loadbalancing with “variance” command.

In other words, EIGRP will install all paths with metric < variance * best_metric into the local routing table, provided that it meets the feasibility condition to preventrouting loop. Therefore we can calculate the variance > metric / best_metric = 2611200 / 1075200 =2.4.

So with a variance greater than 2 (and must be an integer), we can load balance traffic to network 192.168.13.0/24.

https://www.cisco.com/c/en/us/support/docs/wireless/4400-series-wireless-lan-controllers/109597-csr-chained-certificates-wlc-00.html#anc12

By default, the maximum severity sent as a syslog trap is warning. That is why you see syslog traps for login failures. Since a login success is severity 5 (notifications), those syslog messages will not be converted to traps. To fix this, configure:

Note:

The syntax of login block is:

login block-for seconds attempts tries within seconds