Trying to Understand TTL with Cisco Meraki
I have a client side capture of a cisco meraki sending me a reset packet for specific packets. The TTL for this packet is 250. However, for packets that do succeed and don't get reset the TTL is 127. I understand that cisco will increase the TTL to 256, but in comparison to the successful packets, there is only 1 hop. So I would expect 255 instead of 250.
The reason for the reset isn't super clear. What I know is that it was a false flag by snort. We resolved the reset issue, I'm only interested in the hops that I saw.
Can I infer that when cisco "processes" a packet, determine it's suspicious and sends a reset, that it can get decremented multiple times? Or is this flawed thinking?
I'm just trying to understand how this reset packet had 6 hops instead of 1. Even potential answers as the entire configuration isn't known. I was under the impression that whenever a packet is routed, the ttl is decremented. But we only have the client, meraki as the middle-man, and the server. My understanding is either flawed, or the meraki is routing the traffic multiple times "within itself".
Apologies, I am new to networking.
That Is flawed thinking, there's no proof that the reset packet is created with a TTL of 255 (that's the max, not 256). There's probably not even a hop, so most likely the reset packet is created with a TTL of 250.
Thanks for your response. I see my mistake on the 255 default cisco TTL. But if it's not hoping, why would it even be reduced to 250?
@SYN-bit mentions
ip.ttl= 250 here: RST packets sent by both client and server during file transferWell, I was looking for TTL=250 in combination with Meraki and that question popped up. So I looked at those pcap and it seems the Meraki has a default TTL of 250...