Multiple Choice Questions
From the last line “K-value mismatch” we learn that the K values of two EIGRP routers are mismatched and EIGRP neighborship between two routers will not be formed.
Note: EIGRP K values are the metrics that EIGRP uses to calculate routes. Mismatched K values can prevent neighbor relationships from being established. By default K1 & K3 are set to 1 while K2, K4 and K5 are set to 0. We can change the EIGRP K values via the “metric weights tos k1 k2 k3 k4 k5” command under EIGRP router mode (tos: type of service must always be zero). For example:
Router(config-router)#metric weights 0 20 10 50 40 40
The following list of parameters must match between EIGRP neighbors in order to successfully establish neighbor relationships:
+ Autonomous System number.
+ K-Values (look at the previous lesson).
+ If authentication is used both: the key number, the password, and the date/time the password is valid must match.
+ The neighbors must be on common subnet (all IGPs follow this rule).
Therefore we don’t need to check EIGRP hello and hold timers because they don’t have to match. We should check if appropriate networks are included in the “network …” command of EIGRP on both routers.
For example in the topology below, R1 learned the Loopback0 interface of R6 via two equal paths R2-R4 and R3-R5:
The routing table of R1 is shown below:
And the traceroute command from R1 to R6’s loopback0:
Traceroute works by sending packets with gradually increasing Time-To-Live (TTL) value, starting with TTL value of 1. The first router receives the packet, decrements the TTL value and drops the packet because it then has TTL value zero. The router sends an ICMP Time Exceeded message back to the source. The next set of packets are given a TTL value of 2, so the first router forwards the packets, but the second router drops them and replies with ICMP Time Exceeded. Proceeding in this way, traceroute uses the returned ICMP Time Exceeded messages to build a list of routers that packets traverse, until the destination is reached and returns an ICMP Echo Reply message.
The “1”, “2” and “3” in the traceroute output stands for the hop number. Therefore with the first hop (TTL is set to 1) we can see the packets are sent through 126.96.36.199 (R2) and 188.8.131.52 (R3). For the second hop (TTL is set to 2) they are 184.108.40.206 (R5) and 220.127.116.11 (R4)…
In conclusion we can use the traceroute command to check if the load-balancing is actually occurring.
IPSec transport mode (encrypting an IP GRE tunnel) is a commonly deployed option because it provides all the advantages of using IP GRE, such as IP Multicast protocol support (and, thus, also the support of routing protocols that utilize IP Multicast) and multiprotocol support. Furthermore, this option saves 20 bytes per packet over IPSec tunnel mode (encrypting an IP GRE tunnel) because an additional IP header is not required.
IPSec alone does not support multicast which many dynamic routing protocols use. GRE tunnels helps IPSec overcome this disadvantage by handling the transportation of multiprotocol and IP multicast traffic (from site-to-site VPNs, for example).
With the p2p GRE over IPsec solution, all traffic between sites is encapsulated in a p2p GRE packet before the encryption process, simplifying the access control list used in the crypto map statements. The crypto map statements need only one line permitting GRE (IP Protocol 47).
With the p2p GRE over IPsec solution, all traffic between sites is encapsulated in a p2p GRE packet before the encryption process, simplifying the access control list used in the crypto map statements.