Hi Paul, I had previously (like you) the hash-key stuff configured on some MX80 gear, and removed it after reading David Roy's answer.
I can confirm that the removal of this stuff left the tfeb in a strange state (running 11.4R5), with some funny logs at the commit (tfeb0 jnh_loadbalance_hashkey(538): Unsupported Hash Mode:4, Flags:0x1 received, tfeb0 jnh_loadbalance_hashkey(538): Unsupported Hash Mode:11, Flags:0x0 received), and a buncha "No" instead of the "Yes" I was looking for in the "show jnh lb" results. I added some enhanced-hash-key options, commited, removed them, commited, and the Hash status was finally fine with the proper default Yes at the proper places... A bit rough and unpolished I guess :) Olivier Le 23 oct. 2012 à 17:56, Paul Vlaar a écrit : > Hi Magno, > > that clarifies things a bit more for me, thank you. > > However, am I right to conclude that I still need the hash-key stanza > for our 11.2 MX80s to make IPv6 source/destination hashing work for load > balancing? > > As for what I am trying to do, well, that is pretty simple. We have ECMP > for a number of IPv4 /32 and IPv6 /128 addresses setup via BGP within > our own network, to 32 servers. We want to have load balancing across > these servers for these addresses, and the hashing algorithm should > cause UDP to be distributed per packet, but TCP to be distributed > according to a src_ip:src_port:dst_ip:dst_port hash. > > Thank you, > > ~paul > > On 23/10/12 5:12 PM, magno wrote: >> Hi Paul! >> >> Leaving the hash-key stanza enabled for MX80 leaves room to unexpected >> behaviours as you could observe yourself. _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
