Revision history [back]

I have a capture of a cisco meraki sending a reset packet for specific packets. The TTL for this packet is 250. However, for packets that do succeed and don't get reset its 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.

Can I infer that when cisco "processes" a packet, in this case determine its suspicious and send 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 have a capture of a cisco meraki sending a reset packet for specific packets. The TTL for this packet is 250. However, for packets that do succeed and don't get reset its 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.

Can I infer that when cisco "processes" a packet, in this case determine its it's suspicious and send 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 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 its 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.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 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 its 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.known. I was under the impression that whenever a packet is routed, the ttl is decremented. But with 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".

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 its 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 with 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".

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 its 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 with 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.

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 with 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.