On (05/03/17 13:09), Paul Wouters wrote: > I'm not familiar with those acronyms, and do not understand what > "retaining entropy" means.
entropy: see, for example, the figure in http://www.brocade.com/content/html/en/brocade-validated-design/brocade-ip-fabric-bvd/GUID-2CCB485C-96B8-4D18-AF70-2EF7EEC33C95.html There are 4 equal cost paths between a node in rack1 and a node in rack2 (because you go up to the leaf, and there are 4 spine switches to choose from). (and the attractive property of the spine-leaf, aka CLOS, architecture, is that you can scale this easily by adding more spine switches, so it grows easily) So for things like vxlan etc (basically anything that tunnels over udp, including RoCE) the recommendation is to randomize the udp src port. The switches calculate a hash based on the udp (saddr, sport, faddr, fport) 4-tuple/flow, and will spread flows across the 4 available paths. The hash will stay the same for any given flow so packets will not get re-ordered within the flow. The 4-tuple is provides the "entropy". https://tools.ietf.org/html/draft-ietf-nvo3-dataplane-requirements-03 Entropy can come from other sources as well, e.g., from the mpls label: https://datatracker.ietf.org/doc/rfc6790/?include_text=1 IPv6 flow id, or, even SPI: https://tools.ietf.org/html/draft-herbert-gue-00 BTW, even in tunnel mode, you can have traffic from different tenants taking different spine paths by giving them either different udp sports, or by giving them different SPIs.. Retaining entropy: if I send my udp traffic in the clear, each sport can be used to get a different spine path. After IPsec, without PFP, unless the client does an explicit bind (which most clients dont) the sadb/spd end up being something like *.5001 or 5001.*, so you end up clumping all the sports into 2 SPIs, thereby losing parallelism. --Sowmini _______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
