Based on Cisco Live 2009: Advanced Concepts of DMVPN
Continuing the series of articles on VPN, I want to share the details about the implementation of DMVPN technology, outlined on Cisco Live 2009. Careful, many letters :)
I will begin according to the established tradition with the formulation of the problem .
So, we have a central office and several branches, we want to combine them into a common network using public communication channels (Internet).
Unlike the described GET VPN technology, the use of Internet channels obliges us to use tunneling (replacing the header).
What is Dynamic Multipoint VPNs (DMVPN)? In short, this is a multipoint GRE ( mGRE ) association with IPSec.
mGRE is a tunneling protocol that differs from traditional GRE by the possibility of establishing tunnels with several neighbors on the same interface. The basis is the use of Next-Hop Resolution Protocol ( NHRP ), which allows you to dynamically establish such connections. IPSec, interacting with NHRP, establishes SA as necessary and provides encryption for each separate connection.
')
It is important that while the connection topology is a classic hub-n-spoke, DMVPN allows you to dynamically establish spoke-to-spoke tunnels.
In short, the idea behind NHRP is to specify a hub or NHS (Next-Hop Server), which is static for all spoke. Each spoke is registered dynamically (i.e., NHS doesn’t know the spoke addresses initially), establishes a permanent tunnel with the NHS and the NHS makes its tunnel and real-time (mapping) addresses in the base of its neighbors, and also reports the rest, if necessary, so that could establish connections with each other directly, and not through a hub. Connections of spoke-to-spoke, unlike hub-to-spoke, are not permanent, but temporary. As soon as the traffic between branches is absent for some time, the tunnel between them is removed. This allows using weaker models as spoke routers, since they do not need to hold as many connections as there are spoke. As a hub, on the contrary, you have to choose a router strong enough to withstand the connection with all spoke.
Since each branch office reports its existence (through registration) dynamically, branch offices can be hidden behind dynamic NAT. And since Since the hub is configured statically on each branch office router, it can only be located behind static NAT.
Now we introduce the concept of phases DMVPN . Phases in this case are understood as the type (or character) of the spoke-to-spoke or spoke-to-hub interaction. There are three phases in total.
Phase 1 . Only hub-to-spoke tunnels are implemented, no spoke-to-spoke tunnels are installed and all traffic flows through the hub. In this case, it is logical to replace the next-hop routing protocols from the NHC address to the NHS address.
Registration is as follows:
Those. first an IPSec tunnel is established, then the NHC sends an NHRP registration request message.
The interval between messages is 1/3 'ip nhrp registration holdtime' or 'ip nhrp registration timeout'. If the NHS does not respond, the interval increases exponentially, starting from 1 (1, 2, 4, 8 ..., 64, ...). In this case, after the third attempt NHS will be marked as Down and will not be used. In other words, registration requests perform the keepalive function.
Each NHRP Registration message contains a matching NHC tunnel address and its real address (NBMA) and may also contain extension headers, such as authentication, NAT, etc.
The response to this message is naturally NHRP registration reply. Contains the correspondence between real and tunnel addresses of NHC and NHS, as well as all the same extension headers. In fact, it also confirms the viability of the hub.
After registering the NHC, the output of the NHRP table is as follows:
On Hub :
On Spoke 1 :
Since we have touched the mapping output, then let's discuss thetypes and flags corresponding to this mapping.
Types
Flags
After registration, route information is exchanged, in which the hub puts itself as the next-hop for each route. After that, NHC can exchange data, but through the hub.
From the advantages of this technology, it is possible to note the presence of only one tunnel on each NHC, which saves resources.
The disadvantage is obvious: routing through the hub not only loads it, but also leads to significant delays in transmission.
Phase 2 . Here we can already build spoke-to-spoke tunnels, for which the “deception” of CEF is used. All affiliates receive full routing information with unchanged next-hop (I will explain later how to do this).
NHC, receiving such a route from the NHS, places the corresponding CEF record marked “invalid” for the route, and for the next-hop address (i.e., address of another NHC), the glean record (i.e., the address L3 must be allowed to address L2). This permission is performed by the NHRP when the first packet is sent along this route.
An example of such records:
At the NHRP level, there are also three types of records corresponding to the second phase.
The first packet will be sent through the NHS using process switching. The NHC will send the NHS NHRP resolution request, to which the NHS will respond with an address that allows you to add to the CEF record.
Feature Prior to iOS 12.4.5a, the request and response ran through the entire NHS chain. After (not at 6500 and 7600), the response to NHRP resolution request was shifted to the NHC itself, whose address we are interested in. The interaction scheme of the new phase implementation is shown in the figure:
Sample output from the debug nhrp packet command for phase 2.
The presence of the src NBMA field allows the destination NHC to respond bypassing the hub.
Remarks .
Phase 3 .
In this phase, we allow the NHC to participate in the response to the NHRP resolution requests, taking this “advantage” from the NHS.
Consider the steps.
Example debazh output:
Underlined highlighted receiving NHRP redirect.
Let's summarize the third phase :
Now let's summarize the routing results , armed with phase knowledge.
Postulate 1 . NHC only establishes a routing protocol neighborhood with the NHS, and never with the NHC. NHC reports on its local networks NHS.
Postulate 2 . NHS establishes a neighborhood with all NHC. In doing so, he informs NHC about all networks learned from other NHCs and his local networks.
In addition, regardless of the phase, you need to turn off the split horizon for RIP and EIGRP.
But there is a difference in functioning, depending on the phase:
Postulate 3 . The NHS establishes a routing protocol adjacency with other NHSs. Wherein
“Now that we have reviewed the theoretical fundamentals of DMVPN operation, let's see how to configure it on Cisco routers.
The setting will differ depending on the desired phase and the role of the router (Hub or spoke).
In order:
In terms of NHRP, the hub is configured the same for Phase 1 and Phase 2. The difference will be in the configuration of the routing protocols.
Create a tunnel interface and assign it the address:
Set the source interface and mode - GRE multipoint
Then we actually set the NHRP protocol settings.
Network ID:
Optional authentication:
And we set up mapping of multicast mailings to dynamically recognizable addresses
Phase 3. It differs from Phase 2 only in its presence
Spoke .
Phase 1.
Create a tunnel interface and assign it the address:
Set the source interface
Since we plan to communicate only with the hub - we can explicitly set the destination address and the type of tunnel - the usual GRE IP (by default)
Because to register using the NHRP protocol anyway, then we set the network identifier:
Optional authentication:
And we configure the mapping of multicast mailings to the hub (attention, not tunnel, but real)
Specify the NHS tunnel address:
And we create a mapping for this tunnel address into a real one:
Phase 2.
Almost the same, just set the tunnel mode and do not specify the tunnel destination:
Phase 3. It differs from Phase 2 only in its presence
So we set up mGRE. It remains to attach IPSec to it. The setting is the same on all routers.
Create an ISAKMP policy
For ease of description, I use shared key authentication.
Turn on keepalive
Create a transform-set and bind it to the IPSec profile .
We cling a profile on the tunnel interface
Now let's talk about the routing protocol settings . For simplicity, I will limit myself to the two most common IGPs: OSPF and EIGRP, plus one of them is link-state, the other is distance-vector.
So, as we have already found out, phase 1 & 3 oblige the hub to change next-hop in the routing information to its address, therefore
OSPF:
In the case of EIGRP, the next-hop is changed by default and does not require additional efforts.
In addition, in the case of EIGRP and RIP, you need to disable the split-horizon:
Everything is simple to spoke : we configure the OSPF network type and forcibly prohibit the spoke to be DR or BDR.
OSPF:
For phase 2 a little bit different.
At the hub, we no longer need to change the next-hop, but the split horizon still hinders us. therefore
OSPF:
EIGRP:
We also set the OSPF network type as broadcast to spoke , and since we only need to have a hub neighborhood, we still forcefully forbid the spoke to be DR or BDR.
OSPF:
Let's summarize the technology.
For this, allow me to bow out :) Of course, again I do not hope that I have revealed all aspects of the technology. Behind the scenes at least left a configuration with many hubs, etc. But I hope that I managed to set out a general idea of ​​technology.
I strongly hope for constructive criticism, because The article is large and surely it is full of inaccuracies, errors and misprints.
Podkopaev Ilya, instructor
UPD. Thank you Quickshooter for the error found :)
I will begin according to the established tradition with the formulation of the problem .
So, we have a central office and several branches, we want to combine them into a common network using public communication channels (Internet).
Unlike the described GET VPN technology, the use of Internet channels obliges us to use tunneling (replacing the header).
What is Dynamic Multipoint VPNs (DMVPN)? In short, this is a multipoint GRE ( mGRE ) association with IPSec.
mGRE is a tunneling protocol that differs from traditional GRE by the possibility of establishing tunnels with several neighbors on the same interface. The basis is the use of Next-Hop Resolution Protocol ( NHRP ), which allows you to dynamically establish such connections. IPSec, interacting with NHRP, establishes SA as necessary and provides encryption for each separate connection.
')
It is important that while the connection topology is a classic hub-n-spoke, DMVPN allows you to dynamically establish spoke-to-spoke tunnels.
In short, the idea behind NHRP is to specify a hub or NHS (Next-Hop Server), which is static for all spoke. Each spoke is registered dynamically (i.e., NHS doesn’t know the spoke addresses initially), establishes a permanent tunnel with the NHS and the NHS makes its tunnel and real-time (mapping) addresses in the base of its neighbors, and also reports the rest, if necessary, so that could establish connections with each other directly, and not through a hub. Connections of spoke-to-spoke, unlike hub-to-spoke, are not permanent, but temporary. As soon as the traffic between branches is absent for some time, the tunnel between them is removed. This allows using weaker models as spoke routers, since they do not need to hold as many connections as there are spoke. As a hub, on the contrary, you have to choose a router strong enough to withstand the connection with all spoke.
Since each branch office reports its existence (through registration) dynamically, branch offices can be hidden behind dynamic NAT. And since Since the hub is configured statically on each branch office router, it can only be located behind static NAT.
Now we introduce the concept of phases DMVPN . Phases in this case are understood as the type (or character) of the spoke-to-spoke or spoke-to-hub interaction. There are three phases in total.
Phase 1 . Only hub-to-spoke tunnels are implemented, no spoke-to-spoke tunnels are installed and all traffic flows through the hub. In this case, it is logical to replace the next-hop routing protocols from the NHC address to the NHS address.
Registration is as follows:
Those. first an IPSec tunnel is established, then the NHC sends an NHRP registration request message.
The interval between messages is 1/3 'ip nhrp registration holdtime' or 'ip nhrp registration timeout'. If the NHS does not respond, the interval increases exponentially, starting from 1 (1, 2, 4, 8 ..., 64, ...). In this case, after the third attempt NHS will be marked as Down and will not be used. In other words, registration requests perform the keepalive function.
Each NHRP Registration message contains a matching NHC tunnel address and its real address (NBMA) and may also contain extension headers, such as authentication, NAT, etc.
The response to this message is naturally NHRP registration reply. Contains the correspondence between real and tunnel addresses of NHC and NHS, as well as all the same extension headers. In fact, it also confirms the viability of the hub.
After registering the NHC, the output of the NHRP table is as follows:
On Hub :
HUB#sh ip nhrp
10.1.1.2/32 via 10.1.1.2, Tunnel0 created 15:17:10, expire 01:22:43
Type: dynamic, Flags: unique registered
NBMA address: 172.16.2.1
10.1.1.3/32 via 10.1.1.3, Tunnel0 created 15:17:10, expire 01:22:43
Type: dynamic, Flags: unique registered
NBMA address: 172.16.3.1On Spoke 1 :
SPOKE1#sh ip nhrp
10.1.1.1/32 via 10.1.1.1, Tunnel0 created 15:17:45, never expire
Type: static, Flags: used
NBMA address: 172.16.1.1Since we have touched the mapping output, then let's discuss the
Types
- Static - a record for which the interface clearly defines the correspondence of the tunnel address and the real one (ip nhrp map ...)
- Dynamic is an NHRP record. There are two types:
- Incomplete - we know the tunnel address spoke, but have not yet received a response to the NHRP Resolution request.
Flags
- Unique . It means that this mapping is unique and in the case of changing the NBMA address this record will not be updated.
- Registered - obtained from NHRP Registration, usually on the hub.
- Learned - obtained from NHRP Registration, on the contrary, usually on spoke. \
- Authoritative . Can be used to respond to NHRP resolution request.
- Used . The recording was used in the previous 60 seconds.
- Router . Entries for a remote router or for networks behind it are marked with such a flag.
- Implicit The record is obtained from the source information in the NHRP packet.
- Local . Information about our local network that we gave to some other spoke in response to the NHRP request. It also stores the NBMA address of this spoke.
- NAT . (appeared in 12.4 (6) T version of IOS, not shown after 12.4 (15) T. Indicates that the remote peer supports NAT operation. After 12.4 (15) T just shows the claimed NBMA address in the record as well.
- no socket . A record for which the router does not need or does not want to establish an IPSec tunnel, because there is no traffic that needs this tunnel. If further such traffic appears, the entry will be converted to a “socket” and the IPsec tunnel will be raised. Entries like Local and implicit are always marked first as “no socket”. In addition, the NHRP by default caches source information from NHRP resolution request or reply when they pass through a router. To allow such caching, but not to raise the IPSec tunnel, they are marked as (no socket). If this is not done, unnecessary IPSec sockets from the hub to spoke will be formed, which will not be used. The data arriving at the tunnel interface and leaving it cannot use (no socket) recording, since in this case the router is an intermediate node in the path between the two interacting, and we hardly want to raise another tunnel with an intermediate point. If at some point in time the router receives a data packet that did not come from the tunnel interface and must use (nmo socket) a record, the router converts it into a (socket) record, since in this case the router will be the exit point to the tunnel for this data flow. Also, these (no socket) entries are marked as (non-authoritative), since only records obtained from NHRP registrations are marked as (authoritative).
- Negative . Indicates that the requested mapping has not yet been received. When NHRP sends the NHRP resolution request, it sets this (negative) flag to an incomplete entry, which saves the router from sending these requests multiple times, waiting for a response or establishing an IPSec connection.
After registration, route information is exchanged, in which the hub puts itself as the next-hop for each route. After that, NHC can exchange data, but through the hub.
From the advantages of this technology, it is possible to note the presence of only one tunnel on each NHC, which saves resources.
The disadvantage is obvious: routing through the hub not only loads it, but also leads to significant delays in transmission.
Phase 2 . Here we can already build spoke-to-spoke tunnels, for which the “deception” of CEF is used. All affiliates receive full routing information with unchanged next-hop (I will explain later how to do this).
NHC, receiving such a route from the NHS, places the corresponding CEF record marked “invalid” for the route, and for the next-hop address (i.e., address of another NHC), the glean record (i.e., the address L3 must be allowed to address L2). This permission is performed by the NHRP when the first packet is sent along this route.
An example of such records:
SPOKE1#sh ip cef 192.168.2.0
192.168.2.0/24, version 27, epoch 0
0 packets, 0 bytes
via 10.1.1.3, Tunnel0, 0 dependencies
next hop 10.1.1.3, Tunnel0
invalid adjacency
SPOKE1#sh ip cef 10.1.1.3
10.1.1.0/24, version 20, epoch 0, attached, connected
0 packets, 0 bytes
via Tunnel0, 0 dependencies
valid glean adjacencyAt the NHRP level, there are also three types of records corresponding to the second phase.
- Record is missing. Everything is transparent, the traffic is sent to the NHS, followed by the NHRP resolution request.
- Record type (no socket). It seems we know who to send, but not established IPSec connection. Traffic is still flying to the NHS, and a connection is being established with another NHC
- Record type (socket). Traffic flies to another NHC over an IPSec tunnel.
The first packet will be sent through the NHS using process switching. The NHC will send the NHS NHRP resolution request, to which the NHS will respond with an address that allows you to add to the CEF record.
Feature Prior to iOS 12.4.5a, the request and response ran through the entire NHS chain. After (not at 6500 and 7600), the response to NHRP resolution request was shifted to the NHC itself, whose address we are interested in. The interaction scheme of the new phase implementation is shown in the figure:
Sample output from the debug nhrp packet command for phase 2.
SPOKE1#ping 192.168.2.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/41/72 ms
SPOKE1#
*Mar 1 00:30:01.367: NHRP: Send Resolution Request via Tunnel0 vrf 0, packet size: 81
*Mar 1 00:30:01.367: src: 10.1.1.2, dst: 10.1.1.3
*Mar 1 00:30:01.371: (F) afn: IPv4(1), type: IP(800), hop: 255, ver: 1
*Mar 1 00:30:01.371: shtl: 4(NSAP), sstl: 0(NSAP)
*Mar 1 00:30:01.371: (M) flags: "router auth src-stable", reqid: 4
*Mar 1 00:30:01.371: src NBMA: 172.16.2.1
*Mar 1 00:30:01.371: src protocol: 10.1.1.2, dst protocol: 10.1.1.3
*Mar 1 00:30:01.375: (C-1) code: no error(0)
*Mar 1 00:30:01.375: prefix: 0, mtu: 1514, hd_time: 7200
*Mar 1 00:30:01.375: addr_len: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0, pref: 0
*Mar 1 00:30:01.375: NHRP: Send Resolution Request via Tunnel0 vrf 0, packet size: 81
*Mar 1 00:30:01.379: src: 10.1.1.2, dst: 10.1.1.1
*Mar 1 00:30:01.379: (F) afn: IPv4(1), type: IP(800), hop: 255, ver: 1
*Mar 1 00:30:01.379: shtl: 4(NSAP), sstl: 0(NSAP)
*Mar 1 00:30:01.383: (M) flags: "router auth src-stable", reqid: 4
*Mar 1 00:30:01.383: src NBMA: 172.16.2.1
*Mar 1 00:30:01.383: src protocol: 10.1.1.2, dst protocol: 10.1.1.3
*Mar 1 00:30:01.383: (C-1) code: no error(0)
*Mar 1 00:30:01.387: prefix: 0, mtu: 1514, hd_time: 7200
*Mar 1 00:30:01.387: addr_len: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0, pref: 0
*Mar 1 00:30:01.415: NHRP: Receive Resolution Reply via Tunnel0 vrf 0, packet size: 109
*Mar 1 00:30:01.415: (F) afn: IPv4(1), type: IP(800), hop: 255, ver: 1
*Mar 1 00:30:01.415: shtl: 4(NSAP), sstl: 0(NSAP)
*Mar 1 00:30:01.415: (M) flags: "router auth dst-stable unique src-stable", reqid: 4
*Mar 1 00:30:01.419: src NBMA: 172.16.2.1
*Mar 1 00:30:01.419: src protocol: 10.1.1.2, dst protocol: 10.1.1.3
*Mar 1 00:30:01.419: (C-1) code: no error(0)
*Mar 1 00:30:01.423: prefix: 32, mtu: 1514, hd_time: 6089
*Mar 1 00:30:01.423: addr_len: 4(NSAP), subaddr_len: 0(NSAP), proto_len: 4, pref: 0
*Mar 1 00:30:01.423: client NBMA: 172.16.3.1
*Mar 1 00:30:01.423: client protocol: 10.1.1.3The presence of the src NBMA field allows the destination NHC to respond bypassing the hub.
Remarks .
- Saving the next-hop address at first glance looks like a logical and correct solution. But it has one drawback: each NHC must receive the entire routing table from the NHS, without using summaries. This allows you to use only one level of NHS, i.e. we can serve half NHC with one NHS, the other half with another, but we are obliged to connect them as NHS for each other. This is necessary in order to allow the NHRP resolution request to pass all potential NHS. And their static indication reduces overall reliability.
- Well and besides, the first packet will be sent not through CEF, but through process switching.
Phase 3 .
In this phase, we allow the NHC to participate in the response to the NHRP resolution requests, taking this “advantage” from the NHS.
Consider the steps.
- NHC is traditionally registered on the NHS, which allows the latter to establish a routing protocol neighborhood with the NHC and exchange routing information. At the same time, the NHS is not obliged to keep the route information in its original form: it can change the next-hop for itself and even its summatization. Moreover, the more general route we send back to NHC, the easier it will be :)
- NHC receives the routing information and populates the CEF table. Since we now have the next-hop NHS itself, we will not have “invalid” or “glean” entries. In other words, the first packet along this route will be sent using CEF ... where ??? ... right, to the hub! But this, among other things, means that the absence of "incorrect" entries in CEF will not cause NHRP resolution requests! And here NHRP redirect message !
- Step 3 - a direct continuation of the second. So, the first packet sent from spoke to another spoke goes through the NHS. When the NHS receives a packet via the mGRE tunnel, and then is forced to send it back over the same interface (but to another NHC), the NHS sends the source of this packet to the main third-party feature, the NHRP redirect message. This message tells NHC that it is using a “not quite right” :) route in packet routing. And it “hints” that it would be good to use NHRP resolution to refine the path of the NHC. The first packet itself is however sent to the NHS at.
- Again we continue. Now the NHC that sent the first packet receives a redirect message containing the destination address of that very first packet. This NHC sends the NHRP resolution request about the same IP, but (attention !!!) not to the NHS, but again at the same address ! Those. NHC asks another NHC for its real address. Once again: the destination address in the NHRP resolution request is not the NHS, but the NHC we are interested in, although we (like the first packet) will get to it via the NHS. NHS will send it in the same way as intended (i.e. again the packet will go through the hub, non-optimally).
- Decoupling :) Now our destination NHC (and not NHS !!) responds to the resolution request. Using the real address attached to the request, this NHC will respond to the sender directly, bypassing the NHS. In this case, the answer will contain the entire network (route, prefix) found in the RIB, and not just the requested address. When our NHC sender of the request receives such a response, it will know the real next-hop of such an address, fill in the NHRP table, and correct the entry in CEF (or create a new one).
Example debazh output:
SPOKE2#ping 192.168.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/51/84 ms
SPOKE2#
*Mar 1 00:07:57.151: NHRP: Receive Traffic Indication via Tunnel0 vrf 0, packet size: 97
*Mar 1 00:07:57.155: (F) afn: IPv4(1), type: IP(800), hop: 255, ver: 1
*Mar 1 00:07:57.155: shtl: 4(NSAP), sstl: 0(NSAP)
*Mar 1 00:07:57.159: (M) traffic code: redirect(0)
*Mar 1 00:07:57.159: src NBMA: 172.16.1.1
*Mar 1 00:07:57.159: src protocol: 10.1.1.1, dst protocol: 10.1.1.3
*Mar 1 00:07:57.163: Contents of nhrp traffic indication packet:
*Mar 1 00:07:57.167: 45 00 00 64 00 00 00 00 FE 01 EF EB 0A 01 01 03
*Mar 1 00:07:57.171: C0 A8 01 01 08 00 36 7F 00 00 00
*Mar 1 00:07:57.211: NHRP: Send Resolution Request via Tunnel0 vrf 0, packet size: 85
*Mar 1 00:07:57.215: src: 10.1.1.3, dst: 192.168.1.1
*Mar 1 00:07:57.219: (F) afn: IPv4(1), type: IP(800), hop: 255, ver: 1
*Mar 1 00:07:57.219: shtl: 4(NSAP), sstl: 0(NSAP)
*Mar 1 00:07:57.219: (M) flags: "router auth src-stable nat ", reqid: 5
*Mar 1 00:07:57.219: src NBMA: 172.16.3.1
*Mar 1 00:07:57.219: src protocol: 10.1.1.3, dst protocol: 192.168.1.1
*Mar 1 00:07:57.219: (C-1) code: no error(0)
*Mar 1 00:07:57.219: prefix: 0, mtu: 1514, hd_time: 7200
*Mar 1 00:07:57.219: addr_len: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0, pref: 0
*Mar 1 00:07:57.247: NHRP: Receive Resolution Request via Tunnel0 vrf 0, packet size: 105
*Mar 1 00:07:57.251: (F) afn: IPv4(1), type: IP(800), hop: 254, ver: 1
*Mar 1 00:07:57.251: shtl: 4(NSAP), sstl: 0(NSAP)
*Mar 1 00:07:57.255: (M) flags: "router auth src-stable nat ", reqid: 6
*Mar 1 00:07:57.255: src NBMA: 172.16.2.1
*Mar 1 00:07:57.259: src protocol: 10.1.1.2, dst protocol: 10.1.1.3
*Mar 1 00:07:57.263: (C-1) code: no error(0)
*Mar 1 00:07:57.263: prefix: 0, mtu: 1514, hd_time: 7200
*Mar 1 00:07:57.263: addr_len: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0, pref: 0
*Mar 1 00:07:57.271: NHRP: Send Resolution Reply via Tunnel0 vrf 0, packet size: 133
*Mar 1 00:07:57.275: src: 10.1.1.3, dst: 10.1.1.2
*Mar 1 00:07:57.279: (F) afn: IPv4(1), type: IP(800), hop: 255, ver: 1
*Mar 1 00:07:57.279: shtl: 4(NSAP), sstl: 0(NSAP)
*Mar 1 00:07:57.283: (M) flags: "router auth dst-stable unique src-stable nat ", reqid: 6
*Mar 1 00:07:57.283: src NBMA: 172.16.2.1
*Mar 1 00:07:57.287: src protocol: 10.1.1.2, dst protocol: 10.1.1.3
*Mar 1 00:07:57.291: (C-1) code: no error(0)
*Mar 1 00:07:57.291: prefix: 32, mtu: 1514, hd_time: 7200
*Mar 1 00:07:57.295: addr_len: 4(NSAP), subaddr_len: 0(NSAP), proto_len: 4, pref: 0
*Mar 1 00:07:57.299: client NBMA: 172.16.3.1
*Mar 1 00:07:57.299: client protocol: 10.1.1.3
*Mar 1 00:07:57.323: NHRP: Receive Resolution Reply via Tunnel0 vrf 0, packet size: 153
*Mar 1 00:07:57.331: (F) afn: IPv4(1), type: IP(800), hop: 254, ver: 1
*Mar 1 00:07:57.331: shtl: 4(NSAP), sstl: 0(NSAP)
*Mar 1 00:07:57.331: (M) flags: "router auth dst-stable unique src-stable nat ", reqid: 5
*Mar 1 00:07:57.335: src NBMA: 172.16.3.1
*Mar 1 00:07:57.339: src protocol: 10.1.1.3, dst protocol: 192.168.1.1
*Mar 1 00:07:57.343: (C-1) code: no error(0)
*Mar 1 00:07:57.343: prefix: 24, mtu: 1514, hd_time: 7200
*Mar 1 00:07:57.343: addr_len: 4(NSAP), subaddr_len: 0(NSAP), proto_len: 4, pref: 0
*Mar 1 00:07:57.347: client NBMA: 172.16.2.1
*Mar 1 00:07:57.347: client protocol: 10.1.1.2Underlined highlighted receiving NHRP redirect.
Let's summarize the third phase :
- No invalid entries in CEF. All packets use CEF, and NHRP requests are now called not by an incorrect entry in CEF, but by an explicit indication from the NHS.
- NHS is no longer the only source of NHRP information. The rest of the NHC was also involved. More like peer2peer.
- NHRP replies from NHC contains a whole prefix, not just next-hop. This, by the way, allows us to send a general route from the NHS to the NHC, since The destination NHC will return the prefix that belongs to it, which may be more particular than the one originally received from the NHS.
- The initial packets run through the hub.
- Since the answer is not NHS, but NHC, there may be several levels of hubs in the topology.
Now let's summarize the routing results , armed with phase knowledge.
Postulate 1 . NHC only establishes a routing protocol neighborhood with the NHS, and never with the NHC. NHC reports on its local networks NHS.
Postulate 2 . NHS establishes a neighborhood with all NHC. In doing so, he informs NHC about all networks learned from other NHCs and his local networks.
In addition, regardless of the phase, you need to turn off the split horizon for RIP and EIGRP.
But there is a difference in functioning, depending on the phase:
- In phase 1 and phase 3, the hub cannot save the next-hop in the routing information (for example, BGP next-hop-self, OSPF network point-to-multipoint), due to this it is possible to use summatization. In addition, the number of hubs is not limited and they are not required to be the same level.
- In phase 2, on the contrary, the hub is obliged to save next-hop in the routing information (EIGRP no ip next-hop-self , BGP default, OSPF network broadcast), it is possible to use no more than two hubs.
Postulate 3 . The NHS establishes a routing protocol adjacency with other NHSs. Wherein
- In phase 1 and phase 3, the routing protocol between hubs may differ from the routing protocol between hubs and NHC.
- In phase 2, hubs are required to use the same protocol.
“Now that we have reviewed the theoretical fundamentals of DMVPN operation, let's see how to configure it on Cisco routers.
The setting will differ depending on the desired phase and the role of the router (Hub or spoke).
In order:
In terms of NHRP, the hub is configured the same for Phase 1 and Phase 2. The difference will be in the configuration of the routing protocols.
Create a tunnel interface and assign it the address:
Hub(config)# interface Tunnel0
Hub(config-if)# ip address 10.1.1.1 255.255.255.0Set the source interface and mode - GRE multipoint
Hub(config-if)# tunnel source FastEthernet0/0
Hub(config-if)# tunnel mode gre multipointThen we actually set the NHRP protocol settings.
Network ID:
Hub(config-if)# ip nhrp network-id 123Optional authentication:
Hub(config-if)# ip nhrp authentication ciscoAnd we set up mapping of multicast mailings to dynamically recognizable addresses
Hub(config-if)# ip nhrp map multicast dynamicPhase 3. It differs from Phase 2 only in its presence
Hub(config-if)# ip nhrp redirectSpoke .
Phase 1.
Create a tunnel interface and assign it the address:
Spoke1(config)# interface Tunnel0
Spoke1(config-if)# ip address 10.1.1.2 255.255.255.0Set the source interface
Spoke1(config-if)# tunnel source FastEthernet0/0Since we plan to communicate only with the hub - we can explicitly set the destination address and the type of tunnel - the usual GRE IP (by default)
Spoke1(config-if)# tunnel destination 172.16.1.1Because to register using the NHRP protocol anyway, then we set the network identifier:
Spoke1(config-if)# ip nhrp network-id 123Optional authentication:
Spoke1(config-if)# ip nhrp authentication ciscoAnd we configure the mapping of multicast mailings to the hub (attention, not tunnel, but real)
Spoke1(config-if)# ip nhrp map multicast 172.16.1.1Specify the NHS tunnel address:
Spoke1(config-if)# ip nhrp nhs 10.1.1.1And we create a mapping for this tunnel address into a real one:
Spoke1(config-if)# ip nhrp map 10.1.1.1 172.16.1.1Phase 2.
Almost the same, just set the tunnel mode and do not specify the tunnel destination:
Spoke1(config)# interface Tunnel0
Spoke1(config-if)# ip address 10.1.1.2 255.255.255.0
Spoke1(config-if)# tunnel source FastEthernet0/0
Spoke1(config-if)# tunnel mode gre multipoint
Spoke1(config-if)# ip nhrp network-id 123
Spoke1(config-if)# ip nhrp authentication cisco
Spoke1(config-if)# ip nhrp map multicast 172.16.1.1
Spoke1(config-if)# ip nhrp nhs 10.1.1.1
Spoke1(config-if)# ip nhrp map 10.1.1.1 172.16.1.1Phase 3. It differs from Phase 2 only in its presence
Spoke1(config-if)# ip nhrp shortcut
Spoke1(config-if)# ip nhrp redirectSo we set up mGRE. It remains to attach IPSec to it. The setting is the same on all routers.
Create an ISAKMP policy
Router(config)#crypto isakmp policy 10
Router(config-isakmp)# encr aes
Router(config-isakmp)# authentication pre-share
Router(config-isakmp)# group 2For ease of description, I use shared key authentication.
Router(config-isakmp)#crypto isakmp key cisco address 0.0.0.0 0.0.0.0Turn on keepalive
Router(config)#crypto isakmp keepalive 10 3 periodicCreate a transform-set and bind it to the IPSec profile .
Router(config)#crypto ipsec transform-set IPSEC_SET esp-aes esp-sha-hmac
Router(cfg-crypto-trans)#crypto ipsec profile IPSEC_PROFILE
Router(ipsec-profile)# set transform-set IPSEC_SETWe cling a profile on the tunnel interface
Router(config)#interface tunnel 0
Router(config-if)#tunnel protection ipsec profile IPSEC_PROFILENow let's talk about the routing protocol settings . For simplicity, I will limit myself to the two most common IGPs: OSPF and EIGRP, plus one of them is link-state, the other is distance-vector.
So, as we have already found out, phase 1 & 3 oblige the hub to change next-hop in the routing information to its address, therefore
OSPF:
Hub(config-if)# ip ospf network point-to-multipointIn the case of EIGRP, the next-hop is changed by default and does not require additional efforts.
In addition, in the case of EIGRP and RIP, you need to disable the split-horizon:
Hub(config-if)#no ip split-horizon eigrp AS_NUMBEREverything is simple to spoke : we configure the OSPF network type and forcibly prohibit the spoke to be DR or BDR.
OSPF:
Spoke(config-if)# ip ospf network point-to-multipoint
Spoke(config-if)# ip ospf priority 0 Spoke(config-if)# ip ospf network point-to-multipoint
Spoke(config-if)# ip ospf priority 0For phase 2 a little bit different.
At the hub, we no longer need to change the next-hop, but the split horizon still hinders us. therefore
OSPF:
Hub(config-if)# ip ospf network broadcast (timers to taste)EIGRP:
Hub(config-if)#no ip next-hop-self eigrp AS_NUMBER
Hub(config-if)#no ip split-horizon eigrp AS_NUMBER Hub(config-if)#no ip next-hop-self eigrp AS_NUMBER
Hub(config-if)#no ip split-horizon eigrp AS_NUMBERWe also set the OSPF network type as broadcast to spoke , and since we only need to have a hub neighborhood, we still forcefully forbid the spoke to be DR or BDR.
OSPF:
Spoke(config-if)# ip ospf network broadcast
Spoke(config-if)# ip ospf priority 0 Spoke(config-if)# ip ospf network broadcast
Spoke(config-if)# ip ospf priority 0Let's summarize the technology.
- DMVPN is a technology that allows you to build a VPN with multiple participants. The basic topology is hub-n-spoke, but it is possible to dynamically establish spoke-to-spoke tunnels and even a hierarchy of hubs.
- The basis is mGRE (and it is based on NHRP), and the protection is assigned to IPSec, which interacts closely with it.
- The load on the hub is generally greater than the spoke. This allows the use of equipment that varies in performance, depending on the needs of a particular branch office.
- The nature of the work depends on the configured phase.
- The configuration of the routing protocols also requires care.
- Among the shortcomings I would like to point out the limited support for multicasts and the lack of support for the Cisco ASA (sob ...)
For this, allow me to bow out :) Of course, again I do not hope that I have revealed all aspects of the technology. Behind the scenes at least left a configuration with many hubs, etc. But I hope that I managed to set out a general idea of ​​technology.
I strongly hope for constructive criticism, because The article is large and surely it is full of inaccuracies, errors and misprints.
Podkopaev Ilya, instructor
UPD. Thank you Quickshooter for the error found :)
Source: https://habr.com/ru/post/84738/
All Articles