DMVPN Introduction (Dynamic Multipoint VPN)


Well…its been a while since last time I post something to my beloved blog, and now lets go straight to the topic

What is DMVPN? Why we use it? And How we do it?

Prerequisite for learning:

  • GRE (generic routing encapsulation)
  • knowledge of Routing (Protocol)
  • and….a little bit about CEF

btw…since this is the introduction, I’ll teach you how to develop DMVPN Phase 1



A problem with GRE…

Klo kita punya kasus kek gambar diatas…bagaimana supaya R2, R3, R4 bisa terkoneksi satu sama lain dengan GRE?

Klo yang pernah nyoba pasti jawabnya…Hub-and-Spoke atau lebih bagus lagi…FULL MESH

Baru 4 node aja…kita harus handle 6 tunnel, bayangin klo 7, 8, sampe 10 router atau kantor cabang

The solution…we will build dynamic tunnel called DMVPN (Dynamic Multipath VPN)


DMVPN…how it works

DMVPN itu terdiri dari 3(5) teknologi:

  1. Multipoint GRE (mGRE)
  2. Next-Hop Resolution Protocol (NHRP)
  3. Dynamic Routing Protocol (EIGRP, RIP, OSPF, BGP)
  4. *Dynamic IPsec encryption
  5. *Cisco Express Forwarding (CEF)

Basic DMVPN cukup pake 3 point diatas…Secure DMVPN baru pake point 4, dan…DMVPN phase 2 & 3 pake point 5

DMVPN phase? Ya…DMVPN VPN dibagi jadi 3 fase

  • Phase 1: Spoke register dynamically to Hub each time they want to do communication between Spoke
  • Phase 2: Spoke-to-Spoke tunnel…using CEF, but still use Hub for NHRP source
  • Phase 3: multiple Hub for scalability

mGRE: daripada gw bikin tunnel static tiap node kek GRE, mending gw bikin hub-and-spoke aja, gw tanyain ke hub…jalan untuk ke tujuan/destination lewat mana, baru gw bikin tunnel kesana

trus nanyainnya pake apa? Pake NHRP (Next-Hop Resolution Protocol)

Apaan itu NHRP? Next Hop Resolution Protocol (NHRP) is a protocol or method that can be used so that a computer sending data to another computer can learn the most direct route (the fewest number of hops) to the receiving computer (RFC 2332)

Kek contoh diatas…tapi mirip kek ARP (Address Resolution Protocol) yah? Ho oh

Bedanya dimana? Ya beda tong…ARP minta tolong switch buat minta next-hop mac-address, NHRP minta tolong router untuk minta next-hop IP

Spoke dalam NHRP disebut NHC (NHRP Client), sedangkan Hub dalam NHRP disebut NHS (NHRP Server)


DMVPN Configuration


  • IP addressing and Default route in each router (except Internet)
  • Klo pake GNS…pake IOS 3725

On Hub (R1)


Int tunnel 0 dan tunnel source fa0/0 pretty self-explanatory (and ip address too)

  • Tunnel mode gre multipoint: ini mGRE-nya
  • Tunnel key 1234: security measure buat tunnel (MANDATORY since IOS 12.3(14)T or 12.3(11)T3…klo ga, mGRE ga mau jalan)
  • Ip nhrp network-id: locally significant, biar si router tau dia mau ngirim NHRP ke “domain” mana (jadi 2 tunnel atau lebih bisa join di domain yang sama, lebih dinamis…contoh: buat PT.A pake id 1, buat PT.B pake id 2)
  • Ip nhrp authentication [STRING]: security measure, hanya node2 yang tau yang berhak bikin tunnel via registrasi ke hub
  • Ip nhrp map multicast dynamic: salah satu key component DMVPN, jadi Hub bisa mapping siapa mau bikin tunnel ke siapa, asal ngomong dulu ke dia (mapping-nya kek mac-address Port Security “sticky” di switch)
  • Ip nhrp shortcut: digunakan di DMVPN phase 3, untuk rewrite CEF entry…after getting redirect message? Who gave it?…
  • Ip nhrp redirect: this is the one who gave it, fitur ini mirip ke ICMP Redirect, klo si hub tau best path ke destination yang lebih pendek/cepat…dia akan ngasih tau ke source node-nya “kirim aja ke sono langsung…”

