On 28/6/17 2:31 am, Youssef GHORBAL wrote:
[...]
Further, I would argue that round robin is not a valid 802.3ad/802.1AX
algorithm, per how it defines a frame distributor:
"This standard does not mandate any particular distribution
algorithm(s); however, any distribution algorithm shall ensure
[...]
> Further, I would argue that round robin is not a valid 802.3ad/802.1AX
> algorithm, per how it defines a frame distributor:
>
> "This standard does not mandate any particular distribution
> algorithm(s); however, any distribution algorithm shall ensure that,
> when frames are received by
On Tue, Jun 27, 2017 at 5:05 AM, Youssef GHORBAL
wrote:
>
> There is nothing in the 802.3ad that mandates stickiness of flows per NIC,
> the only thing explicit is that hash algorithm needs to maintain packet
> order. In this case, strictly speaking, it's : Packets do leave in "order"
> and do
> On 27 Jun 2017, at 12:54, sth...@nethelp.no wrote:
>
>> Imagine this set up :
>>
>> freebsd host port0 <-> switch 1 <-> linux host port0
>> freebsd host port1 <-> switch 2 <-> linux host port1
>>
>> On the linux box, port 0&1 are enslaved in a bond with a RR algorithm (Round
>> Robin)
>> On
> Imagine this set up :
>
> freebsd host port0 <-> switch 1 <-> linux host port0
> freebsd host port1 <-> switch 2 <-> linux host port1
>
> On the linux box, port 0&1 are enslaved in a bond with a RR algorithm (Round
> Robin)
> On the freebsd box, port 0&1 are enslaved in a lagg.
>
> switchs 1&
Imagine this set up :
freebsd host port0 <-> switch 1 <-> linux host port0
freebsd host port1 <-> switch 2 <-> linux host port1
On the linux box, port 0&1 are enslaved in a bond with a RR algorithm (Round
Robin)
On the freebsd box, port 0&1 are enslaved in a lagg.
switchs 1&2 are configured for
[...]
>>I've read about netisr work and I was under the impression that even
>> if it's SMP enabled it was made to keep prorocol ordering.
>>
>>What's the expected behaviour in this scenario on the netisr side ?
>>How can I push the investigation further ?
>
> I think yo
Out of curiosity, what sort of lagg setup are you using that's causing
the TCP packets to be split across the two lagg interfaces?
Matt
On Mon, Jun 26, 2017 at 1:35 PM, Navdeep Parhar wrote:
> On Thu, Jun 22, 2017 at 3:57 PM, Youssef GHORBAL
> wrote:
>> Hello,
>>
>> I'm having an issue
On Thu, Jun 22, 2017 at 3:57 PM, Youssef GHORBAL
wrote:
> Hello,
>
> I'm having an issue with a FreeBSD 11 based system, sending
> sporadically TCP/RST to clients after initial TCP session correctly initiated.
> The sequence goes this way :
>
> 1 Client -> Server : SYN
>
Hello,
I'm having an issue with a FreeBSD 11 based system, sending
sporadically TCP/RST to clients after initial TCP session correctly initiated.
The sequence goes this way :
1 Client -> Server : SYN
2 Server -> Client : SYN/ACK
3 Client -> Server : ACK
10 matches
Mail list logo