Tag Archives: 4.1c

4.1.c Implement and troubleshoot encapsulation

4.1.c [i] GRE

Tunneling provides a mechanism to transport packets of one protocol within another protocol, the indirection. The protocol that is carried is known as the passenger protocol, and the protocol that is used for carrying the passenger protocol is known as the transport protocol. Generic Routing Encapsulation (GRE) is one of the available tunneling mechanisms which uses IP as the transport protocol and can be used for carrying many different passenger protocols. The tunnels behave as virtual point-to-point links that have two endpoints identified by the tunnel source and tunnel destination addresses at each endpoint.

Configuring a GRE tunnel involves creating a tunnel interface, which is a logical interface. Then you must configure the tunnel endpoints for the tunnel interface.

To configure the tunnel source and destination, issue the

tunnel source {ip-address | interface-type} and tunnel destination {host-name | ip-address} commands under the interface configuration mode for the tunnel.

Adam, Paul (2014-07-12). All-in-One CCIE V5 Written Exam Guide (Kindle Locations 4443-4452).  . Kindle Edition.

http://www.cisco.com/en/US/tech/tk827/tk369/tech_configuration_examples_list.html

 

4.1.c Implement and troubleshoot encapsulation

4.1.c [ii] Dynamic GRE

NHRP is used similarly to the Address Resolution Protocol (ARP) on Ethernet, it provides the ability to map a tunnel IP address with a logical Non-Broadcast Multi-Access (NBMA) IP address; this allows multipoint (mGRE) to have dynamically set up tunnels without having to explicitly configure a mapping entry between each potential next-hop destination. Dynamic GRE is configured using the NHRP based address resolution for mGRE. Multipoint GRE can be used both at hub and at spokes. Dynamic GRE or Dynamic Multipoint VPNs (DMVPNs) can be configured with or without IPSec.

The “% TUN-5-RECURDOWN: Tunnel0 temporarily disabled” is caused due to recursive routing.The error message means that the GRE tunnel router has discovered a recursive routing problem. Tunnel interface status depends on the IP reachability to the tunnel destination. When the router detects a recursive routing failure for the tunnel destination, it shuts the tunnel interface down for a few minutes so that the situation causing the problem can resolve itself as routing protocols converge . If the problem is caused by misconfiguration, the link can oscillate indefinitely . Another symptom of this problem is continuously flapping Enhanced Interior Gateway Routing Protocol (EIGRP), Open Shortest Path First (OSPF), or Border Gateway Protocol (BGP) neighbors , when the neighbors are over a GRE tunnel.

This condition is usually due to one of these causes:

● A misconfiguration that causes the router to try to route to the tunnel destination address using the tunnel interface itself (recursive routing)

● A temporary instability caused by route flapping elsewhere in the network

Adam, Paul (2014-07-12). All-in-One CCIE V5 Written Exam Guide (Kindle Locations 4465-4470).  . Kindle Edition.

http://www.cisco.com/en/US/products/ps6604/products_white_paper09186a0080c1e9d3.shtml

4.1.c Implement and troubleshoot encapsulation

4.1.c [iii] LISP encapsulation principles supporting EIGRP OTP

EIGRP Over the Top (OTP) allows the customer to establish EIGRP adjacencies across the MPLS/ VPN provider cloud. An EIGRP targeted adjacency between CEs is created. This EIGRP neighborship is done via unicast packets, using the CE ‘WAN’ IP address. This “over the top” peering allows EIGRP to exchange customer prefixes directly between CEs. Customer prefixes are NOT injected in the providers VRF routing table. In order to allow for proper forwarding of user traffic across the MPLS/ VPN cloud , user packets are encapsulated on the CE. The encapsulation header uses the WAN IP address of the CEs, which are known in the MPLS/ VPN cloud.

Control Plane

OTP control plane consists in an EIGRP targeted adjacency between CEs.

Neighborship is established using the CE WAN address, i.e. address of CE on the PE/ CE link, so there is no need for any dynamic routing protocol between the PE/ CE. The PE just needs to redistribute the connected routes.

Data Plane

Since the customer prefixes are not known in the VRF of provider, customer traffic can’t be natively forwarded through the provider cloud, but needs to be encapsulated by CEs before being sent through the provider cloud.

OTP leverages existing LISP encapsulation which:

● Allows dynamic multi-point tunneling

● Provides instance ID field to optionally support virtualization across WAN (see EVN WAN Extension section)

OTP does not use LISP control plane (map server/ resolver, etc.) instead it uses EIGRP to exchange routes and provide the next-hop, which LISP encapsulation uses to reach remote prefixes.

Adam, Paul (2014-07-12). All-in-One CCIE V5 Written Exam Guide (Kindle Locations 4478-4488).  . Kindle Edition.

http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6554/ps6599/whitepaper_C11-730404.html

 

 

 

