Re: [Anima] GRASP ALL_GRASP_NEIGHBORS

["Joel M. Halpern" <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]>, Sandelman Software Works
>   -= IPv6 IoT consulting =-
>