First we need some basic knowledge about GRE tunnel:
GRE tunnels are designed to be completely stateless. This means that each tunnel endpoint does not keep any information about the state or availability of the remote tunnel endpoint. A consequence of this is that, by default, the local tunnel endpoint router does not have the ability to bring the line protocol of the GRE Tunnel interface down if the remote end of the tunnel is unreachable. The ability to mark an interface as down when the remote end of the link is not available is used in order to remove any routes (specifically static routes) in the routing table that use that interface as the outbound interface. Specifically, if the line protocol for an interface is changed to down, then any static routes that point out that interface are removed from the routing table. This allows for the installation of an alternate (floating) static route or for Policy Based Routing (PBR) in order to select an alternate next-hop or interface.
An example of configuring a GRE tunnel:
ip address 18.104.22.168 255.255.255.0
tunnel source Loopback1
tunnel destination 10.0.0.1
In order to make this interface up/up, a valid tunnel source and tunnel destination must be configured.
+ A valid tunnel source means any interface that is itself in the up/up state and has an IP address configured on it. For example, if the tunnel source was changed to Loopback0 (which has not been assigned an IP address), the tunnel interface would go down even though Loopback0 is in the up/up state.
+ A valid tunnel destination is one which is routable. However, it does not have to be reachable, which can be seen from this ping test:
|Router# show ip route 10.0.0.1
% Network not in table
Router# show ip route | inc 0.0.0.0
Gateway of last resort is 172.16.52.100 to network 0.0.0.0
S* 0.0.0.0/0 [1/0] via 172.16.52.100
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds:
Success rate is 0 percent (0/5)
In this case the tunnel1 is still up/up because it has a default route. From this we can deduce answer C is not correct but answer D is correct.
GRE tunnel keepalives timers on each side are independent and do not have to match (answer E is not correct). The problem with the configuration of keepalives only on one side of the tunnel is that only the router that has keepalives configured marks its tunnel interface as down if the keepalive timer expires. The GRE tunnel interface on the other side, where keepalives are not configured, remains up even if the other side of the tunnel is down. The tunnel can become a black-hole for packets directed into the tunnel from the side that did not have keepalives configured.
Answer A is not correct because normal GRE tunnel is always required to be in up/up state.
OSPF routers go through the seven states while building neighbor relationship with other routers.
+ Down state: no Hellos have been received on the interface. All OSPF routers begin in this state. It begins by sending a hello packet through each of its interfaces participating in OSPF, even though it does not know the identity of the DR or of any other routers. The hello packet is sent out using the multicast address 22.214.171.124.
+ Attempt/Init state: Hello packet received
+ 2-way state: the router received the Hello message and replied with a Hello message of his own. Receiving a Database Descriptor (DBD) packet from a neighbor in the init state will also a cause a transition to 2-way state.
+ Exstart state: beginning of the LSDB exchange between both routers. Routers will start to exchanging link state information. This state specifies that DR and BDR have been elected and master-slave relation is determined.
+ Exchange state: DBD packets are exchanged. DBDs contain LSAs headers. Routers will use this information to see what LSAs need to be exchanged.
+ Loading state: one neighbor sends LSRs (Link State Requests) for every network it doesn’t know about. The other neighbor replies with the LSUs (Link State Updates) which contain information about requested networks. After all the requested information have been received, other neighbor goes through the same process.
+ Full state: both routers have synchronized the link state database and are fully adjacent with each other. OSPF routing can now begin.
In the above output we see that R4 received the first DBD from 192.168.1.3 (line 4) which cause it to move from INIT to 2-way state (line 5). Then it received the second DBD from 192.168.1.3. That means it is in Exstart state and two OSPF routers are exchanging DBD packets. In fact the DBD packets are also exchanged in Exchange state but they have to pass the Exstart state first so Exstart state is the best answer in this case.
Two GRE tunnels (126.96.36.199 & 188.8.131.52) are considered directly connected so no routing protocol needs to be used so that they can see each other. But we have to configure a routing protocol (static routing in this case) so that they R1 can reach 10.0.3.0/24 network via Tunnel1.
Note: The “U” letter (short for Unreachable) we see above when pinging typically means there is no available route to the destination.
From the “show ip route ospf” output on R2 we notice that it does not know how to reach Lo0 of R5 (184.108.40.206). Therefore we need to advertise this prefix on R5 to R2 via:
+ Redistribute connected routes (which includes Loopback’s IP addresses) to OSPF on R5
+ Advertise Lo0 interface to OSPF on R5 (via the “network” command under OSPF process on R5)
From the outputs above we can imagine the topology of them
In this topology:
+ There are only two routers and a loopback interface -> A is not correct.
+ R1 learn route to 220.127.116.11/32 as O IA as they are in different OSPF area -> B is not correct, E is correct.
+ R2 is an OSPF ABR -> C is not correct
+ E0/0 of R1 is elected DR so it was configured as OSPF type broadcast, not point-to-point (which does not elect DR/BDR) -> D is not correct
+ R1 is DR and R2 is BDR as seen in “State” column of above outputs -> F is correct.
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 18.104.22.168 (R2) and 22.214.171.124 (R3). For the second hop (TTL is set to 2) they are 126.96.36.199 (R5) and 188.8.131.52 (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.