Refer to the exhibit. After applying IPsec, the engineer observed that the DMVPN tunnel went down, and both spoke-to-spoke and hub were not establishing.
Which two actions resolve the issue? (Choose two.)
Refer to the exhibit. After applying IPsec, the engineer observed that the DMVPN tunnel went down, and both spoke-to-spoke and hub were not establishing.
Which two actions resolve the issue? (Choose two.)
To resolve the issue with the DMVPN tunnel, two actions should be taken. First, the configuration on R3 should be adjusted by changing the mode from mode tunnel to mode transport. IPsec transport mode is typically used with DMVPN to provide encryption while maintaining the characteristics of the GRE tunnel needed for DMVPN operation. Second, configuring the crypto isakmp key with a catch-all address of 0.0.0.0 will ensure that ISAKMP can establish SAs with any peer, thus resolving possible addressing mismatches. In summary, these adjustments ensure that the configurations are compatible and functional for secure DMVPN tunnel communication.
I LITERALLY just labbed this. Please forgive the long explanation but I want to share for future testers. I was torn between changing the tunnel mode or removing one address and adding the other. B and D are definitely correct. You can't just put in the command with 0.0.0.0. If you do, you will end up with two crypto key commands and both addresses so the one to the tunnel address MUST be removed. Again, NO DOUBT...B AND D!!!!!
Having many crypto keys is not an issue. you can leave the 10.1.1.1. If you add on top of it either 0.0.0.0 or 192.1.1.1 the tunnel protocol will go up.
Does it mean that C and D are correct?
Worked at Cisco TAC VPN team for over a year. A and D are correct.
Seems like it can't be removed. R2#show crypto isakmp key Keyring Hostname/Address Preshared Key default 8.8.8.8 cisco Tunnel123 is up, line protocol is down R2(config)#crypto isakmp key cisco address 0.0.0.0 Tunnel123 is up, line protocol is up R2#show crypto isakmp key Keyring Hostname/Address Preshared Key default 8.8.8.8 cisco 0.0.0.0 [0.0.0.0] cisco
B and D correct
I LAB it and "D" is definilly right. I didn't need to remove the old command. You can have many isakmp keys and it worked with the ends in different modes (I got surprised with that). So, I am not sure about the another right answer.
Corerct Band D: You can't just put in the command with 0.0.0.0. If you do, you will end up with two crypto key commands and both addresses so the one to the tunnel address MUST be removed.
100 % B and D I check in lab
Answer is A and D. it will run throuhg the key addresses in order. "You can have multiple isakmp policies on your router. The router will run through them in order until it finds a match. So you just need to add a new isakmp policy with a different sequence number eg." https://community.cisco.com/t5/other-security-subjects/can-you-have-multiple-crypto-isakmp-policies-on-a-router/td-p/840716
BD makes more sense
I tested this scenario in my DMVPN lab just now. For this lab I configured ipsec transform-set with "mode tunnel" on hub and also in spokes. DMVPN was up, EIGRP was working etc. But than I changed the transform-set in spoke2 to "mode transport" and shut/no shut the tunnel interface. Spoke2 is not able to ping hub or the other spoke after that. So I'm 100% sure that one of the answers is "A" and looks like having multiple keys is not an issue so I'd go with "D" as well. But before taking my comment as absolutely correct, lab it yourself.
I've been playing around with this lab for an hour. The correct answer with no doubt is AD
AD I would say
Options A and D are correct
DMVPN uses GRE, NHRP can be only be incapsuleted in a GRE packet. If you change the mode of the tunnel in ipsec then you are going to have a VTI instead of a GRE tunnel interface, the result is that you cannot longer use DMVPN. So first we need to take off the tunnel mode ipsec and use transport mode. Because we have more than one peer and we need to add the command to have all the peer using the same preshared key otherwise you will not be able to build up the phase 1 tunnel
Answer is A and D
Answer is A, B I will prove it R1 Config: crypto isakmp policy 10 hash md5 authentication pre-share group 2 crypto isakmp key cisco address 0.0.0.0 ! ! crypto ipsec transform-set TSET esp-des mode tunnel ! crypto ipsec profile TST set transform-set TSET ! ! ! ! ! ! ! interface Loopback0 ip address 1.1.1.1 255.255.255.0 ! interface Tunnel0 ip address 10.1.1.1 255.255.255.0 no ip redirects ip nhrp map multicast dynamic ip nhrp network-id 1 ip nhrp redirect tunnel source Ethernet0/0 tunnel mode gre multipoint tunnel protection ipsec profile TST
R2 Config:crypto isakmp policy 10 hash md5 authentication pre-share group 2 crypto isakmp key cisco address 10.1.1.1 ! ! crypto ipsec transform-set TSET esp-des mode tunnel ! crypto ipsec profile TST set transform-set TSET ! ! ! ! ! ! ! interface Loopback0 ip address 2.2.2.2 255.255.255.0 ! interface Tunnel0 ip address 10.1.1.2 255.255.255.0 no ip redirects ip nhrp map 10.1.1.1 192.1.1.1 ip nhrp map multicast 192.1.1.1 ip nhrp network-id 1 ip nhrp nhs 10.1.1.1 ip nhrp shortcut tunnel source Ethernet0/1 tunnel mode gre multipoint tunnel protection ipsec profile TST R2(config-if)# R2(config-if)#do ping 10.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds:
R2 modify address: crypto isakmp key cisco address 0.0.0.0 R2(config)#do ping 10.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds: ..... Ping times out: why? We still have the IPSEC SA mapped to 10.1.1.1 R2#ping 10.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 5/7/10 ms R2# R2# Hence you do not need to remove the R2: sh run crypto isakmp key cisco address 10.1.1.1 crypto isakmp key cisco address 0.0.0.0 ! R2#ping 10.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 5/9/18 ms R2#
Now change R2 mode to transport: R2: mode transport But R2 can still ping R1!!!! R2(config-if)#do ping 10.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 9/9/10 ms R2(config-if)# BUT R3 CANT Ping R2!!! R3(config-if)#do ping 10.1.1.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.1.1.2, timeout is 2 seconds: *Jun 17 12:37:14.026: %NHRP-3-PAKERROR: Received Error Indication from 10.1.1.1, code: protocol generic error(7), (trigge r src: 10.1.1.3 (nbma: 192.1.1.3) dst: 10.1.1.2), offset: 0, data: 00 01 08 00 00 00 00 00 00 FF 00 48 EC 19 00 34 ... *Jun 17 12:37:19.584: %NHRP-3-PAKERROR: Received Error Indication from 10.1.1.1, code: protocol generic error(7), (trigge
Change R2 to tunnel again R3(config-if)#do ping 10.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 5/8/10 ms R3(config-if)#
The answer is A B
B and D are correct. You need simulate in the lab.
im going with B & D