Skip to main content

DMVPN - phase two - OSPF

In my second post about DMVPN and OSPF I would like to change my configuration from my previous post to enable direct communication between spoke routers.
I strongly recommend to read my previous post first before you start reading this one, because I’m not going to configure it from scratch.

http://myitmicroblog.blogspot.com/2014/12/dmvpn-phase-one-ospf.html

dmvpn-1-1.jpg

As you remember, traffic between R2 and R3 is sent through the hub (R1);
 
R2#traceroute 33.33.33.33 source 22.22.22.22
Type escape sequence to abort.
Tracing the route to 33.33.33.33
VRF info: (vrf in name/id, vrf out name/id)
  1 10.10.10.1 92 msec 124 msec 132 msec
  2 10.10.10.3 180 msec 156 msec 180 msec
R2#

I need to change following parameters to enable phase two (before was: ip ospf network point-to-multipoint):
 
interface Tunnel0
ip ospf network broadcast

I do the same test once again:
First I enable debug for NHRP protocol:
 
R2#debug nhrp
NHRP protocol debugging is on
R2#traceroute 33.33.33.33 source 22.22.22.22
Type escape sequence to abort.
Tracing the route to 33.33.33.33
VRF info: (vrf in name/id, vrf out name/id)
  1 10.10.10.1 192 msec 160 msec 184 msec
  2 10.10.10.3 260 msec
*Dec 22 14:02:05.106: NHRP: NHRP could not map 10.10.10.3 to NBMA, cache entry not found
*Dec 22 14:02:05.110: NHRP: MACADDR: if_in null netid-in 0 if_out Tunnel0 netid-out 12
*Dec 22 14:02:05.110: NHRP: Sending packet to NHS 10.10.10.1 on Tunnel0
*Dec 22 14:02:05.114: NHRP: Checking for delayed event NULL/10.10.10.3 on list (Tunnel0).
*Dec 22 14:02:05.118: NHRP: No node found.
*Dec 22 14:02:05.118: NHRP: Adding Tunnel Endpoints (VPN: 10.10.10.3, NBMA: 5.5.5.1)
*Dec 22 14:02:05.130: NHRP: Successfully attached NHRP subblock for Tunnel Endpoints (VPN: 10.10.10.3, NBMA: 5.5.5.1)
*Dec 22 14:02:05.134: NHRP: Enqueued NHRP Resolution Request for destination: 10.10.10.3
*Dec 22 14:02:05.154: NHRP: Checking for delayed event NULL/10.10.10.3 on list (Tunnel0).
*Dec 22 14:02:05.158: NHRP: No node found.
*Dec 22 14:02:05.162: NHRP-ATTR:  Requester Ext Len: Total ext_len  with NHRP attribute VPE 33

*Dec 22 14:02:05.166: NHRP: Sending NHRP Resolution Request for dest: 10.10.10.3 to 356 msec 224 msec
R2# nexthop: 10.10.10.1 using our src: 10.10.10.2
*Dec 22 14:02:05.166: NHRP: Attempting to send packet via DEST 10.10.10.1
*Dec 22 14:02:05.170: NHRP: Encapsulation succeeded.  Sending NHRP Control Packet  NBMA Address: 5.5.5.1
*Dec 22 14:02:05.174: NHRP: Send Resolution Request via Tunnel0 vrf 0, packet size: 85
*Dec 22 14:02:05.178:       src: 10.10.10.2, dst: 10.10.10.1
*Dec 22 14:02:05.182: NHRP: 113 bytes out Tunnel0
*Dec 22 14:02:06.514: NHRP-ATTR: ext_type: 32771, ext_len : 20

*Dec 22 14:02:06.514: NHRP-ATTR: ext_type: 32772, ext_len : 20

*Dec 22 14:02:06.518: NHRP-ATTR: ext_type: 32773, ext_len : 0

*Dec 22 14:02:06.518: NHRP-ATTR: ext_type: 32775, ext_len : 9

*Dec 22 14:02:06.522: NHRP-ATTR: ext_type: 9, ext_len : 0

*Dec 22 14:02:06.526: NHRP-ATTR: ext_type: 32768, ext_len : 0

