This topic is to discuss the following lesson:
https://networklessons.com/ipv6/how-to-configure-ipv6-tunneling-over-ipv4/
Tunnel interface ip is not required.is it not necessary?
IPv6 uses the link-local addresses as the next-hop for routing entries so there is no need to configure a “global” IPv6 address.
Hello,
I see that you are using multiple interfaces, but our router is only base license… which means we can only have up to 2 interfaces(that are not psychical).
Will it be possible with only 2 interfaces and(loopback 0&1) and have the tunnel psychical? I see that you write that it can be psychical, but what kind of changes would we need to do if so?
Hi Tor,
The tunnel0 interface is using the source IP addresses of my loopback interfaces. You can also build the tunnel between the IP addresses on the FastEthernet0/0 interfaces. Just use those as the source and destination and you are ready to go.
Rene
Hello Rene, and thanks for previous answer. We got it fixed, we changed two of the routers to cisco 1812, and the one running ipv4 only is a asa 5505. we are kinda stuck again though. I want all the other fastethernet ports(1-9) behind lets say destiny(cisco 1812), to access the servers behind cryo. Whatever I do, it wont work…
Thanks again,
regards
If you need some help with this, it’s best to your topology and configs on the GNS3Vault forum. We can take a look there…
Hello Rene,
I was testing these two different manual tunneling types in the lab and wanted to confirm what one should see as that expected MTU for GRE vs. the manual tunnel? I know that you state GRE has a higher MTU, but that was not what I observed in the testing. Also not 100%
R6#sh int tunn0
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 linestate evaluation up
Tunnel source 10.36.36.6 (GigabitEthernet0/1), destination 10.23.23.2
Tunnel Subblocks:
src-track:
Tunnel0 source tracking subblock associated with GigabitEthernet0/1
Set of tunnels with source GigabitEthernet0/1, 1 member (includes iterators), on interface
Tunnel protocol/transport GRE/IP
Key disabled, sequencing disabled
Checksumming of packets disabled
Tunnel TTL 255, Fast tunneling enabled
Tunnel transport MTU 1476 bytes
.
.
.
vs.
R022DC3N4806#sh int tunn0
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 linestate evaluation up
Tunnel source 10.36.36.6 (GigabitEthernet0/1), destination 10.23.23.2
Tunnel Subblocks:
src-track:
Tunnel0 source tracking subblock associated with GigabitEthernet0/1
Set of tunnels with source GigabitEthernet0/1, 1 member (includes iterators), on interface
Tunnel protocol/transport IPv6/IP
Tunnel TTL 255
Tunnel transport MTU 1480 bytes
Tunnel transmit bandwidth 8000 (kbps)
Tunnel receive bandwidth 8000 (kbps)
Last input 00:00:09, output 00:00:21, output hang never
Last clearing of "show interface" counters 00:16:08
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
--More--
Also I am not seeing any association with one of my MAC addresses to the link-local address for GRE tunnel that you mention is created with EUI-64 and takes lowest numbered interface MAC address.
R6#sh ipv6 route
IPv6 Routing Table - default - 4 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
B - BGP, HA - Home Agent, MR - Mobile Router, R - RIP
H - NHRP, I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea
IS - ISIS summary, D - EIGRP, EX - EIGRP external, NM - NEMO
ND - ND Default, NDp - ND Prefix, DCE - Destination, NDr - Redirect
O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2, la - LISP alt
lr - LISP site-registrations, ld - LISP dyn-eid, a - Application
R 2001:10:22:22::/64 [120/2]
via FE80::5287:89FF:FEB9:7460, Tunnel0
C 2001:10:66:66::/64 [0/0]
via Loopback0, directly connected
L 2001:10:66:66::66/128 [0/0]
via Loopback0, receive
L FF00::/8 [0/0]
via Null0, receive
Many thanks for your help to clarify.
Hi Thomas,
The output of the show command for tunnel interfaces has been changed in later IOS versions. What version are you using here?
The MTU of 17916 bytes is the largest MTU that the router can handle which is based on its buffer sizes. The Tunnel transport MTU of 1476 bytes is the actual MTU of the interface, this is smaller to compensate for the overhead of GRE (24 bytes).
About the MAC address, do a “show ip interface tunnel” to see your link local address of this router, then compare it to the MAC addresses of this router.
Rene
I am running 15.4(3)M1. Ok - that makes sense. So based upon this GRE tunnel overhead is 24bytes while manual tunnel mode is 20 bytes, so slightly more overhead for the GRE method. As for the link-local, I was looking on the wrong router 
- I posted R6 configuration above, but when looking for that link-local of the neighbor I was not on the right router in my lab setup. Many thanks.
Whenever a loopback goes down our IGP (EIGRP in this example) could find another path (if there is another path).
should the above read whenever a physical interface goes down? because a loopback should never go down.
That’s a typo for sure. Just fixed it, thanks for letting me know.
Hi Rene,
You mention (or the other way around) in the first part of this. I am wondering how to encapsulate ipv4 traffic inside an ipv6 tunnel. Let’s say I have 2 global v6 endpoints (routers) but want to setup a v4 GRE tunnel INSIDE the v6 tunnel. I don’t know if this makes sense, or if it’s even possible. Basically I want to be able to use global v6 addresses, in order to still use GRE, such as in a DMVPN situation.
Thanks in advance
Hello Mitchell
Yes, it is possible to encapsulate IPv4 inside an IPv6 tunnel. What Rene has described in this lesson is colloquially referred to as 6in4. What you are referring to is 4in6 which is equally achievable.
You can find out more information about such a tunnel from the following Cisco Documentation.
I hope this has been helpful!
Laz
The major differences:
MCT - MTU is 1480, less overhead, supports only a single passenger protocol, mode is ipv6ip.
GRE - MTU is 1476, more overhead, supports multiple passenger protocols, mode is gre.
1 Like
MCT? Is that the manual mode?
Hello Chris
I belive what @zz.alnajjar is referring to is a Manually Configured Tunnel (MCT) although it does not have an official such name. What the manually configured tunnel is, is an IP packet inside an IP packet. A doubly encapsulated packet. If this is configured, the overhead will just be 20 bytes, which is the size of the header of a standard IPv4 packet, thus prodcing an MTU of 1500-20 = 1480. GRE on the other hand has a header of 24 bytes providing an MTU of 1500-24 = 1476.
More info can be found on page 2 of this Cisco Documentation.
I hope this has been helpful!
Laz
Rene, I tried using the following lab without configuring a global IPv6 address but it would not work until I configured the global IPv6 address. I’m going to continue to play with this to see if I can figure it out, but in the event I don’t can you tell me if there’s something else I have to do to get this to work with the link-local addresses?
Hello Mike
Rene’s comment about the use of link-local addresses was only for use by the router in order to determine the next hop. In other words, the IP addresses between routers, or the infrastructure addresses, can in deed be link local addresses only. However, the global IPv6 addresses should be configured in order for the end devices to be able to communicate.
Now for this particular lab, the use of global unicast addresses is vital because you must translate between a specific IPv6 range and a specific IPv4 range in order to perform IPv6 tunneling over IPv4. Such tunneling requires that the IPv6 address range be global unicast addresses. Link-local addresses cannot and should not be tunneled. This restriction is further outlined in this RFC:
https://tools.ietf.org/html/draft-savola-ngtrans-6to4-security-01
Because the IP address range being translated is also the IP address subnets that exist between the Banana and Melon routers as well as between the Apple and Kiwi routers, if no tunneling was necessary, these subnets could indeed remain link-local addresses. However, because these ranges are the very ranges that are to be translated, they must be global unicast addresses.
I hope this has been helpful!
Laz
It has. Thank you very much for your reply!
1 Like