4.1.d Implement and troubleshoot DMVPN [single hub]

this one covers a lot of blueprint ground.

2.3b, 4.1c, 4.1d

mlppp

continuing with the earlier mlppp topology, i added dmvpn.

interface Multilink1
ip address 100.1.10.100 255.255.255.0
ip nbar protocol-discovery
ppp authentication chap
ppp multilink
ppp multilink group 1

hub#sh run int tun 0 | b inter
interface Tunnel0
ip address 10.1.1.1 255.255.255.0
no ip redirects
ip mtu 1400
ip hold-time eigrp 1 60
no ip next-hop-self eigrp 1
ip nhrp map multicast dynamic
ip nhrp network-id 1
no ip split-horizon eigrp 1
tunnel source 100.1.10.100
tunnel mode gre multipoint

hub#sh ip eigrp neigh
IP-EIGRP neighbors for process 1
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
(sec)         (ms)       Cnt Num
1   10.1.1.3                Tu0               11 00:54:30  143  5000  0  2
0   10.1.1.2                Tu0               59 00:54:34  195  5000  0  4

hub#sh ip route eigrp
2.0.0.0/24 is subnetted, 1 subnets
D       2.2.2.0 [90/297372416] via 10.1.1.2, 00:55:01, Tunnel0
100.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
D       100.1.1.10/32 [90/297756416] via 10.1.1.2, 00:55:01, Tunnel0
D       100.1.1.20/32 [90/297756416] via 10.1.1.3, 00:54:55, Tunnel0
3.0.0.0/24 is subnetted, 1 subnets
D       3.3.3.0 [90/297372416] via 10.1.1.3, 00:54:55, Tunnel0

the two spoke tunnel configs:

spoke1#sh run int tun 0 | b inter
interface Tunnel0
ip address 10.1.1.2 255.255.255.0
no ip redirects
ip mtu 1416
ip hold-time eigrp 1 60
no ip next-hop-self eigrp 1
ip nhrp map 10.1.1.1 100.1.10.100
ip nhrp map multicast 100.1.10.100
ip nhrp network-id 1
ip nhrp nhs 10.1.1.1
no ip split-horizon eigrp 1
tunnel source 100.1.20.2
tunnel mode gre multipoint

spoke2#sh run int tun 0 | b inter
interface Tunnel0
ip address 10.1.1.3 255.255.255.0
no ip redirects
ip mtu 1400
ip nhrp map multicast dynamic
ip nhrp map 10.1.1.1 100.1.10.100
ip nhrp map multicast 100.1.10.100
ip nhrp network-id 1
ip nhrp nhs 10.1.1.1
tunnel source 100.1.30.2
tunnel mode gre multipoint

spoke2#trace 10.1.1.2

Type escape sequence to abort.
Tracing the route to 10.1.1.2

1 10.1.1.2 76 msec *  48 msec

spoke1#sh ip route | b Gate
Gateway of last resort is 100.1.20.1 to network 0.0.0.0

1.0.0.0/24 is subnetted, 1 subnets
D       1.1.1.0 [90/297372416] via 10.1.1.1, 01:05:56, Tunnel0
2.0.0.0/24 is subnetted, 1 subnets
C       2.2.2.0 is directly connected, Loopback0
100.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
S       100.1.10.100/32 [1/0] via 100.1.20.1
D       100.1.1.1/32 [90/299804416] via 10.1.1.1, 01:05:56, Tunnel0
C       100.1.1.10/32 is directly connected, Serial1/0
D       100.1.10.0/24 [90/299804416] via 10.1.1.1, 01:05:56, Tunnel0
D       100.1.1.20/32 [90/310556416] via 10.1.1.3, 01:05:51, Tunnel0
C       100.1.20.0/24 is directly connected, Serial1/0
3.0.0.0/24 is subnetted, 1 subnets
D       3.3.3.0 [90/310172416] via 10.1.1.3, 01:05:51, Tunnel0
10.0.0.0/24 is subnetted, 1 subnets
C       10.1.1.0 is directly connected, Tunnel0
S*   0.0.0.0/0 [1/0] via 100.1.20.1

4.1.c Implement and troubleshoot encapsulation

right? it’s confusing…

and vpn… depends on the need or requirement… this like everything else in this journey presents subtle differences that one can miss if asleep at the wheel…

i am not going to reinvent fire…

begin here:

http://www.firewall.cx/networking-topics/protocols/127-ip-security-protocol.html

this is a great site so long as your eyes don’t start bleeding from the color scheme…

part of the difficulty is determining the requirements of the task, and interpreting them correctly because similar things can be accomplished differently… accomplishing the same thing differently leads to FAIL…

http://www.firewall.cx/networking-topics/protocols/870-ipsec-modes.html

and gre:

http://www.firewall.cx/cisco-technical-knowledgebase/cisco-routers/872-cisco-router-gre-ipsec-tunnel-transport.html