glennda Posted April 12, 2013 Posted April 12, 2013 (edited) Hello People, I would like to sanity check my and everybody in my offices thought process on this one. We have a client who intermittently see's the internet connection drop, We are always able to see the router on its internal and external addresses (both public). What we are not able to see is the Watchguard firewall on the other side of the router. (see attached image - IPS are not correct but just examples). During a period of outage the connection between the Cisco and the Watchguard goes down - a duplex mismatch maybe... no both set to 100 Full (already tried that). EDIT: The Watchguard is set to 100 Full, the Cisco auto as when set to 100 full too we got TTL expired in transit But what I have noticed is that if from my office I ping the cisco on both its external and internal public IP I get a TTL of 246 (which is correct as 9 router hops to the Cisco), from my office to the Watchguard the TTL is 54! So between the Cisco and the Watchguard which is a direct connection they are losing 192 hops somewhere. The other strange thing is to bring the line back up you can either reset the Watchguard OR the rad unit. Both of these devices bring the line up. Now in my head I am pointing at the Cisco being at fault for some bizarre reason. The ISP have gone away to look as to what could be causing the issue, but the guy i've been speaking with thinks it could be the firmware on the Rad unit. For anybody not familiar with the Rad unit its this EFM DSL Network Termination Unit LA-210 essentially a termination unit for the EFM line which basicly provides the facility to bond the (in this case) 4 pairs. Any body any ideas what else it could be? Am I right in thinking this is an issue with the cisco router? (model unknown). EDIT: could a mod change the title to Sanity check my thought process - Internet Connection Cisco Issue Edited April 12, 2013 by glennda
jamesreedersmith Posted April 12, 2013 Posted April 12, 2013 Just as a FYI TTL is nothing to do with Hops its to do with DNS caching time i believe https://en.wikipedia.org/wiki/Time_to_live
glennda Posted April 12, 2013 Author Posted April 12, 2013 (edited) Just as a FYI TTL is nothing to do with Hops its to do with DNS caching time i believe https://en.wikipedia.org/wiki/Time_to_live Depends if we are talking about TTL for DNS caching or TTL on IP Packets in my case i'm talking about the latter The time-to-live value can be thought of as an upper bound on the time that an IP datagram can exist in an Internet system. The TTL field is set by the sender of the datagram, and reduced by every router on the route to its destination. If the TTL field reaches zero before the datagram arrives at its destination, then the datagram is discarded and an ICMP error datagram (11 - Time Exceeded) is sent back to the sender. The purpose of the TTL field is to avoid a situation in which an undeliverable datagram keeps circulating on an Internet system, and such a system eventually becoming swamped by such "immortals". as it says its there to stop a packet floating round the internet space for ever if it cannot be routed to its destination. Edited April 12, 2013 by glennda
jamesreedersmith Posted April 12, 2013 Posted April 12, 2013 So what about a trace route to find the hops?
glennda Posted April 12, 2013 Author Posted April 12, 2013 So what about a trace route to find the hops? A trace is fine which is what is strange, but occasionally you get a TTL expired in transit. In my head I think the Cisco is doing something strange with its routes but I'm not a Cisco expert!
ConradJones Posted April 12, 2013 Posted April 12, 2013 (edited) TTL on a Ping result is exactly as @glennda describes. IGNORE(what cisco is it?) re-read model unknown! Edited April 12, 2013 by ConradJones
glennda Posted April 12, 2013 Author Posted April 12, 2013 yeah its not my Cisco but i'm trying to make sure i don't look a fool to my client!
ConradJones Posted April 12, 2013 Posted April 12, 2013 its difficult to say with out looking at it, it could be the cisco or it could be something as simple as an iffy cable. you need to go thing each thing methodically (not always easy, you don't always have an indentically configured everything lying aroung)
glennda Posted April 15, 2013 Author Posted April 15, 2013 Bad cable. I thought that but would it explain the TTL count increase? Toby
Destinova Posted April 15, 2013 Posted April 15, 2013 Can you post a traceroute to both the router and firewall? Also, have you compare the routing tables on both? Do a "show interfaces counters errors" on the Cisco device, and look for CRC or Frame errors.
glennda Posted April 15, 2013 Author Posted April 15, 2013 Can you post a traceroute to both the router and firewall? Also, have you compare the routing tables on both? Do a "show interfaces counters errors" on the Cisco device, and look for CRC or Frame errors. I don't have access to the Cisco - its supplied by the ISP - from what the engineer says there is no Packet errors or duplex miss matches. I am getting the cables swapped out tomorrow although they have been replaced already. I'm not sure if it is the config they have on there cisco's but I have just checked one of the others and it does exactly the same. Ping to router directly TTL=246 ping to firewall behind it TTL=54! Bizarre - the traces don't show anything out of the ordinary (not even any time outs).
nelsons Posted May 2, 2013 Posted May 2, 2013 Sounds like a routing issue, unlikely to be a loop between the router and the FW as the packet gets there eventually. You will need some output from the ISP to determine the issue. At the very least ask for a show ip int brief | ex unass and also a show ip route and show int counters errors. HTH Steve CCIE#10055
glennda Posted May 2, 2013 Author Posted May 2, 2013 Sounds like a routing issue, unlikely to be a loop between the router and the FW as the packet gets there eventually. You will need some output from the ISP to determine the issue. At the very least ask for a show ip int brief | ex unass and also a show ip route and show int counters errors. HTH Steve CCIE#10055 It looks like the issue was to do with the EFM modem, it had pairs which where flakey and I think as they came up and down it was sending the router into a tizz. Should have updated!
nelsons Posted May 2, 2013 Posted May 2, 2013 Yip link flapping that would do it ! :-) Glad it's sorted.
Destinova Posted May 3, 2013 Posted May 3, 2013 Bad cable. I've been waiting to see if this one got resolved. Great news!
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now