Building DMVPN with mGRE, NHRP and IPSec VPN
June 3, 2008 14 Comments
I – OVERVIEW
This lab will treat the design and deployment of dynamic multipoint VPN architectures by moving step by step into the configuration and explaining how mGRE (multipoint Generic Router Encapsulation), NHRP (Next-Hop Resolution Protocol) and IPsec VPN are mixed to build a dynamic secure topology over the Internet for large enterprises with hundreds of sites.
Figure1: physical Topology
A hypothetical enterprise (figure1) with a central office (HUB) and several branch office sites (spokes) connecting over the Internet is facing a rapid business grow and more and more direct connections between branch offices are needed.
Spokes are spread over different places where it is not always possible to afford a static public addresses therefore company needs more scalable method than a simple Hub and spoke with point-to-point tunneling or a full mesh topology where the administration tasks of the IPSec traffic become extremely burdensome.
II – DEPLOYMENT
Figure2: Address scheme
The DMVPN model provides a scalable configuration for a dynamic-mesh VPN with the only static relationships configured are those between spokes and the HUB.
DMVPN concepts include several components like mGRE, NHRP and IPSec Proxy instantiation that will be explained during this lab.
II-1 Address scheme:
Each site has its own private address space 10.0.1.0/24, 10.0.2.0/24, 10.0.3.0/24 and 10.0.4.0/24 for central site, site1, site2 and site3 respectively.
Each spoke router obtains its public IP address dynamically from the ISP; only the HUB has a static permanent public IP.
Table1: address scheme
Network |
Addresses |
OSPF Area 10 – central site | 10.0.1.0/24 |
OSPF Area 11 – site 1 | 10.0.2.0/24 |
OSPF Area 12 – site 2 | 10.0.3.0/24 |
OSPF Area 13 – site 3 | 10.0.4.0/24 |
Multipoint GRE network | 172.16.0.128/26 |
Area 0 link subnet between HUB and Internet | 192.168.0.16/30 |
Area 0 link between SPOKEA and Internet | 192.168.0.12/30 |
Area 0 link between SPOKEB and Internet | 192.168.0.8/30 |
Area 0 link between SPOKEC and Internet | 192.168.0.4/30 |
II-2 Multipoint Generic Router Encapsulation – mGRE:
Table2: Tunnel configuration guideline
Router HUB | ||
Interface tunnel 0 |
Ip /mask |
172.16.0.129/28 |
Source ip |
S1/0 |
|
Dest ip |
– |
|
Tunnel type |
GRE multipoint |
|
Router SPOKEA | ||
Interface tunnel 0 |
Ip /mask |
172.16.0.130/28 |
Source ip |
S1/0 |
|
Dest ip |
– |
|
Tunnel type |
GRE multipoint |
|
Router SPOKEB | ||
Interface tunnel 0 |
Ip /mask |
172.16.0.131/28 |
Source ip |
S1/0 |
|
Dest ip |
– |
|
Tunnel type |
GRE multipoint |
|
Router SPOKEC | ||
Interface tunnel 0 |
Ip /mask |
172.16.0.132/28 |
Source ip |
S1/0 |
|
Dest ip |
– |
|
Tunnel type |
GRE multipoint |
A Hub n Spoke point-to-point GRE would be a heavy burden for the administration of the topology because all spokes IP addresses must be known in advance.
Moreover such traditional solutions consume lot of CPU and memory resources because each tunnel will create its own IDB (Interface Descriptor Block).
The alternative for point-to-point GRE will be multipoint GRE where a single interface will terminate all spokes GRE tunnels and will consume a single IDB and conserves interface memory structures and interface process management on the HUB.
With point-to-multipoint GRE the tunnel source should be public routable, in our case we set mGRE packet to take serial 1/0 as an output interface to the SP network, the tunnel destination address is dynamically assigned.
Tunnel source and destination form the outer IP header that will carry the encapsulated traffic throughout the physical topology.
All tunnels participating to mGRE network are identified by a tunnel key ID and belongs to the same subnet 172.16.0.129/26, from the private address space and routable only inside the company’s network.
HUB:
interface Tunnel0
ip address 172.16.0.129 255.255.255.192
!!The mGRE packet will be encapsulated out of the physical interface
tunnel source Serial1/0
!!Enable mGRE
tunnel mode gre multipoint
!! Tunnel identification key, match the NHRP network-id
tunnel key 1
SPOKEA :
interface Tunnel0
ip address 172.16.0.130 255.255.255.192
tunnel source Serial1/0
tunnel mode gre multipoint
tunnel key 1
SPOKEB :
interface Tunnel0
ip address 172.16.0.131 255.255.255.192
tunnel source Serial1/0
tunnel mode gre multipoint
tunnel key 1
SPOKEC :
interface Tunnel0
ip address 172.16.0.132 255.255.255.192
tunnel source Serial1/0
tunnel mode gre multipoint
tunnel key 1
So far, all tunnel protocol state still down, because tunnels destination addresses are unknown, so unreachable.
The HUB router knows that traffic destined to 172.16.0.128/26 will be forwarded to the serial interface (tunnel source) to be encapsulated into the needed mGRE tunnel and all other traffic will be reachable through the next hop physical interface 192.168.0.18, therefore no particular information about spokes on the HUB except that they belong to 172.16.0.128/26.
II-3 Static routing:
HUB:
ip route 0.0.0.0 0.0.0.0 192.168.0.18
ip route 172.16.0.0 255.255.255.192 Serial1/0
As opposed to the HUB, all spokes know the HUB physical IP address 192.168.0.17 and how to reach it statically (through s1/0). All other traffic will be forwarded to the next hop physical interface IP address.
On SPOKEA:
!! Forward all traffic to the ISP next-hop destination
ip route 0.0.0.0 0.0.0.0 192.168.0.14
!! The HUB physical interface is reachable through serial1/0
ip route 192.168.0.17 255.255.255.255 Serial1/0
On SPOKEB:
ip route 0.0.0.0 0.0.0.0 192.168.0.10
ip route 192.168.0.17 255.255.255.255 Serial1/0
On SPOKEC:
ip route 0.0.0.0 0.0.0.0 192.168.0.5
ip route 192.168.0.17 255.255.255.255 Serial1/0
II-4 Dynamic routing:
Figure3: routing topology
Each spoke protects a set of private subnet, not known by others; all other routers must be informed of these subnets.
With distance vector protocols like RIP or EIGRP the specification of “no-split horizon” is required for the updates to be sent back to the mGRE interface to other spokes.
With Link State protocols like OSPF the appropriate next-hop is automatically reflected within the subnet.
Typically OSPF is configured in point-to-multipoint mode on mGRE interfaces, this cause spokes to install routes with the HUB as next-hop, which negates DMVPN network topology concept, for that reason DMVPN cloud must be treated as broadcast.
NBMA – Non Broadcast Multiple Access are networks where multiple hosts/devices are connected, but data is sent directly to the destination over a virtual circuit or switching fabric like ATM, FR or X.25.
Broadcast networks – All hosts connected to the network listen to the media but only the host/device to which the communication is intended will receive the frame.
Cisco prefer Distance Vector protocols and recommend using EIGRP for large scale deployments.
Spokes OSPF priorities are set to 0 to force them in DROTHER mode and never become DR/BDR, whereas the HUB priority is set to a higher value “10” for instance.
All routers must be configured to announce the mGRE subnet 172.16.0/128 as area 0 and 10.0.1.0/24, 10.0.2.0/24, 10.0.3.0/24 and 10.0.4.0/24 as OSPF non-backbone area10, area11, area12 and area13 respectively.
Note that the routing protocol is dealing only with mGRE logical topology.
HUB:
interface Tunnel0
ip ospf network broadcast
ip ospf priority 10
!
router ospf 10
router-id 1.1.0.1
!! Announce local networks.
network 10.0.1.0 0.0.0.255 area 10
!! Announce mGRE network as OSPF backbone
network 172.16.0.128 0.0.0.63 area 0
SPOKEA:
interface Tunnel0
ip ospf network broadcast
ip ospf priority 0
!
router ospf 10
router-id 1.1.1.1
network 10.0.2.0 0.0.0.255 area 11
network 172.16.0.128 0.0.0.63 area 0
SPOKEB:
interface Tunnel0
ip ospf network broadcast
ip ospf priority 0
!
router ospf 10
router-id 1.1.2.1
network 10.0.3.0 0.0.0.255 area 12
network 172.16.0.128 0.0.0.63 area 0
SPOKEC:
interface Tunnel0
ip ospf network broadcast
ip ospf priority 0
!
router ospf 10
router-id 1.1.3.1
network 10.0.4.0 0.0.0.255 area 13
network 172.16.0.128 0.0.0.63 area 0
II-5 Next Hop Resolution Protocol – NHRP:
NHRP role is to discover address of other routers/hosts connected to a NBMA. Generally NBMA networks require tedious static configuration (static mapping between network layer address).
NHRP provides ARP like resolution and dynamically learn addresses of devices connected to the same NBMA networks from a next-hop server and then directly communicate them without passing through intermediate systems like in traditional Hub and Spoke topologies.
In our case the NHRP will facilitate building GRE tunnels. The HUB will maintain NHRP database of spokes mGRE virtual addresses associated to their public interface addresses. Each spoke registers its public address when it boots and queries the NHRP database for other spokes IP when needed.
On each tunnel interface, NHRP must be enabled and identified, it is recommended that the NHRP network-id match tunnel key.
NHRP participants can optionally be authenticated.
Because NHRP is a client-server protocol, the server (HUB) doesn’t need to know clients, nevertheless clients have to know the server.
Spokes explicitly set HUB as the next-hop server and statically tie the HUB virtual tunnel IP to the HUB physical interface s1/0. In the same manner spokes must map multicast forwarding to the HUB virtual mGRE IP address.
The same configuration is required in the HUB site but without any mapping or next-hop servers just map multicast forwarding to any new dynamically created NHRP adjacency.
HUB:
interface Tunnel0
ip nhrp authentication cisco
ip nhrp map multicast dynamic
ip nhrp network-id 1
ip nhrp cache non-authoritative
ip ospf network broadcast
SPOKEA:
interface Tunnel0
ip nhrp authentication cisco
ip nhrp map multicast 192.168.0.17
ip nhrp map 172.16.0.129 192.168.0.17
ip nhrp network-id 1
ip nhrp nhs 172.16.0.129
SPOKEB:
interface Tunnel0
ip nhrp authentication cisco
ip nhrp map multicast 192.168.0.17
ip nhrp map 172.16.0.129 192.168.0.17
ip nhrp network-id 1
ip nhrp nhs 172.16.0.129
SPOKEC:
interface Tunnel0
ip nhrp authentication cisco
ip nhrp map multicast 192.168.0.17
ip nhrp map 172.16.0.129 192.168.0.17
ip nhrp network-id 1
ip nhrp nhs 172.16.0.129
II-6 IPSec VPN:
The only thing to do after setting IPSec phase 1 and phase 2 parameters is to define an IPSec profile and assign it to the mGRE tunnel interface.
Table3: IPSec parameters
PHASE 1 | |||||||||||||||||||||||||
IKE parameters | |||||||||||||||||||||||||
PHASE 2 |
|||||||||||||||||||||||||
|
!!IKE phase1 – ISAKMP
crypto isakmp policy 1
!! Symmetric key algorithm for data encryption
encr 3des
!! authentication type using static key between participants
authentication pre-share
!! asymmetric algorithm for establishing shared symmetric key across the network
group 2
!! preshared key and peer (dynamic)
crypto isakmp key cisco address 0.0.0.0 0.0.0.0
!!IKE phase2 – IPSEec
crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
mode transport
crypto ipsec profile IPSecProfile
set transform-set ESP-3DES-SHA
interface Tunnel0
!!encapsulate IPSec inside mGRE
tunnel protection ipsec profile IPSecProfile
III – MONITORING
HUB:
First of all, Make sure those s1/0 and tunnel interfaces are up/up, otherwise review your static routing statements.
HUB#sh ip int brief
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 unassigned YES NVRAM administratively down down
Serial1/0 192.168.0.17 YES NVRAM up up
Serial1/1 unassigned YES NVRAM administratively down down
Serial1/2 unassigned YES NVRAM administratively down down
Serial1/3 unassigned YES NVRAM administratively down down
Loopback0 10.0.1.1 YES NVRAM up up
Loopback1 1.1.0.1 YES manual up up
Tunnel0 172.16.0.129 YES NVRAM up up
HUB#
After spokes have registered to the HUB through NHRP protocol, the HUB have dynamically learned IP addresses of all participants of the mGRE (logical topology) and know how to reach them through the physical topology.
Spokes mGRE tunnel IP addresses are mapped to their physical public routable IP’s.
HUB#sh ip nhrp
172.16.0.130/32 via 172.16.0.130, Tunnel0 created 02:40:11, expire 01:22:18
Type: dynamic, Flags: unique registered
NBMA address: 192.168.0.13
172.16.0.131/32 via 172.16.0.131, Tunnel0 created 02:40:14, expire 01:21:45
Type: dynamic, Flags: unique registered
NBMA address: 192.168.0.9
172.16.0.132/32 via 172.16.0.132, Tunnel0 created 02:40:14, expire 01:21:54
Type: dynamic, Flags: unique registered
NBMA address: 192.168.0.6
HUB#
The HUB establishes mGRE tunnel with all spokes and initiate OSPF neighbor relationship with each one of them.
All routers will exchange routing information through the HUB.
HUB#sh ip ospf neigh
Neighbor ID Pri State Dead Time Address Interface
1.1.1.1 0 FULL/DROTHER 00:00:32 172.16.0.130 Tunnel0
1.1.2.1 0 FULL/DROTHER 00:00:35 172.16.0.131 Tunnel0
1.1.3.1 0 FULL/DROTHER 00:00:32 172.16.0.132 Tunnel0
HUB#
Now the HUB knows about all spokes local networks.
HUB#sh ip route
Codes: C – connected, S – static, R – RIP, M – mobile, B – BGP
D – EIGRP, EX – EIGRP external, O – OSPF, IA – OSPF inter area
N1 – OSPF NSSA external type 1, N2 – OSPF NSSA external type 2
E1 – OSPF external type 1, E2 – OSPF external type 2
i – IS-IS, su – IS-IS summary, L1 – IS-IS level-1, L2 – IS-IS level-2
ia – IS-IS inter area, * – candidate default, U – per-user static route
o – ODR, P – periodic downloaded static route
Gateway of last resort is 192.168.0.18 to network 0.0.0.0
1.0.0.0/32 is subnetted, 1 subnets
C 1.1.0.1 is directly connected, Loopback1
172.16.0.0/26 is subnetted, 2 subnets
C 172.16.0.128 is directly connected, Tunnel0
S 172.16.0.0 is directly connected, Serial1/0
10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
O IA 10.0.3.1/32 [110/11112] via 172.16.0.131, 02:16:51, Tunnel0
O IA 10.0.2.1/32 [110/11112] via 172.16.0.130, 02:16:51, Tunnel0
C 10.0.1.0/24 is directly connected, Loopback0
O IA 10.0.4.1/32 [110/11112] via 172.16.0.132, 02:16:51, Tunnel0
192.168.0.0/30 is subnetted, 1 subnets
C 192.168.0.16 is directly connected, Serial1/0
S* 0.0.0.0/0 [1/0] via 192.168.0.18
HUB#
HUB#ping
Protocol [ip]:
Target IP address: 10.0.2.1
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 10.0.1.1
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.2.1, timeout is 2 seconds:
Packet sent with a source address of 10.0.1.1
!!!!!
Success rate is 40 percent (2/5), round-trip min/avg/max = 80/116/152 ms
HUB#
HUB#ping
Protocol [ip]:
Target IP address: 10.0.4.1
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 10.0.1.1
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.4.1, timeout is 2 seconds:
Packet sent with a source address of 10.0.1.1
!!!!!
Success rate is 60 percent (3/5), round-trip min/avg/max = 104/128/144 ms
HUB#
SPOKEA:
Routing information is exchanged between all routers via the HUB, this is the only OSPF neighbor relationship spokes establish.
SPOKEA#sh ip ospf neigh
Neighbor ID Pri State Dead Time Address Interface
1.1.0.1 1 FULL/DR 00:00:32 172.16.0.129 Tunnel0
SPOKEA#
Nevertheless, advertised networks are directly reachable through the router that announced them.
SPOKEA#sh ip route
…
Gateway of last resort is 192.168.0.14 to network 0.0.0.0
1.0.0.0/32 is subnetted, 1 subnets
C 1.1.1.1 is directly connected, Loopback1
172.16.0.0/26 is subnetted, 1 subnets
C 172.16.0.128 is directly connected, Tunnel0
10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
O IA 10.0.3.1/32 [110/11112] via 172.16.0.131, 00:01:25, Tunnel0
C 10.0.2.0/24 is directly connected, Loopback0
O IA 10.0.1.1/32 [110/11112] via 172.16.0.129, 00:01:25, Tunnel0
O IA 10.0.4.1/32 [110/11112] via 172.16.0.132, 00:01:25, Tunnel0
192.168.0.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.0.12/30 is directly connected, Serial1/0
S 192.168.0.17/32 is directly connected, Serial1/0
S* 0.0.0.0/0 [1/0] via 192.168.0.14
SPOKEA#
Spoke A knows about the next-hop server, the HUB, through a static map statement and will register by announcing to the HUB its physical public routable IP address assigned to its virtual mGRE IP.
SPOKEA#sh ip nhrp
172.16.0.129/32 via 172.16.0.129, Tunnel0 created 00:02:03, never expire
Type: static, Flags: authoritative used
NBMA address: 192.168.0.17
When spokeA wants to communicate with 10.0.4.1/32 it inspects the routing table and will find that 10.0.4.1 is reachable though the next-hop mGRE address 172.6.0.129.
SpokeA will ask the HUB about the public IP address that corresponds to 172.16.0.129, the HUB will reply with 192.168.0.6; only then, the spoke will send the traffic directly to SPOKEC.
According to the outputs of “debug tunnel” and a “traceroute” commands on spokeB, you can note that the next-hop of the mGRE network is the final destination and there is no intermediate hops, this is confirmed by the delivery through the physical topology where mGRE traffic is encapsulated and sent directly from 192.168.0.6 to 192.168.0.9 with no intermediate hops.
SPOKEB#debug tunnel
Tunnel Interface debugging is on
SPOKEB#traceroute 172.16.0.132
Type escape sequence to abort.
Tracing the route to 172.16.0.132
1 172.16.0.132 80 msec
*Mar 1 00:03:55.839: Tunnel0: GRE/IP to decaps 192.168.0.6->192.168.0.9 (len=84 ttl=253)
*Mar 1 00:03:55.843: Tunnel0: GRE decapsulated IP 172.16.0.132->172.16.0.131 (len=56, ttl=255) * 44 msec
SPOKEB#
Because DMVPN involves several concepts multipoint GRE, NHRP, dynamic routing and IPSec, troubleshooting issues can be very time consuming, so the best practice is to focus on each step and make sure things work well before configuring the next step.
Hello.
Anybody knows if there is a way to create a spoke using OpenBSD operating system?
That OS surely supports IPSec and GRE, but as far as I searched the Internet, I didn’t find any clue if OpenBSD supports NHRP.
Any clearing is appreciated.
Thanks in advance.
Bye.
Alex
Hi Alex,
There is indeed an open source project (sourceforge) called openhrp under linux, I don’t know if it is possible to compile it under OpenBSD, but sounds promissing.
It might help:
http://sourceforge.net/projects/opennhrp
IPsec Deployment under OpenBSD
http://blogs.techrepublic.com.com/networking/?p=35&tag=rbxccnbtr1
Good work!
Thanks for the suggestion.
I already knew about opennhrp and yes, OpenBSD can run Linux binaries. But since opennhrp is not still a “complete” product and since it’s not native for OpenBSD, I searched for a project completely based on *BSD systems.
Anyway, thanks for the fast answer. I appreciated it.
Good work to you!
Alex
Could somebody explain why OSPF advertise only host ( /32 ) and not complete /24 Network? And why I get in constant time intervals “adjacency changed” messages?
Thx
Hi Dima,
This is how Cisco routers behave by default with loopback interfaces, there is several solutions to remediate to this issue :
1- If the area to which the loopback belongs is contiguous to area 0:
1.1- Change loopback OSPF network type.
1.2- Summarize loopback IP (as from ABR).
2- If the area to which the loopback belongs is non-contiguous to area 0, join the two area using traditional methods (OSPF virtual links or GRE/IPIP tunneling) in addition to either (1.1) or (1.2).
3- Redistribute connected (as from ASBR).
For more details, please refer to the following post OSPF loopback network type/
Regarding to the second issue,
– Make sure all neighbors in the same segment are using the same OSPF network type, otherwise some parameters could match to establish neighbor relationship but not others which can cause neighbor to be “unreachable”.
– if you are using “broadcast” OSPF network type (default for Fast Ethernet) check subnet matching.
Without topology, IPs and configuration, these remains general advices.
Hope it helps
AJN
Thanks, it helps a lot. The first question I could solve with “ip ospf network point-to-point”
But I still don’t know what to do with 2nd question. I used the same topology, configuration and IPs as in example. Furthermore I remember as I used same topology, for NHRP – only without IPsec. I had the same thing. Its not that OSPF or EIGRP doesn’t work – it works fine, but every time the “hello timer” ( I guess ) expires I get the “adjacency changed to down” message and then shortly is the adjacency up again until the hello timer expires.
I guess it could be solved with Multicast providing (pim dense-sparse mods) – but I do know too few about it, that I could simply “test out”.
Dima
– With EIGRP make sure in a given segment all connected devices use whether multicast (default behavior) or unicast (using “neighbor” command)
– if you are using any layer2 device between your EIGRP routers and there is a layer2 issue, connected layer3 devices will not be informed until the expiration of relationships timers.
– if you have “holdtime expired” ==> router using multicast
– if you have “retry-limit exceeded ==> router using unicast
– PIM modes matter with IGP using multicast over FR NBMA partial mesh with multipoint interfaces, you will need to enable pseudo-broadcast when mapping PVCs.(Multicast over NBMA/)
– if you are advertising multicast use PIM-SM with RP at the HUB site or PIM-Sparse-Dense mode with multicast agent and the source at the HUB site.
AJN
Good work, I learn a lot today.
Hello Sir,
Great work and excellent explanation.
I learned a lot on DMVPN today. I have done all but seems small correction needed. When i ‘debug tunnel’ and ‘traceroute to 172.16.0.132’ i am not getting ‘GRE decapsulated logical mapping address’ rather i am getting like this ::
R5#trace 172.16.0.132
Type escape sequence to abort.
Tracing the route to 172.16.0.132
1 172.16.0.132 156 msec
*Mar 1 02:39:48.631: Tunnel0 count tx, adding 28 encap bytes
*Mar 1 02:39:48.779: Tunnel0: GRE/IP to classify 192.168.0.6->192.168.0.13 (len=84 type=0x800 ttl=252 tos=0xC0)
*Mar 1 02:39:48.783: Tunnel0: GRE/IP to decaps 192.168.0.6->192.168.0.13 (len=84 ttl=252)
*Mar 1 02:39:48.783: Tunnel0: GRE decapsulated IP packet (linktype=7, len=56)
*Mar 1 02:39:48.791: Tunnel0 count tx, adding 28 encap bytes * 120 msec
Except this all is working fine. When i verified tunnel, for me looks okay but did not work as expected
I have enclose IpSec details here.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
R5#sh crypto ipsec sa
interface: Tunnel0
Crypto map tag: Tunnel0-head-0, local addr 192.168.0.13
protected vrf: (none)
local ident (addr/mask/prot/port): (192.168.0.13/255.255.255.255/47/0)
remote ident (addr/mask/prot/port): (192.168.0.6/255.255.255.255/47/0)
current_peer 192.168.0.6 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 3, #pkts encrypt: 3, #pkts digest: 3
#pkts decaps: 2, #pkts decrypt: 2, #pkts verify: 2
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0
local crypto endpt.: 192.168.0.13, remote crypto endpt.: 192.168.0.6
path mtu 1500, ip mtu 1500, ip mtu idb Serial0/0
current outbound spi: 0x7C8EE5E8(2089739752)
inbound esp sas:
spi: 0x9B418D8(162797784)
transform: esp-3des esp-sha-hmac ,
in use settings ={Transport, }
conn id: 7, flow_id: SW:7, crypto map: Tunnel0-head-0
sa timing: remaining key lifetime (k/sec): (4512281/3370)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0x7C8EE5E8(2089739752)
transform: esp-3des esp-sha-hmac ,
in use settings ={Transport, }
conn id: 8, flow_id: SW:8, crypto map: Tunnel0-head-0
sa timing: remaining key lifetime (k/sec): (4512281/3370)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE
outbound ah sas:
outbound pcp sas:
protected vrf: (none)
local ident (addr/mask/prot/port): (192.168.0.13/255.255.255.255/47/0)
remote ident (addr/mask/prot/port): (192.168.0.9/255.255.255.255/47/0)
current_peer 192.168.0.9 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 8, #pkts encrypt: 8, #pkts digest: 8
#pkts decaps: 10, #pkts decrypt: 10, #pkts verify: 10
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0
local crypto endpt.: 192.168.0.13, remote crypto endpt.: 192.168.0.9
path mtu 1500, ip mtu 1500, ip mtu idb Serial0/0
current outbound spi: 0x36919AB3(915511987)
inbound esp sas:
spi: 0xA2D3E51C(2731795740)
transform: esp-3des esp-sha-hmac ,
in use settings ={Transport, }
conn id: 5, flow_id: SW:5, crypto map: Tunnel0-head-0
sa timing: remaining key lifetime (k/sec): (4442129/1412)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0x36919AB3(915511987)
transform: esp-3des esp-sha-hmac ,
in use settings ={Transport, }
conn id: 6, flow_id: SW:6, crypto map: Tunnel0-head-0
sa timing: remaining key lifetime (k/sec): (4442128/1412)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE
outbound ah sas:
outbound pcp sas:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Please explain me where i am missing and how can i fix it. Thanks a lot in advance.
Br
Gangadhar
Thank you Gangadhar, glad to help.
It looks like a routing issue.
With tunneling encapsulation we will have 2 levels of routing :
– The 1st related to the outer header “PUBLIC”
– The second is related to the encapsulated inner header “PRIVATE”
Make sure the “PRIVATE” address scheme is reachable through the mGRE tunnel so it can forwarded to the tunnel (second level) and then encapsulated to be send to the “PUBLIC network”.
Thank you very much sir for the reply and insight. I will correct it and pactice other scenarios as well.
I am following your articles with a great hope in my ‘CCIE pursuing’ path. My confidence is building slowly. You are my inspirer, sorry…..can’t stop saying this words my self.
Thanks once again for great works and providing high standards of articles.
– Gangadhar
Great Great Great for all !!!
Now i have used above config in my GNS3 Lab with 3745 cisco router (c3745-jk9s-mz.123-24a.image). i can ping all spokes from the HUB but not the reverse. Plse below for all config:
– ISP
Int fast 1/0
Ip addr 192.168.0.18 255.255.255.252
No shut
!
Int fast 2/0
Ip addr 192.168.0.5 255.255.255.252
No shut
!
Int fast 3/0
Ip addr 192.168.0.10 255.255.255.252
No shut
!
Int fast 4/0
Ip addr 192.168.0.14 255.255.255.252
No shut
————————————————————————————————————————————————————————————————————-
– HUB
Int fast 1/0
Ip addr 192.168.0.17 255.255.255.252
No shut
interface Tunnel0
ip address 172.16.0.129 255.255.255.192
tunnel source fast 1/0
tunnel mode gre multipoint
tunnel key 1
ip route 0.0.0.0 0.0.0.0 192.168.0.18
ip route 172.16.0.0 255.255.255.192 fast 1/0
interface Tunnel0
ip ospf network broadcast
ip ospf priority 10
!
router ospf 10
router-id 1.1.0.1
network 10.0.1.0 0.0.0.255 area 10
network 172.16.0.128 0.0.0.63 area 0
interface Tunnel0
ip nhrp authentication cisco
ip nhrp map multicast dynamic
ip nhrp network-id 1
ip nhrp cache non-authoritative
ip ospf network broadcast
crypto isakmp policy 1
encr 3des
authentication pre-share
group 2
crypto isakmp key cisco address 0.0.0.0 0.0.0.0
crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
mode transport
crypto ipsec profile IPSecProfile
set transform-set ESP-3DES-SHA
interface Tunnel0
tunnel protection ipsec profile IPSecProfile
————————————————————————————————————————————————————————————————————-
– Spoke A
Int fast 2/0
Ip addr 192.168.0.6 255.255.255.252
No shut
!
interface Tunnel0
ip address 172.16.0.130 255.255.255.192
tunnel source fast 2/0
tunnel mode gre multipoint
tunnel key 1
ip route 0.0.0.0 0.0.0.0 192.168.0.14
ip route 192.168.0.17 255.255.255.255 fast 2/0
interface Tunnel0
ip ospf network broadcast
ip ospf priority 0
!
router ospf 10
router-id 1.1.1.1
network 10.0.2.0 0.0.0.255 area 11
network 172.16.0.128 0.0.0.63 area 0
interface Tunnel0
ip nhrp authentication cisco
ip nhrp map multicast 192.168.0.17
ip nhrp map 172.16.0.129 192.168.0.17
ip nhrp network-id 1
ip nhrp nhs 172.16.0.129
crypto isakmp policy 1
encr 3des
authentication pre-share
group 2
crypto isakmp key cisco address 0.0.0.0 0.0.0.0
crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
mode transport
crypto ipsec profile IPSecProfile
set transform-set ESP-3DES-SHA
interface Tunnel0
tunnel protection ipsec profile IPSecProfile
————————————————————————————————————————————————————————————————————-
– SPOKE B
Int fast 3/0
Ip addr 192.168.0.9 255.255.255.252
No shut
interface Tunnel0
ip address 172.16.0.131 255.255.255.192
tunnel source fast 3/0
tunnel mode gre multipoint
tunnel key 1
ip route 0.0.0.0 0.0.0.0 192.168.0.10
ip route 192.168.0.17 255.255.255.255 fast 3/0
interface Tunnel0
ip ospf network broadcast
ip ospf priority 0
!
router ospf 10
router-id 1.1.2.1
network 10.0.3.0 0.0.0.255 area 12
network 172.16.0.128 0.0.0.63 area 0
interface Tunnel0
ip nhrp authentication cisco
ip nhrp map multicast 192.168.0.17
ip nhrp map 172.16.0.129 192.168.0.17
ip nhrp network-id 1
ip nhrp nhs 172.16.0.129
crypto isakmp policy 1
encr 3des
authentication pre-share
group 2
crypto isakmp key cisco address 0.0.0.0 0.0.0.0
crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
mode transport
crypto ipsec profile IPSecProfile
set transform-set ESP-3DES-SHA
interface Tunnel0
tunnel protection ipsec profile IPSecProfile
————————————————————————————————————————————————————————————————————-
– SPOKE C
Int fast 4/0
Ip addr 192.168.0.13 255.255.255.252
No shut
interface Tunnel0
ip address 172.16.0.132 255.255.255.192
tunnel source fast 4/0
tunnel mode gre multipoint
tunnel key 1
ip route 0.0.0.0 0.0.0.0 192.168.0.5
ip route 192.168.0.17 255.255.255.255 fast 4/0
interface Tunnel0
ip ospf network broadcast
ip ospf priority 0
!
router ospf 10
router-id 1.1.3.1
network 10.0.4.0 0.0.0.255 area 13
network 172.16.0.128 0.0.0.63 area 0
interface Tunnel0
ip nhrp authentication cisco
ip nhrp map multicast 192.168.0.17
ip nhrp map 172.16.0.129 192.168.0.17
ip nhrp network-id 1
ip nhrp nhs 172.16.0.129
crypto isakmp policy 1
encr 3des
authentication pre-share
group 2
crypto isakmp key cisco address 0.0.0.0 0.0.0.0
crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
mode transport
crypto ipsec profile IPSecProfile
set transform-set ESP-3DES-SHA
interface Tunnel0
tunnel protection ipsec profile IPSecProfile
————————————————————————————————————————————————————————————————————-
1- I can’t ping from spoke to spoke
plse at which step are isue ?
Sam
Pingback: Mpls Vpn Configuration Example u002bbgp | MPLS
Dear Sir, Great work.
can you please give me example that how to configure DMVPN , even if i have Dynamic ip address on HUB. i want to use. DDns Service.