Passed Exam Today 300-410

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.

A DHCP server that receives a DHCPDISCOVER message may respond with a DHCPOFFER message on UDP port 68 (BootP client).

…

In the event that the DHCP server is not on the local subnet, the DHCP server will send the DHCPOFFER, as a unicast packet, on UDP port 67, back to the DHCP/BootPRelay Agent from which the DHCPDISCOVER came.

After redistribution, R3 learns about network 10.1.1.0/24 via two paths:

+ Internal BGP (IBGP): advertised from R4 with AD of 200 (and metric of 0)

+ OSPF: advertised from R1 with AD of 110 (O E2) (and metric of 20)

Therefore R3 will choose the path with the lower AD via OSPF

But this is a looped path which is received from R3 -> R2 -> R1 -> R3. So when the advertised route

from R4 is expired, the looped path is also expired soon and R3 will reinstall the main path from R4.

This is the cause of intermittent connectivity.

We can solve this problem by denying the 10.1.1.0/24 prefix from being redistributed into OSPF on

R1. So R3 will not learn this prefix from R1.

Or another solution is to place an OSPF distribute-list inbound on R3 to block the 10.1.1.0/24 prefix

from being advertised back to R3.