Jadi untuk ip nhrp shortcut and redirect digunakan untuk DMVPN phase 2 dan 3


Rata2 sekarang switch/router sudah mendukung jumbo frame (MTU lebih dari 1500), tapi klo engga…dengan path-mtu-discovery, router bisa ngukur besar paket yang akan dikirim supaya ga di fragmentasi (that’s the definition of MTU right?!?)

(kadang2 suka ga jalan ini mtu-discovery, entah karena ICMP nya ke blok makanya “pengukuran” MTU-nya kaga jalan, jadi kasi aja no path-mtu-discovery…). Kita juga bisa kasi manual MTU limiter kek Ip mtu 1400 artinya kita set max MTU 1400, nah MSS (max-segment size) kita kurangin -40 (best practice dr expert gitu, gw juga ga tau kenapa mesti -40) jadi 1360 biar ga kepotong (tindakan preventif kali ya…)

In R2, R3, and R4 (bedain IP-nya aja)


Most notable configuration in this router is ip nhrp nhs [destination tunnel ip address], artinya kita ngasi tau ke router ini…klo mau bikin tunnel tolong registrasi ke ip tersebut (NHS)

Emang ip tersebut bisa diraih lewat mana? Untuk bisa ke ip tersebut kita pointing ke ip physical/fisiknya router target, and that’s why ip nhrp map [ip tunnel] [ip physical] placed in CLI

Plus klo mau multicast…kirim aja ke ip physical tersebut juga dengan ip nhrp map multicast [ip physical]

By the way…dalam NHRP…IP Physical tersebut dinamakan NBMA Address

DMVPN is done…anything missing? Yes…now the routing takes place

Masukin ip network tunnel-nya, masukin juga network (di R2, R3, dan R4 juga sama)

Don’t forget….EIGRP is DISTANCE VECTORthere is SPLIT HORIZON (jalan keluar DAN masuknya Cuma 1…interface tunnel 0), so disabling split-horizon (no ip split-horizon) and next-hop-self (no ip next-hop-self) will do the wonder


The Verification

Dari sini kita bisa liat…R1 dynamically learn about others tunnel via NHRP

And lets check out the routing table

Lets check in R2 pinging and tracing to R3

Lets check the wireshark…(coba ping dari R4 ke R2, trus cek di R1…jgn di cek sama yang udah tunneling kek R2 ke R4 misalkan)

Anddd…R1 correctly redirect to which is R2 tunnel IP



DMVPN Explained by Petr Lapukhov #16379 @http://blog.ine.com/2008/08/02/dmvpn-explained/

DMVPN Type by by Petr Lapukhov #16379 @http://blog.ine.com/2008/12/23/dmvpn-phase-3/#more-400

NHRP by IETF RFC 2332 @http://www.ietf.org/rfc/rfc2332.txt?number=2332

NHRP Network-id https://supportforums.cisco.com/discussion/12075461/dmvpn-ip-nhrp-network-id

Adjust MSS https://learningnetwork.cisco.com/thread/40703

BGP Configuration (Part 3)


Part 1 and Part 2

Let’s learn about another BGP Features like:

  • Local-AS
  • Next-Hop-Self
  • Backdoor
  • Multihoming (Load-Sharing)
  • eBGP Multi-Hop


BGP Local-AS

Typically, this feature comes up when ISP A acquisitioning ISP B, but ISP C (or customers from ISP B) doesn’t want to change BGP Peering (change AS again, change neighbor, and so on)

Figure 1. initial network diagram

Figure 2. after acquisition form ISP A

Figure 3. initial BGP network from ISP C point of view

And then…ISP A bought ISP B, therefore all router in ISP B changed into AS 100 (ISP A)…but ISP C doesn’t want to change anything in their routers (too complicated they say…wkwkw)

So…let’s configure like this

Figure 4. local as configuration

ISP B Router says “I am AS 100 now, but…You (ISP C) can still recognize me as AS 200

Let’s see in ISP C

Figure 5. ISP C still recognize ISP B AS 200

See…no problem at all, ISP C still thinks that ISP B is AS 200 (even though ISP A Bought it and change that ISP B AS into AS 100)

If, somehow, somebody with directly above your position as engineer say…”remove those AS 200 from the AS-Path, we don’t need it anymore”

