Static Point-to-Point IPv6 Tunnels ccnp training center in delhi gurgaon

Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192


This section examines the configuration and some basic verification for two different
types of IPv6 point-to-point tunnels:
■ Manually configured tunnels (MCT)
■ Generic Routing Encapsulation (GRE) tunnels
Note: The phrase manually configured tunnels refers to an RFC standard encapsulation
of IPv6 inside IPv4 packets. There is no formal name for this feature, so most documents
refer to it as “manually configured tunnels,” “manual tunnels,” or “configured tunnels.” This
chapter uses the term manually configured tunnels (MCT) for consistency and easier reference.
MCT and GRE tunnels have many similarities, including the configuration. They both create
a virtual point-to-point link between two IPv4 routers for the purpose of supporting
the forwarding of IPv6 packets. IPv6 IGP routing protocols can run over these virtual links.
To support the IGPs, plus other features, the routers will assign link local addresses on
these links and allow the forwarding of IPv6 multicast traffic. Both types allow the configuration
of additional security features over the tunnel interfaces. Finally, both require static
configuration of both the tunnel source and the tunnel destination IPv4 addresses.
To the depth used for these topics in this book, these two tunneling options have only minor
differences. Manually configured tunnels simply conform to the rules about generic
IPv6 tunnels outlined in RFC 4213, which defines how to encapsulate IPv6 inside an IPv4
packet, without additional headers. GRE tunnels use a generic encapsulation originally defined
by Cisco and later standardized in RFC 2784. GRE uses an additional stub header
www.CareerCert.info
620 CCNP ROUTE 642-902 Official Certification Guide
between the IPv4 and IPv6 header; this extra header includes a protocol type field, which
allows a GRE tunnel to carry many passenger protocols. (The passenger protocol is the
protocol encapsulated inside another protocol’s header.) GRE also supports several transport
protocols (transport protocols encapsulate the passenger protocol), although IPv4
typically is the only transport protocol used for tunneling IPv6. GRE’s flexibility allows a
single GRE tunnel to carry IPv6 plus other traffic as well, whereas manually configured
tunnels cannot.
This section examines manually configured tunnels in detail and then compares GRE tunnels
to manually configured tunnels.
Manually Configured Tunnels
The main planning task for an implementation plan that includes manually configured tunnels
requires a little thought about the tunnel source and destination IPv4 addresses.
Other than that, the configuration uses straightforward commands that refer to the key elements
in the conceptual drawings in Figures 18-2 and 18-3. However, even though the individual
commands are straightforward, the configuration requires several steps. So, this
section breaks the configuration into two sections: tunnel configuration steps and IPv6
configuration steps.
Configuring and Verifying a Manually Configured Tunnel
To configure the tunnel, first you need to choose what IPv4 addresses will be used when
encapsulating packets (as shown in Figure 18-2). A router’s tunnel interface borrows the
IPv4 address on some other interface; the router then uses that IPv4 address as the source
address when encapsulating packets. Comparing the configuration on the two routers on
either end of the tunnel, the two routers must agree to the correct IPv4 addresses: the
source address used by one router should match the other router’s tunnel destination IPv4
address and vice versa. Finally, for better availability, if any IPv4 redundancy exists between
the two routers, the engineer should choose to use loopback interface IPv4 addresses,
because the tunnel interface fails if the interface associated with the source IP
address fails.
The configuration centers around the configuration of a virtual interface called a tunnel
interface. The tunnel interface creates an object that can be configured like an interface, so
that additional commands can set parameters for a given tunnel. For instance, the engineer
configures the source and destination IPv4 addresses (two different interface subcommands),
with another command to configure the tunnel encapsulation (GRE or manually
configured tunnel). The following list outlines the steps to configure the tunnel.
Step 1. Find the tunnel IPv4 addresses planned for the tunnel, and ensure that each
router can forward IPv4 packets between the addresses. If using a new loopback
interface, create the loopback using the interface loopback number command,
assign it an IPv4 address with the ip address command, and confirm
that routes for this interface will be advertised by IPv4.
Step 2. Create a tunnel interface using the interface tunnel number command, selecting
a locally significant integer as the tunnel interface number.
Key
Topic
www.CareerCert.info
Chapter 18: IPv4 and IPv6 Coexistence 621
R1 R3
F0/0
2111::1
Loop 1
10.9.9.1
Loop 3
10.9.9.3
Tunnel 0
2013::1
Tunnel 3
2013::3
F0/1
2222::3
Figure 18-6 Figure Showing Configuration Items in Example 18-1
Step 3. Define the source IPv4 address of the tunnel using the tunnel source
{interface-type interface-number | ipv4-address} interface subcommand.
(This address must be an IPv4 address configured on the local router.)
Step 4. Define the destination IPv4 address for the encapsulation using the tunnel
destination ipv4-address interface subcommand; the address must match the
tunnel source command on the other router.
Step 5. Define the tunnel as a manually configured tunnel (not GRE), as defined in
RFC 4213, using the tunnel mode ipv6ip interface subcommand.
For example, consider Figure 18-6, which shows an updated representation of the Enterprise
network shown in Figures 18-1, 18-2, and 18-3. In this case, even though no redundancy
exists, the engineer plans to use loopback addresses (10.9.9.1 on R1 and 10.9.9.3 on
R3). Example 18-1 that follows shows the tunnel configuration on R1 and R3.
Example 18-1 Configuring an IPv6IP Tunnel on R1 and R3
R1# conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)# interface loopback 1
R1(config-if)# ip address 10.9.9.1 255.255.255.255
R1(config-if)# interface tunnel 0
R1(config-if)# tunnel source loopback 1
R1(config-if)# tunnel destination 10.9.9.3
R1(config-if)# tunnel mode ipv6ip
! Next, on router R3
R3# conf t
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)# interface loopback 3
R3(config-if)# ip address 10.9.9.3 255.255.255.255
R3(config-if)# interface tunnel 3
R3(config-if)# tunnel source loopback 3
R3(config-if)# tunnel destination 10.9.9.1
R3(config-if)# tunnel mode ipv6ip
At this point, assuming IPv4 connectivity exists between the two tunnel endpoints, the
tunnel interfaces should be up. A quick show command, as shown in Example 18-2, confirms
the tunnel interface’s status on R1, plus a few other interesting tidbits. Beside the
tunnel interface being up, the output confirms the source and destination IPv4 addresses.
www.CareerCert.info
622 CCNP ROUTE 642-902 Official Certification Guide
It also confirms that the tunnel mode uses IPv6 over IP (the word “IP” implying IPv4) to
match the tunnel mode ipv6ip configuration command.
Example 18-2 Verification of the Tunnel
R1# show interfaces tunnel0
Tunnel0 is up, line protocol is up
Hardware is Tunnel
MTU 17920 bytes, BW 100 Kbit/sec, DLY 50000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 10.9.9.1 (Loopback1), destination 10.9.9.3
Tunnel protocol/transport IPv6/IP
Tunnel TTL 255
Tunnel transport MTU 1480 bytes
Tunnel transmit bandwidth 8000 (kbps)
Tunnel receive bandwidth 8000 (kbps)
! the rest of the output is the typical counter information
Configuring and Verifying the Manually Configured Tunnel
The configuration shown in the previous section prepares the tunnel to encapsulate traffic
inside IPv4 packets, but it does complete the configuration. The configuration also needs
to enable IPv6 on the routers that create the tunnel, treating the tunnel interfaces just like
you would for serial interfaces connected with a leased line.
The configuration steps mirror those discussed at some length in Chapters 16 and 17, so
the specific commands will not be discussed here. However, Example 18-3 shows the configuration
of both the tunnel and the IPv6 details on R1, with the newly added IPv6 commands
highlighted.
Example 18-3 Completed Tunnel and IPv6 Configuration on Router R1
R1# show running-config
! Only pertinent portions retained
ipv6 unicast-routing
!
interface Loopback1
ip address 10.9.9.1 255.255.255.255
!
interface Tunnel0
no ip address
ipv6 address 2013::1/64
ipv6 eigrp 1
tunnel source Loopback1
tunnel destination 10.9.9.3
tunnel mode ipv6ip
www.CareerCert.info
Chapter 18: IPv4 and IPv6 Coexistence 623
!
interface FastEthernet0/0
ip address 10.1.1.1 255.255.255.0
ipv6 address 2111::1/64
ipv6 eigrp 1
!
ipv6 router eigrp 1
eigrp router-id 1.1.1.1
no shutdown
The new configuration should be somewhat familiar from the last few chapters, but a few
items could use some emphasis. First, note that the tunnel interface does indeed have an
IPv6 address configured, and EIGRP enabled, just as if it were a physical interface. However,
the tunnel interface does not have, nor does not need, an IPv4 address. The tunnel interface
needs only a Layer 3 address for the passenger protocols – in other words, the
protocols carried as data inside the encapsulating packets. So, only an IPv6 address is
needed on the interface. The rest of the highlighted IPv6 configuration uses the same
logic discussed in Chapters 16 and 17.
The same verification commands seen in Chapters 16 and 17 can confirm the IPv6 details
on the tunnel. Example 18-4 lists the output from a few of these commands, highlighting
some of the key details.
Example 18-4 Verifying IPv6 Works over the Tunnel
R1# show ipv6 interface brief
FastEthernet0/0 [up/up]
FE80::213:19FF:FE7B:5026
2111::1
! irrelevant lines omitted for brevity
Loopback1 [up/up]
unassigned
Tunnel0 [up/up]
FE80::A09:901
2013::1
R1# show ipv6 interface tunnel0
Tunnel0 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::A09:901
No Virtual link-local address(es):
Global unicast address(es):
2013::1, subnet is 2013::/64
Joined group address(es):
FF02::1
FF02::2
FF02::A
FF02::1:FF00:1
www.CareerCert.info
624 CCNP ROUTE 642-902 Official Certification Guide
FF02::1:FF09:901
MTU is 1480 bytes
ICMP error messages limited to one every 100 milliseconds
ICMP redirects are enabled
ICMP unreachables are sent
ND DAD is enabled, number of DAD attempts: 1
ND reachable time is 30000 milliseconds (using 42194)
Hosts use stateless autoconfig for addresses.
R1# traceroute ipv6 2222::3
Type escape sequence to abort.
Tracing the route to 2222::3
1 2013::3 0 msec 4 msec 4 msec
The first two commands show how routers create the link local IPv6 addresses for manually
configured tunnel interfaces. Routers normally form a serial interface’s link local IPv6
address using EUI-64 rules based on the MAC address of the first LAN interface on the
router. In this case, the router forms the link local address with a FE80::/96 prefix and then
adds the 32-bit tunnel source IPv4 address as the last 32 bits. For example, the first two
show commands in Example 18-4 list R1’s link local address on its tunnel interface:
FE80::A90:901. Adding back the leading 0s in the last two quartets, the last two quartets
look like this:
0A09:0901
Converting each pair of hex characters to decimal, you can find the IPv4 address of
10.9.9.1. (Appendix B, “Conversion Tables,” includes a hex/decimal conversion table.)
The show ipv6 interface tunnel0 command lists the usual IPv6 addresses. It lists the link
local address, along with the statically configured global unicast address (2013::1). It lists
multicast addresses, including EIGRP’s FF02::A, and the (highlighted) solicited node multicast
address associated with both the link local and the global unicast address on the interface.
(When a multicast needs to be sent out a manually configured tunnel’s interface,
the router encapsulates the IPv6 multicast and forwards it inside a unicast IPv4 packet to
the other end of the tunnel.)
The traceroute ipv6 2222::3 command at the end of the example confirms that IPv6 traffic
can pass over the tunnel.
GRE Tunnels
Only one difference exists in the configuration between manually configured tunnels and
point-to-point GRE tunnels: the tunnel mode. IOS uses the tunnel mode ipv6ip command
for manually configured tunnels, which also tells IOS to use the encapsulation as defined
in RFC 4213. IOS uses the tunnel mode gre ip command to instead configure a GRE tunnel,
meaning that IOS uses the RFC 2784 GRE encapsulation. This encapsulation adds the
GRE header to the encapsulation. (Also, because IOS defaults to use GRE over IP, you can
alternatively just omit the tunnel mode command as well.)
www.CareerCert.info
Chapter 18: IPv4 and IPv6 Coexistence 625
Key
Topic
The configurations are indeed almost identical. For example, to migrate from the configuration
shown in Example 18-3, which shows all of R1’s configuration for both the tunnel
and IPv6 with a manually configured tunnel, simply use one of the following two options:
■ Issue the tunnel mode gre ip command on both routers’ tunnel interfaces.
■ Issue the no tunnel mode ipv6ip command on both routers’ tunnel interfaces, which
reverts to the default of GRE over IP.
Note: If the two routers’ tunnel modes do not match, the tunnel interfaces can stay
up/up, but the routers cannot forward IPv6 packets because of the mismatched encapsulations.
The verification command output looks almost identical as well, but with just a few differences
to note. IOS uses a different convention for the link local address created for a GRE
tunnel interface. It works as if the tunnel interface is a serial interface, deriving the interface
ID using EUI-64 rules and the MAC address of the first LAN interface on the router.
The second difference relates to how IOS automatically sets the MTU of the passenger
protocols (IPv6 in this case) to 1476 for GRE tunnels; with manually configured tunnels,
the passenger MTU was set to 1480. These settings allow space in both modes for the 20-
byte additional IPv4 header that encapsulates the packet, plus in the case of GRE, the additional
4-byte GRE header. Example 18-5 highlights some of these minor differences.
Example 18-5 Verifying GRE over IP Tunnels That Support IPv6
R1# show interfaces tunnel 0
Tunnel0 is up, line protocol is up
Hardware is Tunnel
MTU 17916 bytes, BW 100 Kbit/sec, DLY 50000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 10.9.9.1 (Loopback1), destination 10.9.9.3
Tunnel protocol/transport GRE/IP
Key disabled, sequencing disabled
Checksumming of packets disabled
Tunnel TTL 255
Fast tunneling enabled
Tunnel transport MTU 1476 bytes
Tunnel transmit bandwidth 8000 (kbps)
Tunnel receive bandwidth 8000 (kbps)
! the remaining omitted lines list interface counters
Point-to-Point IPv6 Tunnel Summary
Point-to-point IPv6 tunnels give engineers a means to implement IPv6 connectivity without
requiring extensive deployment of native IPv6. At the same time, these tunnels act like
native IPv6 links, running IPv6 IGPs, using link local addresses, and requiring no static
www.CareerCert.info
626 CCNP ROUTE 642-902 Official Certification Guide
Key
Topic
Table 18-3 Comparing Manual and GRE IPv6-over-IP Tunnels
Manual Tunnels GRE
RFC 4213 2784
Tunnel mode command tunnel mode ipv6ip tunnel mode gre ip
Passenger MTU default 1480 1476
Supports IPv6 IGPs? Yes Yes
Forwards IPv6 multicasts? Yes Yes
Uses static configuration of
tunnel destination?
Yes Yes
Supports multiple passenger
protocols?
No Yes
Link local based on... FE80::/96, plus 32 bits
from tunnel source
IPv4 address
IPv6 EUI-64, using lowest
numbered interface’s MAC
address