*Dec 22 14:02:06.526: NHRP: Receive Resolution Reply via Tunnel0 vrf 0, packet size: 133
*Dec 22 14:02:06.530: NHRP: netid_in = 0, to_us = 1
*Dec 22 14:02:06.534: NHRP: nhr
R2#p_pak_reply_from_target: answer_nbma: 7.7.7.1, responder_nbma: 7.7.7.1
*Dec 22 14:02:06.534: NHRP: Tunnels gave us pak src: 7.7.7.1
*Dec 22 14:02:06.538: NHRP: Checking for delayed event NULL/10.10.10.3 on list (Tunnel0).
*Dec 22 14:02:06.542: NHRP: No node found.
*Dec 22 14:02:06.546: NHRP: >>> nhrp_need_to_delay: ENQUEUED Delaying resolution request nbma src:6.6.6.1 nbma dst:7.7.7.1 reason:IPSEC-IFC: need to wait for IPsec SAs.
*Dec 22 14:02:06.550: NHRP: Enqueueing delayed event to be processed. src:10.10.10.2 dst:10.10.10.3
*Dec 22 14:02:06.570: NHRP: Process delayed resolution request src:10.10.10.2 dst:10.10.10.3
*Dec 22 14:02:06.574: NHRP: nhrp_pak_reply_from_target: answer_nbma: 7.7.7.1, responder_nbma: 7.7.7.1
*Dec 22 14:02:06.578: NHRP: Tunnels gave us pak src: 7.7.7.1
*Dec 22 14:02:06.578: NHRP: Checking for delayed event NULL/10.10.10.3 on list (Tunnel0).
*Dec 22 14:02:06.582: NHRP: No node found.
*Dec 22 14:02:06.586: NHRP: No need to delay processing of resolu
R2#tion event nbma src:6.6.6.1 nbma dst:7.7.7.1
*Dec 22 14:02:06.590: NHRP-ATTR: In nhrp_cache_pak LINE: 1392

*Dec 22 14:02:06.594: NHRP: Adding Tunnel Endpoints (VPN: 10.10.10.3, NBMA: 7.7.7.1)
*Dec 22 14:02:06.598: NHRP: Cleanup up 0 stale cache entries
*Dec 22 14:02:06.622: NHRP: Successfully attached NHRP subblock for Tunnel Endpoints (VPN: 10.10.10.3, NBMA: 7.7.7.1)
*Dec 22 14:02:06.630: NHRP: Finding cache entry 694DDDA0 for 10.10.10.3
R2#

the most important information is this one:
 
*Dec 22 14:02:06.594: NHRP: Adding Tunnel Endpoints (VPN: 10.10.10.3, NBMA: 7.7.7.1)

Once the new entry has been added I can check once again:
 
R2#traceroute 33.33.33.33 source 22.22.22.22
Type escape sequence to abort.
Tracing the route to 33.33.33.33
VRF info: (vrf in name/id, vrf out name/id)
  1 10.10.10.3 124 msec 160 msec 144 msec
R2#

As you see now packet from 22.22.22.22 has been sent directly to the R3’s LAN (33.33.33.33)

Let’s check the nhrp mapping:
 
R2#sh ip nhrp
10.10.10.1/32 via 10.10.10.1
   Tunnel0 created 00:08:21, never expire
   Type: static, Flags: used
   NBMA address: 5.5.5.1
10.10.10.3/32 via 10.10.10.3
   Tunnel0 created 00:00:22, expire 01:59:37
   Type: dynamic, Flags: router used
   NBMA address: 7.7.7.1
R2#

and you can see two entries: one static to the hub (never expire) and dynamic one to the R3 which expires in less than 2h.

To be able to connect directly to r3 the new ISAKMP has been negotiated with the R3:
 
R2#sh crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
6.6.6.1         7.7.7.1         QM_IDLE           1013 ACTIVE
5.5.5.1         6.6.6.1         QM_IDLE           1012 ACTIVE

IPv6 Crypto ISAKMP SA

Let’s check the crypto sessions:
 
R2#sh crypto session detail
Crypto session current status

Code: C - IKE Configuration mode, D - Dead Peer Detection
K - Keepalives, N - NAT-traversal, T - cTCP encapsulation
X - IKE Extended Authentication, F - IKE Fragmentation

