Discussion:
[j-nsp] per-flow load balancing hash and ICMP traffic
Mark Miklic
2006-12-07 21:47:01 UTC
Permalink
Anyone knows how ICMP is being treated when layer-4 hash option (any of
them) is being turned on?

I was doing some tests today, and the only way I could ensure a consistent
path for MTR through the per-flow lb-ed network was to exclude layer-4
parameter hashing completely.

The only thing that comes to my mind is that Juniper introduces random
values if there is no layer-4 information in the datagram...Is there any
option to bypass this, or perhaps I am barking at the wrong tree?

Thanks,
Mark
Mark Miklic
2006-12-07 22:24:06 UTC
Permalink
Actually,

it is enough if I exclude source-port from the hash. This is even more
confusing... I thought mtr had nothing to do with layer-4 source ports and
such, being ICMP. Is perhaps the sequence number treated as the source port?
Any ideas?

Thanks,
Mark
Post by Mark Miklic
Anyone knows how ICMP is being treated when layer-4 hash option (any of
them) is being turned on?
I was doing some tests today, and the only way I could ensure a consistent
path for MTR through the per-flow lb-ed network was to exclude layer-4
parameter hashing completely.
The only thing that comes to my mind is that Juniper introduces random
values if there is no layer-4 information in the datagram...Is there any
option to bypass this, or perhaps I am barking at the wrong tree?
Thanks,
Mark
Mark Miklic
2006-12-07 22:43:14 UTC
Permalink
Ok, problem solved (thanks Ray;).

Seems like the source-port for layer-4 hash equals to datagram id for ICMP.
Really interesting...

Mark
Post by Mark Miklic
Actually,
it is enough if I exclude source-port from the hash. This is even more
confusing... I thought mtr had nothing to do with layer-4 source ports and
such, being ICMP. Is perhaps the sequence number treated as the source port?
Any ideas?
Thanks,
Mark
Post by Mark Miklic
Anyone knows how ICMP is being treated when layer-4 hash option (any of
them) is being turned on?
I was doing some tests today, and the only way I could ensure a
consistent path for MTR through the per-flow lb-ed network was to exclude
layer-4 parameter hashing completely.
The only thing that comes to my mind is that Juniper introduces random
values if there is no layer-4 information in the datagram...Is there any
option to bypass this, or perhaps I am barking at the wrong tree?
Thanks,
Mark
Rafał Szarecki
2006-12-08 10:11:19 UTC
Permalink
Mark,

It is interesting what U describe. I rather expect that removing
destination-port from hash will put all ICMP packet on same link.
If U configure 'source-port' actualy ASIC is look at first 2 Bytes after end
of IP Header. This 2 B for ICMP are TYPE and CODE field. So they will should
do not varry.
The destination-port is matching 3rd and 4th Byte, where ICMP has checksum.
and this value of course can varry. So use of this for hash, will result in
load-ballancing.

BTW as ASIC just takes some bytes form packet, they are protocol unaware.
And if in FirewallFilter you configure some 'destination-port' without
protocol (tcp/udp), it can results in matching of ICMP, raw IP or other
packets which has no port at leyer 4.
Post by Mark Miklic
Ok, problem solved (thanks Ray;).
Seems like the source-port for layer-4 hash equals to datagram id for ICMP.
Really interesting...
Mark
Post by Mark Miklic
Actually,
it is enough if I exclude source-port from the hash. This is even more
confusing... I thought mtr had nothing to do with layer-4 source ports
and
Post by Mark Miklic
such, being ICMP. Is perhaps the sequence number treated as the source
port?
Post by Mark Miklic
Any ideas?
Thanks,
Mark
Post by Mark Miklic
Anyone knows how ICMP is being treated when layer-4 hash option (any
of
Post by Mark Miklic
Post by Mark Miklic
them) is being turned on?
I was doing some tests today, and the only way I could ensure a
consistent path for MTR through the per-flow lb-ed network was to
exclude
Post by Mark Miklic
Post by Mark Miklic
layer-4 parameter hashing completely.
The only thing that comes to my mind is that Juniper introduces random
values if there is no layer-4 information in the datagram...Is there
any
Post by Mark Miklic
Post by Mark Miklic
option to bypass this, or perhaps I am barking at the wrong tree?
Thanks,
Mark
_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
--
Rafa? Szarecki JNCIE
+48602418971
Mark Miklic
2006-12-08 14:24:01 UTC
Permalink
Rafal,

indeed, your explanation is correct. I guess there is no bypassing it...

Thanks,
Mark
Post by Rafał Szarecki
Mark,
It is interesting what U describe. I rather expect that removing
destination-port from hash will put all ICMP packet on same link.
If U configure 'source-port' actualy ASIC is look at first 2 Bytes after
end of IP Header. This 2 B for ICMP are TYPE and CODE field. So they will
should do not varry.
The destination-port is matching 3rd and 4th Byte, where ICMP has
checksum. and this value of course can varry. So use of this for hash, will
result in load-ballancing.
BTW as ASIC just takes some bytes form packet, they are protocol unaware.
And if in FirewallFilter you configure some 'destination-port' without
protocol (tcp/udp), it can results in matching of ICMP, raw IP or other
packets which has no port at leyer 4.
Post by Mark Miklic
Ok, problem solved (thanks Ray;).
Seems like the source-port for layer-4 hash equals to datagram id for ICMP.
Really interesting...
Mark
Post by Mark Miklic
Actually,
it is enough if I exclude source-port from the hash. This is even more
confusing... I thought mtr had nothing to do with layer-4 source ports
and
Post by Mark Miklic
such, being ICMP. Is perhaps the sequence number treated as the source
port?
Post by Mark Miklic
Any ideas?
Thanks,
Mark
Post by Mark Miklic
Anyone knows how ICMP is being treated when layer-4 hash option (any
of
Post by Mark Miklic
Post by Mark Miklic
them) is being turned on?
I was doing some tests today, and the only way I could ensure a
consistent path for MTR through the per-flow lb-ed network was to
exclude
Post by Mark Miklic
Post by Mark Miklic
layer-4 parameter hashing completely.
The only thing that comes to my mind is that Juniper introduces
random
Post by Mark Miklic
Post by Mark Miklic
values if there is no layer-4 information in the datagram...Is there
any
Post by Mark Miklic
Post by Mark Miklic
option to bypass this, or perhaps I am barking at the wrong tree?
Thanks,
Mark
_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
--
Rafa? Szarecki JNCIE
+48602418971
Loading...