Multiple Choice Questions
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 126.96.36.199 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 188.8.131.52.
+ 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 (184.108.40.206 & 220.127.116.11) 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 (18.104.22.168). 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 22.214.171.124/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.