Interface: Tunnel0
Uptime: 00:00:45
Session status: UP-ACTIVE
Peer: 7.7.7.1 port 500 fvrf: (none) ivrf: (none)
      Phase1_id: 7.7.7.1
      Desc: (none)
  IKEv1 SA: local 6.6.6.1/500 remote 7.7.7.1/500 Active
          Capabilities:(none) connid:1013 lifetime:23:59:14
  IPSEC FLOW: permit 47 host 6.6.6.1 host 7.7.7.1
        Active SAs: 2, origin: crypto map
        Inbound:  #pkts dec'ed 5 drop 0 life (KB/Sec) 4271777/3554
        Outbound: #pkts enc'ed 3 drop 0 life (KB/Sec) 4271777/3554

Interface: Tunnel0
Uptime: 00:02:45
Session status: UP-ACTIVE
Peer: 5.5.5.1 port 500 fvrf: (none) ivrf: (none)
      Phase1_id: 5.5.5.1
      Desc: (none)
  IKEv1 SA: local 6.6.6.1/500 remote 5.5.5.1/500 Active
          Capabilities:(none) connid:1012 lifetime:23:51:15
  IPSEC FLOW: permit 47 host 6.6.6.1 host 5.5.5.1
        Active SAs: 4, origin: crypto map
        Inbound:  #pkts dec'ed 104 drop 0 life (KB/Sec) 4151957/3434
        Outbound: #pkts enc'ed 109 drop 0 life (KB/Sec) 4151957/3434

R2#
 
As you remember two entries were only on the hub (R1) and on spokes only one to the R1. In my next post I will test phase three (OSPF).
Labels:

Comments

Post a Comment

Popular posts from this blog

What should you know about HA 'override enabled' setting on Fortigate?

High availability is mandatory in most of today's network designs. Only very small companies or branches can run their business without redundancy. When you have Fortigate firewall in your network you have many options to increase network availability. You can use Fortigate Clustering Protocol ( FGCP ) or Virtual Router Redundancy Protocol ( VRRP ). FGCP has two modes: 'override' disabled (default) and 'override' enabled . I'm not going to explain how to set up HA as you can find many resources on Fortinet websites: https://cookbook.fortinet.com/high-availability-two-fortigates-56/ https://cookbook.fortinet.com/high-availability-with-fgcp-56/ Let's recap what is the main difference between them. The default HA setting is 'override' disabled and this is an order of selection an active unit: 1) number of monitored interfaces - when both units have the same number of working (up) interfaces check next parameter 2) HA uptime - an
8 comments
Read more

FortiGate and GRE tunnel

Recently I worked on one project where a client requested to re-route web traffic to the GRE tunnel to perform traffic inspection. I would like to share with you what is required if you configure it on FortiGate. We need a new GRE interface and policy base routing (PBR) to change the route for specific source IPs. Of course you need firewall policies to permit the traffic. Let's start with GRE interface. Unfortunately you can't configure it using the GUI, only CLI is the option: config system gre-tunnel edit "gre1" set interface "port1" set local-gw 55.55.55.55 set remote-gw 44.44.44.44 next end When the end peer is Cisco router, you need to set the IP for the GRE interface: config system interface edit gre1 set ip 192.168.10.10 255.255.255.255 set remote-ip192.168.10.20 end In next step we need to fix routing. We need the alternate path via GRE but to keep the route in the active routing table you need to set the same AD (adminis
Post a Comment
Read more

Inpection of asymmetric sessions on FortiGate

There is one feature available on FortiGate, and I think you should know it, as it modifies a bit what we know about stateful firewalls. In past every packet was treated individually and you had to create policies in both directions. With stateful firewalls we can track connections, and by checking couple of attributes, we can treat them as part of the same session. For example when you initiate connection from a host1 to host2, the returning connection from host2 to host1 will be treated as part of the same connection (session). They have to have the same source/destination and destination/source IPs, port numbers and interfaces.There is an exception from this rule and FortiGate in some specific cases can accept connections on port which was not used in the initial connection. Let me explain how it works on the below example:      The host1 has a default gateway on R1 (10.0.1.2), but you may notice that it is not the optimal path to host2 subnet. When we analyze the packet flo
1 comment
Read more