Archives for posts with tag: EIGRP

Dynamic Virtual Tunnel Interface.

It’s a similar concept to DMVPN but with a few differences

  • dVTI requires a smaller packet header only 4 bytes compared to DMVPN which is an additional 28 bytes
  • dVTI does not  use NHRP
  • dVTI has backwards compatibility with IPsec direct encapsulation
  • dVTI requires IP unumbered
  • dVTI requires the use of a dynamic routing protocol instead of keepalives
  • dVTI must be initiated by the remote branch to the head-end

I personally like the fact that the interface is unnumbered as it reduces the amount of IP address space that you need to manage. Each virtual template can be configured with different characteristics on the head-end device so that common branch offices share the same settings. This type of solution is ideal for a hub and spoke design.

I’m not saying dVTI is better or worse than DMVPN it’s just different.

The spoke forms an EIGRP neighbor with the HUB, you can then advertise a default route to the spoke. If you want to apply policies like QoS you can do this directly on the template interface.  The spoke will advertise the LAN network to the Hub and you can then summarise at the Hub into the data centre for multiple spokes.

Here is the configuration with a front VRF, this was tested in the lab on live equipment.

Hub Configuration

vrf definition internet
 rd 1:1
 address-family ipv4
 
 crypto keyring KEYRING vrf internet 
  pre-shared-key address [IP ADDRESS of SPOKE or match all] key cisco
 
 crypto isakmp policy 10
  encr aes
  hash sha256
  authentication pre-share
  group 14

crypto isakmp profile ISAKMPPROFILE
  keyring KEYRING
  match identity address [IP ADDRESS of SPOKE or match all] internet
  virtual-template 1

crypto ipsec transform-set TSET_SECURE esp-aes esp-sha256-hmac

interface Loopback0
  ip address 172.16.255.1 255.255.255.255
 
 interface gig0/0
  vrf forwarding internet
  description outside_interface
  ip address [WAN Interface IP and Subnet Mask] 
  no ip redirects
  no ip unreachables
  no ip proxy-arp

interface gig0/1
  description inside_interface
  ip address 192.168.255.50 255.255.255.0
  

interface Virtual-Template1 type tunnel
  ip unnumbered Loopback0
  ip mtu 1408
  ip summary-address eigrp 1 0.0.0.0 0.0.0.0
  tunnel mode ipsec ipv4
  tunnel vrf internet
  tunnel protection ipsec profile IPSECPROFILE_SECURE

router eigrp 1
  network 172.16.255.1 0.0.0.0

ip route vrf internet 0.0.0.0 0.0.0.0 [next-hop to internet]

Spoke Configuration

vrf definition internet
 rd 1:1
  address-family ipv4

crypto keyring 1 vrf internet 
  pre-shared-key address [IP address of HUB] cisco

crypto isakmp policy 10
  encr aes
  hash sha256
  authentication pre-share
  group 14

crypto ipsec transform-set TSET_SECURE esp-aes esp-sha256-hmac

crypto ipsec profile IPSECPROFILE_SECURE
  set transform-set TSET_SECURE

interface Loopback0
 ip address 172.16.255.2 255.255.255.255
 
 interface Tunnel0
  ip unnumbered Loopback0
  ip mtu 1408
  tunnel source gig0/1
  tunnel mode ipsec ipv4
  tunnel destination [IP address of HUB]
  tunnel vrf internet
  tunnel protection ipsec profile IPSECPROFILE_SECURE

interface gig0/1
  description outside_interface
  vrf forwarding internet
  ip address [WAN Interface IP and Subnet Mask or DHCP]

interface vlan 1 
  description inside_interface
  ip address 172.16.1.1 255.255.255.252
  no shut

router eigrp 1
  network 172.168.255.2 0.0.0.0
  network 172.16.1.1 0.0.0.0
  eigrp stub connected summary

To verify you can use commands like below.

“show ip int brief”
“show ip interface virtual-access1”
“show ip eigrp neighbors”
“show crypto isakmp sa”
“show crypto engine connections active”

Update: You might notice I have used classic EIGRP instead of EIGRP named mode, the reason was due to the fact that under the af-interface virtua- template I wasn’t able to set the summary route, the command was accepted but wasn’t being sent to the neighbor. Perhaps this is a bug in the version I was running.

 

Advertisements

This lab is setup for static Rendezvous Point, you may use this in a small environment with only one or two multicast sources, static RP is managed by manually configuring each router with “ip pim rp-address x.x.x.x”. As you can probably tell manually updating each router with a new RP could be time conusming on larger networks,  so we will cover other ways to assign or elect the RP in my future blogs.

Static RP topology

Static RP topology

Attached are the config’s for each router (Router Configs). As I’m using GNS3 I had to enter commands “no ip route-cache” and “no ip mroute-cache” on each PIM interface. Also add “no ip cef”. You won’t need this for physical routers.

Now lets confirm our configurations with some well known commands.

From R4 we need to confirm the IGMP memberships “show ip igmp groups” will show all the IGMP joins the router has recieved from hosts wanting to join the multicast stream.

R4#sh ip igmp groups
IGMP Connected Group Membership
Group Address    Interface                Uptime    Expires   Last Reporter   Group Accounted
239.4.4.4        FastEthernet0/0          00:21:26  stopped   10.10.10.4

Next we confirm the RP with the command  ” show ip pim rp” lets do this from R2, this will show us all RP’s and the multicast group address they are responsible for.

R2#sh ip pim rp
Group: 239.4.4.4, RP: 10.10.10.3, v2, uptime 00:03:55, expires never
Group: 224.0.1.40, RP: 10.10.10.3, v2, uptime 00:24:12, expires never

Next from R1 we initate some traffic using “ping 239.4.4.4” you should get a reply, now we can run the command from R2 “show ip mroute summary”. This will show us the shared tree and source tree for the multicast source.

R2#sh ip mroute summary
IP Multicast Routing Table
(*, 239.4.4.4), 00:02:47/stopped, RP 10.10.10.3, OIF count: 0, flags: SPF
(56.56.56.1, 239.4.4.4), 00:02:47/00:00:46, OIF count: 1, flags: FT

This confirms our multicast setup is working correctly.

If you are struggling with source and shared tree check out this blog (http://packetlife.net/blog/2008/oct/20/pim-sm-source-versus-shared-trees)

RH