Finally got to do some DMVPN stuff and I have to say, it ain't so bad. It truly reminds me a lot of Frame Relay. I didn't mind FR. I kinda miss it. But then I am a little off when it comes to technology. :) Well, enough rambling. On to my notes.
To make IPSec tunnels be robust off two interfaces, use crypto map <name> local-address <inteface>. This will allow a crypto connection to be made to one location on the device and not drop if an interface dies. Well, not exactly true. Traffic will be routed out the other interface so a couple of packets may disappear but it is automatic and not a manual process. You just have to be sure to use the address on the other side of the tunnel on the peer.
I never really had to create VPNS before. Trying to do this isn't really that bad. From what I understand, you create the ISAKMP policy, which includes the initial encryption, DH group, hash type, and authentication type. Outside of that, you configure the authentication type parameters, with pre-share being super easy. Next, define the IPSec transform-set with encryption and hash types along with a name. Also don't forget to set the mode to tunnel or transport. Configure ACLs to define what traffic is being encrypted with source and destination. Create a crypto map where you set the peer, the transform-set to use, and the traffic ACL. Finally apply that to an external interface and done. This will allow encrypted and unencrypted traffic out of the interface.
When doing GRE over IPSec, have the ACL for the traffic match protocol GRE and apply the crypto map to the external interface and not the tunnel. GRE over IPSec allows the use of dynamic routing protocols. GRE over IPSec also means fewer SAs. More entries in the ACL for traffic to be encrypted means that there are more SAs needed. One for each entry. With GRE over IPSec, there is only one entry for each location and that means one SA per location. Also by default, the DF bit is not copied from the original IP header to the GRE payload to the ESP header. This may cause you to want to lower the MTU on the tunnel. You can also modify the MSS window in TCP with ip tcp adjust-mss <NEW_MSS> to help reduce packet size and decrease fragmentation.
With a crypto map you have to define peers but with a crypto profile, the peer is pulled from the tunnel. Really only seems that you are putting in the crypto commands to secure the information riding in the tunnel. All other transport information is handled by the tunnel. You also don't have to worry about an ACL to specify what traffic is encrypted. If it goes over the tunnel, it gets encrypted.
I was wondering what the difference between a Virtual Tunnel Interface (VTI) and GRE IPSec tunnel was when I first starting seeing the terms in the workbook. The difference is that the VTI is directly encapsulated in ESP and doesn't need another header to move it from place to place. It also ahs a smaller overhead. With GRE and IPSec, to help increase the payload and decrease the overhead, you have to set the IPSec mode to transport. For VTI, you can leave it as tunnel. Another big difference is that VTIs only carry IP. GRE IPSec tunnels can carry just about anything from IS-IS to your momma. Also interesting that the tunnel interface for a VTI accounts for the ESP header in its MTU auto-magically. Do a show interface tunnel# to see it. This also means you don't have to enter the MTU for the tunnel since it is smarter than the average tunnel. Wonder if a VTI also looks for picnic baskets. There is a thought. Still, setting the ip tcp adjust-mss is a good idea.
DMVPNs aren't really all that scary. At first, I was thinking that with the dynamic nature of them and the encryption, that it was super tough. They really aren't. Set the spokes to point to the NHS (hub) and agree on NHRP authentication, GRE tunnel key number, and whether or not multicast will be used. After that check the hub for registrations and voila. Use show dmvpn and show ip nhrp for verification.
By default multicast is not used within DMVPN tunnels. You have to turn it on with the ip nhrp map multicast command. On the spokes, you put in the "external" IP of the hub. At the hub, you add the word dynamic. Think of doing this like adding the word broadcast to that wonderful protocol called Frame Relay. Also multicast packets are not replicated to other spokes. No spoke to spoke there people.
So what I am gathering is that DMVPN has phases. Phase 1 is spoke to hub only and not good for a lot of traffic going spoke to spoke. Phases 2 and 3 are where traffic can go from spoke to spoke. Phase 2 is where traffic goes from spoke to spoke via asking the hub where each spoke is located. Route updates are sent to the spokes with the next-hop unchanged. Phase 3 is where the spokes respond to NHRP resolution requests.
When creating a DMVPN with IPSec and you want to make it so that the spokes only securely talk with the hub, set the crypto isakmp key to the external tunnel interface. For the hub, you can set it to 0.0.0.0. Gonna have to see if you can enter multiple entries for each spoke. Only problem with that is the hub has to be modified for each spoke added. PKI is the real way to go.
DMVPN uses crypto profiles and crypto maps to add security. If it used maps, it would require the set peer option. Using set peer removes the dynamic portion of DMVPN. Also setting the mode to Transport over Tunnel saves overhead by not encapsulating a header with another header. To make sure that the DMVPN is working, check the hub has ISAKMP and IPSec SAs for each spoke. Only after IPSec connections are made are the NHRP connections made and can be checked.
To do DMVPN Phase 1 with EIGRP, set up the hub like before but the spokes are now going to get tunnel destination and take out tunnel mode gre multipoint. This makes sure that the spokes don't talk with each other and that all traffic goes through the hub. The hub is king in Phase 1.
When doing DMVPN with OSPF, there are three choices. One is to make the hub point-to-multipoint and change the hello-interval to match the spokes. Two is the change the hub to point-to-multipoint and change the spokes' hello-interval to match the hub. Three is to make the hub and spokes all point-to-multipoint OSPF type. The third option cannot be used in Phase 1. The hub always has to be point-to-multipoint. By default tunnel interfaces are point-to-point. Again, sounds more and more like Frame Relay. Frame Relay, my old friend, you come around, again and again.
To do DMVPN Phase 2, two key criteria have to be met. One is that the hub doesn't do any summarization. When done, the next hop is changed to the hub so the spoke sends it there. That brings in key point 2, which is that the next hop cannot be changed. Again, if the next-hop is changed then, all traffic goes to the new next-hop. Other interesting fact with DMVPN Phase 2 is that adjacencies are only formed from the spokes to the hub. No spoke to spoke adjacencies are there. Again, sounds more and more like Frame Relay.
No comments:
Post a Comment