GRE Tunnel
Question 1
Explanation
GRE packets are encapsulated within IP and use IP protocol type 47
Question 2
Explanation
A GRE interface definition includes:
+ An IPv4 address on the tunnel
+ A tunnel source
+ A tunnel destination
Below is an example of how to configure a basic GRE tunnel:
interface Tunnel 0 ip address 10.10.10.1 255.255.255.0 tunnel source fa0/0 tunnel destination 172.16.0.2 |
In this case the “IPv4 address on the tunnel” is 10.10.10.1/24 and “sourced the tunnel from an Ethernet interface” is the command “tunnel source fa0/0”. Therefore it only needs a tunnel destination, which is 172.16.0.2.
Note: A multiple GRE (mGRE) interface does not require a tunnel destination address.
Question 3
Explanation
The tunnel interface is configured in default mode means the tunnel has been configured as a point-to-point (P2P) GRE tunnel. Normally, a P2P GRE Tunnel interface comes up (up/up state) as soon as it is configured with a valid tunnel source address or interface which is up and a tunnel destination IP address which is routable.
Under normal circumstances, there are only three reasons for a GRE tunnel to be in the up/down state:
+ There is no route, which includes the default route, to the tunnel destination address.
+ The interface that anchors the tunnel source is down.
+ The route to the tunnel destination address is through the tunnel itself, which results in recursion.
Therefore if a route towards the tunnel destination has not been configured then the tunnel is stuck in up/down state.
Question 4
Explanation
In this question only answer A is a reasonable answer. When the state of the tunnel interface is continuously moving between up and down we must make sure the route towards the tunnel destination address is good. If it is not good then that route may be removed from the routing table -> the tunnel interface comes down.
Question 5
Explanation
The IP protocol was designed for use on a wide variety of transmission links. Although the maximum length of an IP datagram is 65535, most transmission links enforce a smaller maximum packet length limit, called an MTU. The value of the MTU depends on the type of the transmission link. The design of IP accommodates MTU differences since it allows routers to fragment IP datagrams as necessary. The receiving station is responsible for the reassembly of the fragments back into the original full size IP datagram.
Fragmentation and Path Maximum Transmission Unit Discovery (PMTUD) is a standardized technique to determine the maximum transmission unit (MTU) size on the network path between two hosts, usually with the goal of avoiding IP fragmentation. PMTUD was originally intended for routers in IPv4. However, all modern operating systems use it on endpoints.
The TCP Maximum Segment Size (TCP MSS) defines the maximum amount of data that a host is willing to accept in a single TCP/IP datagram. This TCP/IP datagram might be fragmented at the IP layer. The MSS value is sent as a TCP header option only in TCP SYN segments. Each side of a TCP connection reports its MSS value to the other side. Contrary to popular belief, the MSS value is not negotiated between hosts. The sending host is required to limit the size of data in a single TCP segment to a value less than or equal to the MSS reported by the receiving host.
TCP MSS takes care of fragmentation at the two endpoints of a TCP connection, but it does not handle the case where there is a smaller MTU link in the middle between these two endpoints. PMTUD was developed in order to avoid fragmentation in the path between the endpoints. It is used to dynamically determine the lowest MTU along the path from a packet’s source to its destination.
Reference: http://www.cisco.com/c/en/us/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag.html (there is some examples of how TCP MSS avoids IP Fragmentation in this link but it is too long so if you want to read please visit this link)
Note: IP fragmentation involves breaking a datagram into a number of pieces that can be reassembled later.
Question 6
Explanation
A valid tunnel destination is one which is routable (which means the destination is present or there is a default route in the routing table). However, it does not have to be reachable -> Answer B is correct.
For a tunnel to be up/up, the source interface must be up/up, it must have an IP address, and the destination must be reachable according to your own routing table.
Question 7
Question 8
Question 9
Explanation
GRE tunnel provides a way to encapsulate any network layer protocol over any other network layer protocol. GRE allows routers to act as if they have a virtual point-to-point connection to each other. GRE tunneling is accomplished by creating routable tunnel endpoints that operate on top of existing physical and/or other logical endpoints. Especially, IPsec does not support multicast traffic so GRE tunnel is a good solution instead (or we can combine both).
Question 10
Question 11
Explanation
When running GRE tunnel over IPSec, a packet is first encapsulated in a GRE packet and then GRE is encrypted by IPSec -> C is correct.
Question 12
Explanation
Four steps to configure GRE tunnel over IPsec are:
1. Create a physical or loopback interface to use as the tunnel endpoint. Using a loopback rather than a physical interface adds stability to the configuration.
2. Create the GRE tunnel interfaces.
3. Add the tunnel subnet to the routing process so that it exchanges routing updates across that interface.
4. Add GRE traffic to the crypto access list, so that IPsec encrypts the GRE tunnel traffic.
An example of configuring GRE Tunnel is shown below:
interface Tunnel0
ip address 192.168.16.2 255.255.255.0
tunnel source FastEthernet1/0
tunnel destination 14.38.88.10
tunnel mode gre ip
Note: The last command is enabled by default so we can ignore it in the configuration)
(Reference: CCNP Routing and Switching Quick Reference)
Question 13
Explanation
The address of the crypto isakmp key (line “crypto isakmp key ******* address 172.16.1.2”) should be 192.168.2.1, not 172.16.1.2 -> A is correct.
Question 14
Explanation
The access-list must also support GRE traffic with the “access-list 102 permit gre host 192.168.1.1 host 192.168.2.1” command -> B is correct.
Below is the correct configuration for GRE over IPsec on router B1 along with descriptions.
The interface tunnel configuration is rather simple so I don’t post it here.
Question 15
Explanation
The “tunnel destination” in interface tunnel should be 192.168.2.1, not 172.16.1.2 -> D is correct.
I purchased 300-101, the information inside is true and effective. Before the exam, the question bank will be updated to take the initiative to communicate with me. The attitude is very good. Any questions will be answered in time, and the information is comprehensive. There is no subject. I passed the exam and shared it with you. I hope it will help you too.
h tt p://t .cn/RDug3fQ
want to take ccnp route exam please share me the dumps please
Some new questions…
Which commands are used to configure IPSEC over GRE tunnel? (choose two)
A. IP MTU
B. Tunnel Key
C. IP TCP Adjust MSS
D. MPLS MTU
E. IP unnumbered
So far GRE over IPSEC was referenced in the questions, here it’s the other way round. I guess since with IPSEC over GRE the payload will be encrypted (unlike the payload+GRE overhead), the GRE interface itself doesn’t need an IP, thus IP unnumbered could be an answer.
IP TCP Adjust MSS and Tunnel key could also be an answer.
Thus, B,(C), E
Anyone else has a comment? :)
RRRRR:
w w w
The update here is fast, the information is complete, the pass rate is very high, and you can go and see if you need it.
.cciedumps.xyz/ccie_rs.php?utm_source=bbs&utm_medium=bbs
Which commands are used to configure IPSEC over GRE tunnel? (choose two)
A. IP MTU
B. Tunnel Key
C. IP TCP Adjust MSS
D. MPLS MTU
E. IP unnumbered
I think right answers A and C
Hmmm, B maybe right to.
Strange question, not so clear.
Regarding Q5 and his variances (saiko show one):
For Q5 answers are TCP MSS and PMTU (like digitaltut wrote). For saiko question, the answers are IP MTP and TCP MSS.
IP MTU is static definition for MTU and PMTUD ( path-mtu-discovery) is dynamically one, which is much better. So, is desirable tu use R1(config-if)#tunnel path-mtu-discover min-mtu 1200 (for example) in interface tunnel mode command.
Q13,Q14,Q15 are beautiful questions, at CCIE level and unfortunately, difitaltut answer incorrect to Q13 and Q14, and present wrong explanantion to Q15. Wrong explanation are indeed to all three. I suggest to digitaltut to try to configure crypto map on tunnel interface to see what is happening. That will be the answer
“R1(config-if)#crypto map test
% NOTE: crypto map is configured on tunnel interface.
Currently only GDOI crypto map is supported on tunnel interface.”
So, please digitaltut correct answers for Q13 and Q14 and write somewhere that ” crypto map is applicable only to physical interface”
Here is a link where is described what i observe in GNS3
https://community.cisco.com/t5/vpn-and-anyconnect/problem-with-gre-over-ipsec-with-ios-version-15-1-2-t4/td-p/1751266
“A crypto map cannot be applied to a tunnel interface. If you try to apply the tunnel interface to a crypto map, an error message is displayed as follows: crypto map is configured on tunnel interface. Currently only Group Domain of Interpretation (GDOI) crypto map is supported on tunnel interface.”
Q5 Answer A-D.
TCP MSS as described earlier takes care of fragmentation at the two endpoints of a TCP connection, but it does not handle the case where there is a smaller MTU link in the middle between these two endpoints. PMTUD was developed in order to avoid fragmentation in the path between the endpoints. It is used to dynamically determine the lowest MTU along the path from a packet’s source to its destination.
https://www.cisco.com/c/en/us/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag.html
who needs DUMP can reach me at: muhamadawan1988@ gmail . com
no
The charming message