Ticket 15 – IPv6 GRE Tunnel

my method-of-resolution:
A) show running-config | b Loopback for R1, R2, R3, R4, DSW1, DSW2.
DSW1 not needed for this problem but wanted to be thorough.
B) write down the Loopback addresses for each of the above, specifically noting the IPv6 addresses.
C) ping R1->R2, R1->R3, R1->R4 Loopback6 addresses.
i) If you are diligent in your studies you will see Loopback6 addresses are IPv6, while Loopback0 and Loopback1 addresses are IPv4.
ii) All Loopback6 addresses are in the 2026 network.
iii)> R1->R4 ping fails; thus indicating an issue between R3 and R4.
D) ping DSW2->R4, DSW2->R3.
Note that DSW2->R3 fails,; again indicating something wrong between R3 & R4.
E) Looking at IPv6 Topology Diagram we see there is an IPv6 GRE Tunnel in Area 34 that is Totally NSSA.
i) show running-config on R3 & R4.
ii) Note there is an interface Tunnel 34 on R3 & R4.
iii) Comparing the two configs (R3 & R4), observe there is “tunnel mode ipv6” on R3 but not on R4
iv) Hardest part is realizing that Fault Condition is not just IPv6.
a) tunnel destination addresses are IPv4.
b) GRE Tunnel (Tunnel 34) are IPv6 addresses under IPv6 OSPF process 6 in Area 34
—–> Fault condition: IPv4 and IPv6 interoperability

My method to solve this:

1. Start ping from R1 to R2, R3 and R4.
2. R1 –> R4 ping fails… means problem should be between R3 and R4.
3. Check configs of IPv6 on R3 and R4.
4. Easiest method is to check the “show ipv6 ospf neighbor” command on R3. It will show only one neighborship with R2 but not with R4.
5. Issue should be on R3-R4 ospf’s ipv6 process and interfaces.
6. There is Tunnel interface between R3 and R4.. So the ambigious command “tunnel mode ipv6” can easily be identified from running config.

im confused.. the “show ipv6 interface” command shows me that tun34 ipv6 is up/up on both sides… is that right? and why?

after several hours, i just realized that the PacketTracer Ticket 15 is NOT this GRE-Tunnel-34 discussion.

But networktut sim shows config differences on R3 and R4 –which is the correct answer for this ticket

anyone knows the difference between

tunnel mode ipv6
and
tunnel mode ipv6ip

?

ty in advance

Is there any new questions

Guys. In this ticket (15) is suppose to ping the webserver from client 1?

My question is because in the networttut sim, we cant ping the webserver from client 1 and 2

Hi!
I’ve just passed exam today with 1000/1000.
I’m so happy !!!
Only new questions (13th-Nov-2019), 2 Simlets, the same Tickets.
All answers here are good.

ONE PROBLEM – almost failed here – in Ticket 15 IPv6 GRE Tunnel command “tunnel mode ipv6” is in the middle of interface configuration, not at the bottom.

Given the problem,we are concerned with DSW2 to R1 on IPv6 L3 topology. Check the possible path: DWS2>R4>R3>R2>R1

From DSW2 let’s ping loopbacks on the way to R1(Do a sh ip int br on R4,R3,R2 annd R1 to get ipv6 addresses). Can ping R4’s ipv6 loopback address but cannot ping R3 ,R2 and R1

Go to R3 and try to ping R4 and DSW2’s loopback and well as ping R1 and R2’s ipv6 loopback addresses. Cannot ping R4 and DSW and R2 but can ping R1.

We have to go over and examine R3 more closely.She also want to see R2 and R4’s show run configs

R2-R3 config looks good but R3 to R4 there is a tunnel 34 and it is has an extra tunnel mode ipv6 command. You know it is extra because a sh interface tunnel34 on R4 indicates up/up status but on R3 it is up/down so remove that extra link on R3 will bring the tunnel interface to up/up

Hi All, I have passed Tshoot exam today with 1000/1000. 13th-Nov-2019 MCQs questions, simlets and tickets are all valid! NO new questions or tickets. To narrow down issue I normally ping 209.65.200.241 from R1, then R2>>>R3>>>R4>>>DSW1>>>Client & do ipconfig on client ping client IP 10.2.1.3 from DSW >>>R4 >>>R3 >>>R2>>>R1.

I had premium account, after spending 4 hours I booked exam. CCNP route is theory, CCNP TSHOOT is practical and very easy.

@Woodkid

“tunnel mode ipv6” creates a generic IPv6 gre tunnel. This is the equivalent to a normal IPv4 GRE tunnel, it’s just using a v6 GRE header to encapsulate the traffic instead of v4.

“tunnel mode ipv6ip” creates a 6to4 tunnel. 6to4 tunnels encapsulate IPv6 packets for transmission over IPv4 networks. 6to4 uses a static mapping… every IPv4 address is mapped to a corresponding v6 address by (I’m simplifying a bit) appending the v4 address to the 2002::/16 v6 subnet. The key thing to understand is that because of that static mapping, a 6to4 tunnel doesn’t need a tunnel destination address. If the router receives a packet destined for an address in 2002::/16, it can reverse the algorithm and get the corresponding IPv4 address, to which the packet is sent after being encapsulated inside of a v4 GRE tunnel.

Basically 6to4 is a transition technology. It’s so you can stitch together all of your internal v6 subnets using a v4 WAN. If you pick all of your v6 subnets carefully, you won’t need to keep track of where they are on the v4 because it’s implied via the subnet.

6to4 is basically dead. If I’m not mistaken it was in the earlier drafts of v6 and then was disfavored later on, but it’s still implemented as an option on lots of devices. If you think about it, there’s a ton of manual things you’d need to keep track of and it won’t necessarily be dynamic if routes go down. You’re also going to need to assign non-global addresses to all the v6 devices on your network, which kinda sucks too. So you’d better off doing something GRE/mGRE and using routing protocols to sort it out.