We have several WAN connections that are point to point, but the carrier provides an Ethernet handoff to our equipment. One problem with this setup is that if the long haul portion of the circuit goes down our router interface stays up. We use a routing protocol to route around the down circuit, but since our router interface stays up we can not easily detect that the circuit is down.
Is there anyway to have the Ethernet interfaces go down when they can no longer reach the other end of the connection? Would a GRE tunnel or something similar over the connection work for this and then we can detect when the tunnel goes down instead? If so, what would be the pros and cons of doing this.
You could try something like:
If you are running a dynamic routing protocol (like EIGRP or OSPF) over the link as I believe your post states then it should detect the link failure because both of these protocols have neighbor discovery and a hello protocol which should detect failure of the link. (Even RIP should solve this issue though its convergence is much slower).
Depending on the version of code that you are running a GRE tunnel may or may not be a solution. In Cisco's longtime implementation of GRE tunnels the tunnel interface will be up/up as long as the router has a viable route toward the destination. Even if the outgoing link were broken it is likely that the GRE interface would not go down. Cisco introduced a feature in 12.2T of keepalives for GRE tunnel. In this feature the router sends a keepalive packet over the tunnel and should get a response. If no response is received for a configurable number of retries the tunnel interrface goes protocol down. This should be a solution of the issue that you describe if your router has code that supports this feature.
It doesn't look PBR with tracking will take the Ethernet interface down when the other side is not reachable. Therefore we will not be able to detect the issue with our network monitoring system.
It looks like a GRE tunnel with heartbeats may be the only option.
Is your routing protocol running over the WAN link? If so does it involve adjacencies?
You may be able to get away with modifying your hello timers to get the neighbor torn down quicker, allowing traffic to route other ways if the carrier is down.
hey man ,
just run a dynamic routing protocol and adjust timers so that the dead interval arrives faster than normal ..even the links does not go down ..it wont get hello packets from other side ..and will declare this path as dead and then will take secondary route..this would surely help ..we did this in metro ethernet
The issue isn't the routing around the problem it is being able to detect the problem. The routing protocol is doing its job when the link goes down, but the Ethernet interface stays up. Therefore our network monitoring system can not detect the problem on the connection.
While you're correct that the ethernet interface stays up when there is a carrier line break, the loss of EIGRP or OSPF neighbor will prevent that link from being taken to any remote route.
The only route that will be affected is the connected route which the ethernet interface is sitting on. That is unless you're using static routes, which will forward based on next-hop reachability, in which case the first solution: pbr with tracking, is your best.
I just read this more carefully, and it sounds like you're less concerned with proper handling of traffic in the case of an error, but more concerned about your network monitoring being aware of it.
If that is the case, you're going to want to look into IP SLA. With this, you're router will constantly poll a remote host. If the polls timeout, you can configure it to generate an SNMP trap to alert your network monitor. More information here:
I have a similar situation.I configured GRE tunnels using the Ethernet interface as a reference. The GRE tunnels allow me to know when the circuit is down even though the Ethernet interface is up. Based on your situation, I really believe that GRE is the solution.
It allows you to better manage your devices as well as traffic. You can configure QoS if need be.
Let me know if it helps.