IPv6 NAT-PT

In the recent posts, we discussed how we can transport IPv6 traffic over IPv4 backbone using the tunneling techniques. 

These techniques will not work if we have one part of network which can only run IPv4 and the other part can only run IPv6. Since IPv4 and IPv6 are not compatible with each other, we have to use some sort of translation mechanism. The way we can achieve this is through NAT-PT (NAT protocol translation).

Let's look at the below topology and see how NAT-PT can be implemented.

We have three routers R1, R2 and R3. We are running RIPng and RIPv2 between R1-R2 and R2-R3 respectively. R1 is only aware about IPv6 addresses, similarly R3 is only aware about IPv4 addresses.

Our goal is to establish reachability between the IPv6 loopback (2001:1111::1/128) of R1 to IPv4 loopback (3.3.3.3/32) of R3.

IPv6 tunneling over IPv4 - 6to4 Autotunnel

In the previous post, we looked at the IPv6 tunneling technique using IPv4 manual tunnels. We will now see how dynamic multipoint IPv6 tunnel works.

6to4 tunnels allow for the dynamic creation of IPv6 within IPv4 tunnels. Manual tunnel is normally used as point-to-point however 6to4 tunnels can be point-to-multipoint.

The 2002::/16 range has been reserved to use for tunneling. We will have to add the IPv4 address into this range to generate /48 prefix. i.e. if the IPv4 address of the border router is 192.168.1.1 then the 6to4 site address prefix becomes 2002:C0A8:101::/48 (Convert 192.168.1.1 to Hex which results in C0A8:0101)

We will work on the same topology we used in the previous post.

IPv6 tunneling over IPv4 - Manual Tunnel

We know that IPv4 and IPv6 addresses are not compatible with each other. Let's say the existing infrastructure is running on IPv4. If we need to implement IPv6 on few of the hosts, we need to use some sort of a technique for IPv6 hosts to communicate with each other using existing IPv4 network. One of the ways we can achieve this is by using a tunneling method.

In this post we will see how we can implement "Manual Tunnel". 

As shown in the diagram below, we have R1, R2 and R3 connected with each other. 

All three routers are running EIGRP and there is an IPv4 reachability from R1 to R3.

BFD (Bidirectional Forwarding Detection)

In this post, we will look into a feature called BFD (bidirectional forwarding detection). In normal routing protocol operation, the link failure is detected by using the hello/holddown/dead timers. 

Depending on the routing protocol, you can lower the timers to achieve fast failure detection. e.g. in the case of OSPF the lowest dead time can be one second and one can set the hello interval as low as 50ms.

However lowering these timers can result in higher CPU utilization. Also it will unnecessarily waste the link bandwidth. 

There is a better way of achieving fast failure detection through BFD. BFD is a UDP-based protocol that provides fast (in milliseconds) routing protocol independent detection of layer-3 next hop failures.

Let's see how it works. As shown in the diagram below, routers R1 and R2 are connected via Switch 1 and Switch 2. Both the routers are running OSPF and we can see the OSPF neighbourship is up.

Multicast Notes

Well Known Multicast Addresses

224.0.0.1 - All Hosts
224.0.0.2 - All Multicast Routers
224.0.0.9 - RIPv2 Routers
224.0.0.10 - EIGRP Routers
224.0.0.12 - HSRPv2
224.0.0.13 - PIM Routers
224.0.0.22 - IGMPv3
224.0.1.1 - NTP
224.0.1.39 - Cisco-RendezvousPoint-Announce
224.0.1.40 - Cisco-RendezvousPoint-Discovery
232.0.0.0/8 - Reserved for SSM
233.0.0.0/8 - GLOP address range

PIM (Protocol Independent Multicast)

• Protocol independent means that it can work with any unicast routing protocol 
• Pim can be implemented in three modes: sparse mode, dense mode and sparse-dense mode.

Layer 2 MPLS VPN (AToM)

In the previous post, we have seen the configuration of Layer 3 VPN. here we will see how we can configure Layer 2 VPN. 

Layer 3 VPN requires the PE participating in the CE routing. Sometimes PE cannot support specific routing protocol as required by the customer or the CE devices may not be IP aware.

Also customer will have to involve the service provider if they want to do any routing changes.

Layer 2 VPN resolves this issue by providing a layer 2 connectivity between CEs, effectively providing a broadcast domain. Customer can run any routing protocol between the CEs and will be in full control of the routing.

Generally it's done by using AToM (Any transport over MPLS) or L2TPV3 (Layer 2 tunnelling protocol). 

The key difference between both the methods is that AToM uses the MPLS as the transport while L2TPV3 uses IP. 

Let's look at the below scenario and see how we can implement this. We will use AToM in our example.

6VPE

6VPE (IPv6 VPN Provider Edge Router) is a feature which connects the customer sites configured with IPv6 addressing over the existing IPv4 MPLS backbone.

In our last post, we have seen how we can configure standard Layer 3 MPLS connection on Cisco routers and advertise customer's IPv4 prefixes over that. 

We will use the same topology for 6VPE however we will configure IPv6 addresses between PE to CE (R1-R2 and R5-R6) and on the Loopbacks of the CEs (R1 and R6).

This is how our topology looks like

Layer 3 MPLS VPN

In this post we will look at the steps of configuring Layer 3 MPLS VPN on Cisco routers.

As shown in the diagram, R1 and R6 are CE routers. R2 and R5 are PEs while R3 and R4 are P routers.

DMVPN Phase 3

DMVPN Phase 2 and Phase 3 are identical however in Phase 3, there is no need for the command "no ip next-hop-sef eigrp 10". 

To implement Phase 3, we will have to configure one additional command "ip nhrp redirect" on the hub and one additional command on the spokes ""ip nhrp shortcut". 

The idea here is that when a spoke try to send packets to another spoke, the initial packet will be forwarded to the hub. Upon receiving the packet on mGRE interface, hub will reply back with an "NHRP Redirect" packet which will indicate that the spoke is not using an optimal path and it should look for alternate way by using NHRP reosolution.

The spoke will then sends an NHRP request directly to the destination spoke address (not the hub). The destination spoke will reply abck with the IP routing prefix. When the source spoke receives this reply, it will then know the NBMA IP address of the destination.

DMVPN Phase 2

Continuing from the previous post, let's now see how phase 2 works. 

The major difference between phase 1 and phase 2 is that in phase 2, the spokes can communicate to other spokes directly by using the NHRP mapping information from the hub.

To enable the spoke to create dynamic tunnels, we will remove the tunnel destination command and change the tunnel mode to "gre multipoint".

At the moment, we can see that R2 is learning the loopback of R3 with the next hop 10.1.1.1 (hub's tunnel IP).