A. Manually configured tunnels (MCT)
B. Generic Routing Encapsulation (GRE) tunnels
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.
Both require static configuration of both the tunnel source and the tunnel destination IPv4 addresses.
Note: GRE uses an additional stub header between the IPv4 and IPv6 header; this extra header includes a protocol type field, which allows a GRE tunnel to carry many passenger protocols.
GRE’s flexibility allows a single GRE tunnel to carry IPv6 plus other traffic as well, whereas manually configured tunnels cannot.
A. Manually Configured Tunnels
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.
The source address used by one router should match the other router’s tunnel destination IPv4 address and vice versa.
Note: 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 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.
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), using the tunnel mode ipv6ip interface subcommand.
Let's consider routers R2 and R3 and establish a MCT between them for the forwarding of IPv6 packets over the R2-R3 IPv4 core.
Our goal is to see how the IPv6 traffic is encapsulated into IPv4 across the R2-R3 link and then decapsulated by R3 to be sent to the destination.
We will consider R2's Fa0/0 (2001::1) as the source of the IPv6 packets and R3's Se0/0 (2003::1) as the IPv6 destination.
Also we will use static routes in order to establish reachability between R2's and R3's loopback interfaces and between R2's Fa0/0 and R3's Se0/0 IPv6 addresses.
No IPv6 addresses are configured on the inner interfaces, just IPv4.
The initial configurations:
R2 Fa0/1:
!
interface FastEthernet0/1
ip address 132.0.0.1 255.255.255.252
duplex auto
speed auto
!
R3 Fa0/0:
!
interface FastEthernet0/0
ip address 132.0.0.2 255.255.255.252
duplex auto
speed auto
!
Step 1:
R2(config)#interface loopback 2
R2(config-if)#ip address 2.2.2.2 255.255.255.255
R3(config)#interface loopback 3
R3(config-if)#ip address 3.3.3.3 255.255.255.255
R2#show ip interface brief fastEthernet 0/1
Interface IP-Address OK? Method Status Protocol
FastEthernet0/1 132.0.0.1 YES NVRAM up up
R3#show ip interface brief fastEthernet 0/0
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 132.0.0.2 YES NVRAM up up
R2(config)#ip route 3.3.3.3 255.255.255.255 132.0.0.2
R3(config)#ip route 2.2.2.2 255.255.255.255 132.0.0.1
R2(config)#do ping 3.3.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/23/44 ms
R3(config)#do ping 2.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/24/40 ms
Steps 2, 3, 4, 5:
R2(config)#interface tunnel 2
R2(config-if)#ipv6 address 2014:0:0:14::2/64
R2(config-if)#tunnel source loopback 2
R2(config-if)#tunnel destination 3.3.3.3
R2(config-if)#tunnel mode ipv6ip
R2(config)#ipv6 route 2003::/64 tunnel 2
R3(config)#interface tunnel 3
R3(config-if)#ipv6 address 2014:0:0:14::3/64
R3(config-if)#tunnel source loopback 3
R3(config-if)#tunnel destination 2.2.2.2
R3(config-if)#tunnel mode ipv6ip
R3(config)#ipv6 route 2001::/64 tunnel 3
R2#show interfaces tunnel 2
Tunnel2 is up, line protocol is up
Hardware is Tunnel
MTU 1514 bytes, BW 9 Kbit/sec, DLY 500000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 2.2.2.2 (Loopback2), destination 3.3.3.3
Tunnel protocol/transport IPv6/IP
R3#show interfaces tunnel 3
Tunnel3 is up, line protocol is up
Hardware is Tunnel
MTU 1514 bytes, BW 9 Kbit/sec, DLY 500000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 3.3.3.3 (Loopback3), destination 2.2.2.2
Tunnel protocol/transport IPv6/IP
The tunnel is UP on both sides:
R2#ping 2014:0:0:14::3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2014:0:0:14::3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/24/36 ms
R3#ping 2014:0:0:14::2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2014:0:0:14::2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/24/56 ms
Now, we should be able to see the encapsulation process by using Wireshark while ping-ing from R2's Fa0/0 (2001::1) to R3's Se0/0 (2003::1).
Before ping-ing, we will start a Wireshark capture on the R2-R3 link (R3's Fa0/0 to be more specific), using the embedded GNS3 Wireshark app and filter the results by "icmpv6".
R2#ping 2003::1 source 2001::1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2003::1, timeout is 2 seconds:
Packet sent with a source address of 2001::1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/24/48 ms
The ping is successful and the capture shows us that the IPv6 header was indeed encapsulated inside an IPv4 header.
The IPv4 header specifies a source address of 2.2.2.2 (R2's Lo2) and a destination address of 3.3.3.3 (R3's Lo3), showing that the communication took place between the IPv4 addresses in the so-called IPv4 core.
The IPv6 header specifies the source and destination addresses that we used in the ping command.
To further enhance the idea of encapsulation, we can go into Wireshark - Statistics - Protocol Hierarchy and see the header order in the packet.
Verification commands:
R2#show ipv6 interface brief tunnel 2
Tunnel2 [up/up]
FE80::202:202
2014:0:0:14::2
R3#show ipv6 interface brief tunnel 3
Tunnel3 [up/up]
FE80::303:303
2014:0:0:14::3
Note: 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. 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.
B. GRE Tunnels
Only one difference exists in the configuration between manually configured tunnels and point-to-point GRE tunnels: the tunnel mode.
The IOS uses the tunnel mode gre ip command to configure a GRE tunnel.
Note: Because IOS defaults to use GRE over IP, you can alternatively just omit the tunnel mode command.
To migrate from MCT to GRE 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.
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.
Note: 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 20byte additional IPv4 header that encapsulates the packet, plus in the case of GRE, the additional 4-byte GRE header.
Let's consider routers R2 and R3 and establish a GRE Tunnel between them for the forwarding of IPv6 packets over the R2-R3 IPv4 core.
Our goal is to see how the IPv6 traffic is encapsulated into IPv4 across the R2-R3 link and then decapsulated by R3 to be sent to the destination.
We will consider R2's Fa0/0 (2001::1) as the source of the IPv6 packets and R3's Se0/0 (2003::1) as the IPv6 destination.
Also we will use static in order to establish reachability between R2's and R3's loopback interfaces and OSPFv3 to be able to ping between R2's Fa0/0 and R3's Se0/0 IPv6 addresses.
No IPv6 addresses are configured on the inner interfaces, just IPv4.
The initial configurations:
R2 Fa0/1:
!
interface FastEthernet0/1
ip address 132.0.0.1 255.255.255.252
duplex auto
speed auto
!
R3 Fa0/0:
!
interface FastEthernet0/0
ip address 132.0.0.2 255.255.255.252
duplex auto
speed auto
!
Step 1:
R2(config)#interface loopback 2
R2(config-if)#ip address 2.2.2.2 255.255.255.255
R3(config)#interface loopback 3
R3(config-if)#ip address 3.3.3.3 255.255.255.255
R2#show ip interface brief fastEthernet 0/1
Interface IP-Address OK? Method Status Protocol
FastEthernet0/1 132.0.0.1 YES NVRAM up up
R3#show ip interface brief fastEthernet 0/0
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 132.0.0.2 YES NVRAM up up
R2(config)#ip route 3.3.3.3 255.255.255.255 132.0.0.2
R3(config)#ip route 2.2.2.2 255.255.255.255 132.0.0.1
R2(config)#do ping 3.3.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/23/44 ms
R3(config)#do ping 2.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/24/40 ms
Steps 2, 3, 4, 5:
R2(config)#interface tunnel 2
R2(config-if)#ipv6 address 2014:0:0:14::2/64
R2(config-if)#ipv6 ospf 1 area 0
R2(config-if)#tunnel source loopback 2
R2(config-if)#tunnel destination 3.3.3.3
R2(config-if)#tunnel mode gre ip
R3(config)#interface tunnel 3
R3(config-if)#ipv6 address 2014:0:0:14::3/64
R3(config-if)#ipv6 ospf 1 area 0
R3(config-if)#tunnel source loopback 3
R3(config-if)#tunnel destination 2.2.2.2
R3(config-if)#tunnel mode gre ip
R2#show interfaces tunnel 2
Tunnel2 is up, line protocol is up
Hardware is Tunnel
MTU 1514 bytes, BW 9 Kbit/sec, DLY 500000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 2.2.2.2 (Loopback2), destination 3.3.3.3
Tunnel protocol/transport GRE/IP
R3#show interfaces tunnel 3
Tunnel3 is up, line protocol is up
Hardware is Tunnel
MTU 1514 bytes, BW 9 Kbit/sec, DLY 500000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 3.3.3.3 (Loopback3), destination 2.2.2.2
Tunnel protocol/transport GRE/IP
The tunnel is UP on both sides:
R2#ping 2014:0:0:14::3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2014:0:0:14::3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/24/36 ms
R3#ping 2014:0:0:14::2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2014:0:0:14::2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/24/56 ms
We should also include the source and destination interfaces in the OSPFv3 1 process.
R2(config)#interface fastEthernet 0/0
R2(config-if)#ipv6 ospf 1 area 0
R3(config)#interface serial 0/0
R3(config-if)#ipv6 ospf 1 area 0
Now, we should be able to see the encapsulation process by using Wireshark while ping-ing from R2's Fa0/0 (2001::1) to R3's Se0/0 (2003::1).
Before ping-ing, we will start a Wireshark capture on the R2-R3 link (R3's Fa0/0 to be more specific), using the embedded GNS3 Wireshark app and filter the results by "icmpv6".
R2#ping 2003::1 source 2001::1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2003::1, timeout is 2 seconds:
Packet sent with a source address of 2001::1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/20/28 ms
The ping is successful and the capture shows us that the IPv6 header was indeed encapsulated inside an IPv4 header. Also, a GRE header was introduced between the two, to specify the Protocol Type: IPv6.
The IPv4 header specifies a source address of 2.2.2.2 (R2's Lo2) and a destination address of 3.3.3.3 (R3's Lo3), showing that the communication took place between the IPv4 addresses in the so-called IPv4 core.
The IPv6 header specifies the source and destination addresses that we used in the ping command.
To further enhance the idea of encapsulation, we can go into Wireshark - Statistics - Protocol Hierarchy and see the header order in the packet.
Verification commands:
R2#show ipv6 interface brief tunnel 2
Tunnel2 [up/up]
FE80::C202:10FF:FE94:0
2014:0:0:14::2
R3#show ipv6 interface brief tunnel 3
Tunnel3 [up/up]
FE80::C203:10FF:FE94:0
2014:0:0:14::3
No comments:
Post a Comment