Troubleshooting Tunnel Issue

[Iloveyou]

I ever had to troubleshoot an issue in which the encapsulation protocol of the tunnel was configured incorrectly.

However, the tunnel was still "up/up".

Why is the tunnel still "up/up" even though the encapsulation protocol was wrong? 

[MHM Cisco World]

 The tunnel status depend on reachability of tunnel destination' if it reachable (only appear in RIB or resolve by RIB) the tunnel is UP/UP.

But we can add something to monitor health of tunnel which is add keepalive which check tunnel along path to destiantion' also keepalive not work if the encapsulate is mismatch between two end of tunnel.

MHM

[Iloveyou]

In my setup the 2 tunnel endpoints are private ip.

The tunnel goes through the isp. 

Does this count as "only appear in RIB or resolve by RIB"?

[MHM Cisco World]

Yes' for example the tunnel destination is 210.21.21.1

And you have static or default route or IGP for this IP then it resolve by RIB.

If it direct connect then it appear in RIB as "C"

The best way to test is 

Show ip route 210.21.21.1 longest 

If route appear then your router have or resolve tunnel destination.

Here tunnel will be UP/UP even if there link failed or down in path to destiantion.

MHM

[Iloveyou]

I believe that a 0.0.0.0/0 next hop ip  counts too?

[MHM Cisco World]

Sure count.

MHM

[Joseph W. Doherty]

What tunnel protocol and platform?  Reason I ask, some tunnel protocols on some platforms show up/up even without reachability to other tunnel side.

As @MHM Cisco World already described, (some) tunnels support keepalives.  Those that do, for cases as above, tunnel will only be up/up with end to end connectivity.

[Iloveyou]

cant remember the platform but one was gre and another was ipip.

you said " some tunnel protocols on some platforms show up/up even without reachability to other tunnel side."

why is it like this? it is very misleading. Any better way to troubleshoot?

[Joseph W. Doherty]

---

@Iloveyou wrote:

cant remember the platform but one was gre and another was ipip.

you said " some tunnel protocols on some platforms show up/up even without reachability to other tunnel side."

why is it like this? it is very misleading. Any better way to troubleshoot?

---

Why?  Sorry, don't know, which is why I replied earlier "I never bothered investigating this behavior change. . ."

In the case where it's up/up with an invalid combination, likely because no "far side" is "good" validation done.  As GRE or IPIP are encapsulation protocols, logically, they really shouldn't need to validate far side is usable, but just validate, and process, transit traffic.

If the tunnel being up/up seems so illogical, consider:

router .1<ethernet>switch<ethernet>.2 router

If either router fails will other router's Ethernet interface go down?  No, it will stay up/up.  Since tunnel is a logical interface, why must it NOT be up/up if far side isn't?

Conversely, though, if you had:

router .1<ethernet>.2 router

If other router goes down, near side interface goes down too.

So, point is, which should tunnel interface "link" emulate?  Believe you could argue for either.

For simplicity, of a protocol like GRE, they might argue "not our problem" to take the interface down if you don't have a valid end-to-end tunnel.

As already noted, "knowing" the tunnel path isn't truly working, end-to-end, can be revealed by keepalives and/or a dynamic routing protocol.  Some kind of on-going SLA test would also reveal whether tunnel is usable.

[Gopinath_Pigili]

Hello,

There are four possible states in which a GRE tunnel interface exists:

1. Up/up - This implies that the tunnel is fully functional and passes traffic. It is both administratively up and its protocol is up as well.
2. Administratively down/down - This implies that the interface has been administratively shut down.
3. Up/down - This implies that, even though the tunnel is administratively up, something causes the line protocol on the interface to be down.
4. Reset/down - This is usually a transient state when the tunnel is reset by software. This usually happens when the tunnel is misconfigured with a Next Hop Server (NHS) that is its own IP address.

GRE tunnels are designed to be completely stateless. This means that each tunnel endpoint does not keep any information about the state or availability of the remote tunnel endpoint.

A consequence is that, by default, the local tunnel endpoint router cannot bring the line protocol of the GRE Tunnel interface down if the remote end of the tunnel is unreachable

Best regards
******* If This Helps, Please Rate *******

[Joseph W. Doherty]

For point #1, I've seen up/up GRE tunnel interfaces that don't have a reachable "far" side tunnel interface.  I.e., they blackhole any passed traffic.

I recall also seeing GRE tunnel interfaces, without an explicit keepalive configured, also only go up/up when the other end of the tunnel could be reached.

The change in behavior seemed to be related to how new the platform was. I never bothered investigating this behavior change (because almost always use a dynamic routing protocol across such tunnels - i.e. alarmed on routing issues, not interface status) but possibly later GRE implementations did some form of implicit keepalive.

[Iloveyou]

could be reached or could not be reached?

what i experience is that wan interface is pingable but tunnel not working due to different encapsulation protocol.

[Joseph W. Doherty]

---

@Iloveyou wrote:

could be reached or could not be reached?

what i experience is that wan interface is pingable but tunnel not working due to different encapsulation protocol.

---

My reference to reachability, is tunnel end-to-end.  Mixing tunnel encapsulations precluding tunnel operation has nothing to do with being able to ping physical tunnel end point (although, of course, if you cannot reach the tunnel physical's end point, tunnel won't work either, again, though, may show as up/up).

[Iloveyou]

you said "

1. Up/up - This implies that the tunnel is fully functional and passes traffic. It is both administratively up and its protocol is up as well."

in that case why is tunnel up/up when encapsulation protocol is mismatch on both sides.

[Gopinath_Pigili]

In WAN interface like ...Serial link.......then line protocols status is down...main cause might be mismatch encapsulation.

I think..It's not same case with Tunnel Interface. Tunnel Interface line protocol is down... since, it does not have a tunnel source or a tunnel destination, then line protocol is down.

In order to make this interface up/up (line protocol), a valid tunnel source and tunnel destination must be configured.

Best regards
******* If This Helps, Please Rate *******