A project has been started to configure VPN between head office and remote branches. This was done simply by configuring site-to-site VPN (See my Blog) between remote branch (Peshawar) and Faisalabad (next hope) as we (Peshawar hope) are using it as our next hope to reach head office. After the basic configuration of site-to-site VPN, we done with it and the communication were successful between two remote offices. The problem arises when Faisalabad configured VPN with another remote office (Abbotabad) now when they start communication with them by giving their peer address under crypto map as shown below, as the link established between the two sites, ping (communication) breaks between Peshawar and Faisalabad when again peer address of Peshawar was given here so communication breaks with the other remote offices.
Hub-Router (config) # crypto map VPN_MAP 10 ipsec-isakmp
Hub-Router (config-crypto-map) # set peer 130.13.x.x
Problem:
The main problem was that we had multiple sites which are using Faisalabad as their next hop, so it becomes HUB, now we required some method to configure VPN for HUB and SPOKE topology. After searching and goggling we came with the solution that DMVPN is the right choice for it.
Solution:
A Dynamic Multipoint Virtual Private Network (DMVPN) is an up gradation of the virtual private network (VPN) configuration process of Cisco IOS-based routers. What DMVPN does is that it prevents the need of configuration of pre-defined static peers in crypto-map and ISAKMP peer statement. An IPsec tunnel between two Cisco routers may be created on an as needed basis. Tunnels may be created between a spoke router and a hub router or between spokes.
DMVPN Spoke is configured with one or more hub IP addresses. DMVPN hub IP addresses are typically static. DMVPN spoke IP addresses may be static, or dynamic. The spoke router is configured with the hub's IP address and allowing the spoke to connect to hub when it is online. The hub router does not need to be configured with the IP addresses of the spoke routers. This allows many-spoke VPN routers to be deployed without the need to configure additional peers on the hub.
For ROUTING we use dynamic routing protocol between the spokes and the hub, as well as other spokes. We can have the choice of using EIGRP or OSPF routing protocols between them as it is used commonly now a days, one of the reason is scalability. We used EIGRP for our internal routing.
Configurations:
I suppose that you are familiar with GRE tunneling configuration and sit-to-site VPN configuration, if not then look at here my blogs for step wise configuration of GRE and VPN as I will be talking about the remaining configuration that are required for DMVPN.
HUB Configuration:
HUB-Router (config) # interface tunnel 0
HUB-Router (config) # ip nhrp authentication cisco120
HUB-Router (config) # ip nhrp map multicast dynamic
HUB-Router (config) # ip nhrp network-id 10
HUB-Router (config) # no ip split-horizon eigrp 100
There is a reason why we use “no ip split-horizon” on hub, see here
HUB-Router (config) # tunnel source fastethernet 0/0
HUB-Router (config) # tunnel mode gre multipoint
HUB-Router (config) # tunnel key 0
Tunnel key is used on Point-to-Point or Multipoint
HUB-Router (config) # tunnel protection ipsec profile Cisco
Spoke Configuration:
SPOKE -Router (config) # interface tunnel 0
SPOKE -Router (config) # ip nhrp authentication cisco120
SPOKE -Router (config) # ip nhrp map multicast dynamic
Note: We can choose either static ip address or multicast (broadcasting/multicasting), if we choose dynamic it means that learn the destination address that are from client registration on hub
SPOKE -Router (config) # ip nhrp map 172.16.2.1 221.120.x.x
The first is the destination tunnel address and second is the public address of destination.
SPOKE-Router (config) # ip nhrp map multicast 221.120.x.x
SPOKE -Router (config) # ip nhrp network-id 10
SPOKE -Router (config) # ip nhrp nhs 172.16.2.1
Where “nhs” is the next hope server address
SPOKE -Router (config) # tunnel source fastethernet 0/0
SPOKE -Router (config) # tunnel mode gre multipoint
SPOKE -Router (config) # tunnel protection ipsec profile Cisco
NHRP is next-hope resolution protocol; not a routing protocol but it make use of routing information. The most prominent feature of NHRP is that it avoids extra router hopes in an NBMA.
Commands:
You can further use the following command to verify and troubleshoot the configurations.
1. show crypto socket ("Display the crypto sockect between NHRP and IPSec)
2. show ip nhrp ("Display the next hope resolution protocol cache entries etc)
3. show ip route
4. show ip eigrp neighbor
5. show crypto ipsec sa ("Display the active channel)
6. show crypto engine connection active ("Display the total encrypted / decrypted SA)
7. show crypto isakmp sa ("Display isalmp security association state (SA)")
You can also do DEBUG for further understanding and logs
1. debug crypto ipsec
2. debig crypto isakmp
3. debug crypto engine
4. debug crypto socket
I hope this will be informative for you !
Cheers :)
7 comments:
nice finding !
Dear Author sohailpk.blogspot.com !
Excuse, that I can not participate now in discussion - it is very occupied. But I will return - I will necessarily write that I think on this question.
I want to quote your post in my blog. It can?
And you et an account on Twitter?
@ Anonymous
Ofcourse you can link my post on your blog by giving my blog link as the reference.
This is the configuration between CE and PE ...what about the Ps configuration in the Core. Are you going to use PTCL BB network or someones else????
Shahid Nawaz
SE - NMS PTCL
@Shahid Namaw.....!
Thnx for Reading me, yes ofcourse we are using PTCL (as we using DXX) this as a Main link for our communication and Telecome link as a Backup.
Cheers :)
why not:)
Post a Comment