LAGs can balance IPSec because the SPI is cafefully placed in the same
location as the UDP / TCP port numbers, so if the LAG recognizes the
protocol type (which most do), it can use the SPI just teh way it uses
the port numbers.
Yes, it is a hack. It is an OLD hack.
Yours,
Joel
On 4/27/2020 10:54 PM, Michael Richardson wrote:
Joel M. Halpern <[email protected]> wrote:
> I suspect that for most GRASP purposes, even if there is a layer 2
network
> between the parties, we are not much worried about how LAG handles GRASP
> packets? If we care about that, then the source port should be
randomized
> between flows, and stable for sequences of related messages.
The idea being that the different 5-tuples would wind up on different links
of the LAG, correct?
Brian E Carpenter <[email protected]> wrote:
> I think we don't care, because GRASP traffic density should be quite
> modest so load balancing isn't really an issue. In response to Michael,
> I don't think the source port matters at all for M_FLOOD messages. My
> code uses the o/s default, but it has no significance to the
> recipient.
I agree with Brian: the DULL message is basically just a probe sent every few
seconds. The bulk traffic would run over IPsec, so there will be an ESP SPI#.
How would a LAG flow balancer deal with that? I don't think it would balance
at all unless two SAs were negotiated. I think that the flow header could
also be tweaked in some kind of round robin fashion.
But, if it's a MC-LAG, then the ACP really wants to see both chassis
seperately. So it occurs to me that we could hack LACP rather than LLDP :-)
It appears that it uses a specific multicast destination.
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
