Shahed Israr is a Network Engineer specializing in GPON, FTTH, and telecom access network technologies. With hands-on experience in Huawei OLT and ONT configuration, U2000 NMS deployment, iMaster NCE-FAN Lite management systems, firmware upgrades, and advanced network troubleshooting, he helps Internet Service Providers (ISPs) and network professionals deploy, manage, and optimize fiber optic networks efficiently. Through GPON Solution, he shares practical technical guides, real-world solutions, and professional knowledge to support engineers working in modern GPON infrastructure.
BGP Weight Attribute is a Cisco Proprietary attribute that influences a router how to reach a certain prefix. The difference between Local Preference and Weight is that the former is propagated within an AS and the latter is router locally significant. Weight can be used if there is one router connected to two or more AS’s or just to just one with two or more eBGP peers. Now, lets configure weight and later use a route-map for more complex use of weight. [boxads]
Weight is a Cisco Proprietary attribute for BGP that is “locally significant.”
Local Preference is a Well-known Discretionary attribute, Weight doesn’t belong to any category.
Default Weight for locally originated routes is 32768. Zero is the default for other routes.
Weight is not propagated to other routers within the AS.
In this lab, BGP Weight Attribute will be configured and will be using route map for more flexibility. Check the diagram below for details.
In the DMVPN Overview article We explained how DMVPN combines a number of technologies that give it its flexibility, low administrative overhead and ease of configuration. This article will cover the DMVPN Configuration including Hub, Spokes, Routing and Protecting the mGRE Tunnel.[boxads]
DMVPN Configuration is simple, if you’ve worked with GRE tunnels before. If the GRE Tunnel concept is new to you, we would recommend reading through our Point-to-Point GRE IPSec Tunnel Configuration article before proceeding with DMVPN configuration.
DMVPN as a design concept is essentially the configuration combination of protected GRE Tunnel and Next Hop Routing Protocol (NHRP).
This article examines a specific DMVPN deployment architecture. Those seeking additional information on available DMVPN deplyment models can also visit my Dynamic Multipoint VPN DMVPN Architecture article.
DMVPN Operation – How DMVPN Operates:
Before diving into the configuration of our routers, we’ll briefly explain how the DMVPN is expected to work. This will help in understanding how DMVPN operates in a network:
Each spoke has a permanent IPSec tunnel to the hub but not to the other spokes within the network.
Each spoke registers as a client of the NHRP server. The Hub router undertakes the role of the NHRP server.
When a spoke needs to send a packet to a destination (private) subnet on another spoke, it queries the NHRP server for the real (outside) address of the destination (target) spoke.
After the originating spoke learns the peer address of the target spoke, it can initiate a dynamic IPSec tunnel to the target spoke.
The spoke-to-spoke tunnel is built over the multipoint GRE (mGRE) interface.
The spoke-to-spoke links are established on demand whenever there is traffic between the spokes. Thereafter, packets are able to bypass the hub and use the spoke-to-spoke tunnel.
All data traversing the GRE tunnel is encrypted using IPSecurity (optional)
Our DMVPN Network:
The diagram below depicts our DMVPN example network. Our goal is to connect the two remote networks (Remote 1 & 2) with the company headquarters. The headquarters router R1 is the central Hub router that will hold the NHRP database containing all spoke routers, their public IP addresses and LAN networks.
Dynamic Multipoint VPN (DMVPN) is the increasing demands of enterprise companies to be able to connect branch offices with head offices and between each other while keeping low costs, minimizing configuration complexity and increasing flexibility.[bodyads]
With DMVPN, one central router, usually placed at the head office, undertakes the role of the Hub while all other branch routers are Spokes that connect to the Hub router so the branch offices can access the company’s resources. DMVPN consists of two mainly deployment designs:
DMVPN Hub & Spoke, used to perform headquarters-to-branch interconnections
DMVPN Spoke-to-Spoke, used to perform branch-to-branch interconnections
In both cases, the Hub router is assigned a static public IP Address while the branch routers (spokes) can be assigned static or dynamic public IP addresses.
DMVPN Overview
DMVPN combines multiple GRE (mGRE) Tunnels, IPSec encryption and NHRP (Next Hop Resolution Protocol) to perform its job and save the administrator the need to define multiple static crypto maps and dynamic discovery of tunnel endpoints.
NHRP is layer 2 resolution protocol and cache, much like Address Resolution Protocol (ARP) or Reverse ARP (Frame Relay).
The Hub router undertakes the role of the server while the spoke routers act as the clients. The Hub maintains a special NHRP database with the public IP Addresses of all configured spokes.
There is a number of different ways an engineer can implement a DMVPN network. The fact that there is a variety of DMVPN Architecture models, each one with its caveats and requirements, means that almost any VPN requirement can be met as long as we have the correct hardware, software license and knowledge to implement it. [boxads]
Speaking of implementation, no matter how complex the DMVPN network might get, it’s pretty straight forward once it’s broken down into sections.
Engineers already working with complex DMVPNs can appreciate this and see the simplicity in configuration they offer. At the end, it’s all a matter of experience.
Providing configuration for each deployment model is out of this article’s scope, however, we will identify key services used in each deployment model along with their strong and weak points.
Future articles will cover configuration of all DMVPN Architecture deployment models presented here.
Following are the most popular DMVPN deployment models found in over 85% of DMVPN Architecture across the globe:
Single DMVPN Network/Cloud – Single Tier Headend Architecture
Single DMVPN Network/Cloud – Dual Tier Headend Architecture
Dual DMVPN Network/Cloud – Single Tier Headend Architecture
DMVPN stands for Dynamic Multipoint VPN and it is an effective solution for dynamic secure overlay networks. In short, DMVPN Configuration is combination of the following technologies: [boxads]
Assuming that reader has a general understanding of what DMVPN is and a solid understanding of IPsec/CEF, we are going to describe the role and function of each component in details. In this post we are going to illustrate two major phases of DMVPN evolution:
1) Phase 1 – Hub and Spoke (mGRE hub, p2p GRE spokes) 2) Phase 2 – Hub and Spoke with Spoke-to-Spoke tunnels (mGRE everywhere)
As for DMVPN Phase 3 – “Scalable Infrastructure”, a separate post is required to cover the subject. This is due to the significant changes made to NHRP resolution logic (NHRP redirects and shortcuts), which are better being illustrated when a reader has good understanding of first two phases. However, some hints about Phase 3 will be also provided in this post.
You may follow bellow professor jaya chandran DMVPN configuration video tutorial, for learning better.
[bodylink]
Multipoint GRE:
Let us start with the most basic building component of DMVPN Configuration – multipoint GRE tunnel. Classic GRE tunnel is point-to-point, but mGRE generalizes this idea by allowing a tunnel to have “multiple” destinations.
DMVPN point-to-point gre tunnels
This may seem natural if the tunnel destination address is multicast (e.g. 239.1.1.1). The tunnel could be used to effectively distribute the same information (e.g. video stream) to multiple destinations on top of a multicast-enabled network. Actually, this is how mGRE is used for Multicast VPN implementation in Cisco IOS. However, if tunnel endpoints need to exchange unicast packets, special “glue” is needed to map tunnel IP addresses to “physical” or “real” IP addresses, used by endpoint routers. As we’ll see later, this glue is called NHRP.
AS-path: A list of the Autonomous Systems (AS) numbers that a route passes through to reach the destination. As the update passes through an AS the AS number is inserted at the beginning of the list. The AS-path attribute has a reverse-order list of AS passed through to get to the destination.
Next-hop: The next-hop address that is used to reach the destination.
Origin: Indicates how BGP learned a particular route. There are three possible types — IGP (route is internal to the AS), EGP (learned via EBGP), or Incomplete (origin unknown or learned in a different way).
WELL-KNOWN, DISCRETIONARY
Local Preference: Defines the preferred exit point from the local AS for a specific route.
Atomic Aggregate: Set if a router advertises an aggregate causes path attribute information to be lost.