Use this at ISP B… neighbor [ip neighbor] local-as [AS] no-prepend

The result is…for example is via AS 100 only

But if you want to change the AS Path from 100 to 200 only, just add “replace-as” beside no-prepend keyword

neighbor [ip neighbor] local-as [AS] no-prepend replace-as


BGP Next-Hop-Self

Figure 6. Example topology

One of the BGP rules is “the next hop is always the IP address of the neighbor specified in the neighbor command

R2 learns via R1 through e-BGP, so next-hop to route to in the R2 perspectives is through (fa0/0 R1)

But when R2 advertise the route to R3, R3 learns that next-hop to is through too (which is incorrect, it should be through fa0/0 R2)

Figure 7. from R3

This is where BGP Next-Hop-Self is useful

We told R2 that he must advertise all route he learn, to neighbor (which is R3) with next-hop directed to himself (R2)

Figure 8. change in R3

Another mention is when configuring BGP in multi-access network such as Ethernet

In topology above, R3 advertise from R4 (let’s say acquired via OSPF) to R1

But, instead of advertising (fa0/0 R3) next-hop to R2, R1 advertise next-hop to is via (fa0/0 R4)

Why ? because it make sense that R1,R3, and R4 is in the same network, same directly connected network, therefore R1 choose to most specific one to route


BGP Backdoor

The case is like this, both R1 and R2 run e-BGP to R3, but somehow R1 and R2 run IGP (like OSPF for example)

When R1 want to send packet to (R2), he learn 2 paths

  • Via R2, which is OSPF, with AD 110
  • Via R3, which is BGP, with AD 20 (e-BGP)

The logic is…R1 sent packet via R3…but we don’t want to happen like this way

The solutions are 2 ways:

  • Edit Administrative Distance, which is not recommended
  • Run BGP Backdoor

The initial configuration are like this:

The result of those configurations is

R1 will sent packet to via BGP not directly to R2 because AD difference

Now…lets configure the backdoor command

This means…for network the BGP AD, use the IGP AD



BGP Multihoming

Right now we discuss about Multihoming with different AS (configuring multihoming with same AS is not much difference because common e-BGP configuration)

And also Load-sharing it (BGP can’t perform load balancing but it can perform load sharing)

Load sharing
is the ability to distribute incoming/outgoing traffic over multiple paths

Load balancing
is the ability to split the load (split packet) toward the same destination (host or IP) over multiple paths.

Configure all routers to e-BGP first…don’t forget to advertise on R1 and on R4

Example configuration on R1:

Maximum-path keyword is for load sharing

The result on R1 should be like this

Let’s ping and trace it…

Now we see…even though there are 2 path, R1 BGP only choose the first established one

How can we load-sharing it?!? Here’s the configuration example

Now it can perform Load Sharing

But here is the case I found, if the AS Path taken difference is too far between AS…the traffic load will cause some problem

Let’s see the example

Those configurations is just to simulate congestion that caused by longer AS Path the packet travels

The traffic share is still 1:1, this will cause problem with the packet that take longer path/bandwidth

So let’s configure dmzlink (for load sharing based on bandwidth)

Now the share is 1:10..1 traffic goes to R2 (bandwidth 10000) and 10 traffic goes to R3

Let’s take a look on Router CEF


eBGP Multihop

eBGP multihop typically used when, somehow, a Router can’t form eBGP peering by connecting directly

so how we configure then?…look at this topology below

ebgp multihop 1

ebgp multihop 2

why we perform static routing? because initially, eBGP peers must connect directly right?

so…they perform peering via directly connected route in their routing table

that cause us to perform static routing (or via IGP) to make the BGP packet can travel to the other peer…

ebgp multihop 3

just look at above configuration…i’m not even touching R2 (except for ip addressing though…)

the keyword is ebgp-multihop

default “hop” for BGP packet is 1…that means BGP packet TTL (time to live) is only travel to directly connected router only

but if we use multihopping, lets say 2…after 1 hop (to directly connected router), that BGP packet have life to travel “one more time”

therefore, BGP packet from R1 (or R3) can reach each other

if we use ebgp-multihop without mentioning the ttl value…default value is 255 (that BGP packet can hop 255 times)

lets verify…

ebgp multihop 4