LARTC - Oct 2000 - [daniel@netatonce.se: SV: TEQL: 2 Mbit eth1 + 2Mbit eth2 = 1Mbit teql0]

The logs are at http://www.bergqvist.se/teql/.

The speed is about 1.3Mbit/s.

Thanks,
Daniel
> -----Ursprungligt meddelande-----
> Från: lartc-admin@mailman.ds9a.nl
> [mailto:lartc-admin@mailman.ds9a.nl]För bert hubert
>
> Ok, then we need to go all out. Try this: tcpdump -i teql0 -w for.ahu, and
> run it while ftp-ing a file over teql0, end put this file online.
> Take care
> that there is no confidential data in the file you are ftp-ing.
>
> If possible, try dumping eth0 and eth1 as well, simultaneously.
>
> I''ll take a look at the dump and see if anything is wrong.
>
> Regards,
>
> bert hubert

>> On Tue, Oct 10, 2000 at 02:12:25PM +0200, Daniel Bergqvist wrote:
>>
>> This will show you "tc -s qdisc ls"
>There is no packet loss both eth1 and eth2.
>
>> Can you check to see if you are running with reverse path
>> filtering enabled?
>> cat /proc/sys/net/ipv4/conf/eth0
>> cat /proc/sys/net/ipv4/conf/eth1
>
>All three (eth0,eth1,eth2) is off on both routers.
Ok, then we need to go all out. Try this: tcpdump -i teql0 -w for.ahu, and
run it while ftp-ing a file over teql0, end put this file online. Take care
that there is no confidential data in the file you are ftp-ing.

If possible, try dumping eth0 and eth1 as well, simultaneously.

I''ll take a look at the dump and see if anything is wrong.

Regards,

bert hubert

-- 
PowerDNS                     Versatile DNS Services  
Trilab                       The Technology People   
''SYN! .. SYN|ACK! .. ACK!'' - the mating call of the internet

On Tue, Oct 10, 2000 at 04:21:06PM +0200, Daniel Bergqvist
wrote:
> The logs are at http://www.bergqvist.se/teql/.
> 
> The speed is about 1.3Mbit/s.
There is lots of packetloss. Also, it is obvious from this dump that
lan_router is sending both over eth1 and eth2, but that the wan router is
only receiving on eth2, and not on eth1, or that your dump failed.

    lan_router_eth1         10-Oct-2000 16:16    73k  
    lan_router_eth2         10-Oct-2000 16:16    73k  
    lan_router_teql0        10-Oct-2000 16:16    42k  
    wan_router_eth1         10-Oct-2000 16:15     1k
    wan_router_eth2         10-Oct-2000 16:15    46k
    wan_router_teql0        10-Oct-2000 16:15   146k
  
lan_router_eth[12] carry ftp data, teql0 carries acknowledgements, and lots
of them are duplicate or triplicate, indicating packetloss and resends.

wan_router_eth1 receives almost nothing, while wan_router_eth2 is sees the
same the ACKs seen by teql0 on the lan_router, also duplicate.

wan_router_teql0 sees packets also seen by lan_router_eth1 and eth2, and
they are alternatingly from eth1 and eth2, which is as it should be.

10.2.18.2 is telling ftp2.citynet.nu that is is missing packets, so it
appears that data is getting lost on the other way. I''m not sure if
this is
related to TEQL.

I''m interested in knowing what you make of the nearly empty
wan_router_eth1
file.

Regards,

bert hubert

-- 
PowerDNS                     Versatile DNS Services  
Trilab                       The Technology People   
''SYN! .. SYN|ACK! .. ACK!'' - the mating call of the internet

On Tue, Oct 10, 2000 at 06:03:44PM +0200, bert hubert
wrote:
> On Tue, Oct 10, 2000 at 04:21:06PM +0200, Daniel Bergqvist wrote:
> > The logs are at http://www.bergqvist.se/teql/.
> > 
> > The speed is about 1.3Mbit/s.
> 
> There is lots of packetloss. Also, it is obvious from this dump that
> lan_router is sending both over eth1 and eth2, but that the wan router is
> only receiving on eth2, and not on eth1, or that your dump failed.

On second thought, there is no packet loss. This is expected behaviour, it
appears, see http://www.kernelnotes.de/kt/latest.html:

Alexey Kuznetsov was critical of this explanation, and said that multipath
routing worked "perfectly when you need to split load on servers talking to
enough large number of clients. Any
     http server is good example." He added that Andi''s suggestion
of the
existing eql, teql and bonding devices, would introcude "even worse problem
of strong tcp reordering. Actually,
     experiments show that load balancing works only in the situations, when
congestion window is bounded by 3 packets. If it is not made artificially,
it occurs automatically on each connection
     after some amount of excessive retransmissions. Total single TCP
connection throughput is never better in this case. Actually, it hints to
the thought that "true load blalancing" has to
     involve tracking connections and avoiding reordering TCP packets."
There was no reply to this, but there was a bit of implementation discussion
elsewhere, along the lines of Andi''s
     explanations. 

----

You might consider using google a bit to find out about packet reordering -
packets arrive out of sequence on eth1 and eth2, which the kernel interprets
as packetloss.

Regards,

bert hubert

-- 
PowerDNS                     Versatile DNS Services  
Trilab                       The Technology People   
''SYN! .. SYN|ACK! .. ACK!'' - the mating call of the internet

Now I understand why it doesn''t work.

I will look into it and try to find a solution.

Thanks for all help
Daniel
> -----Ursprungligt meddelande-----
> Från: lartc-admin@mailman.ds9a.nl
> [mailto:lartc-admin@mailman.ds9a.nl]För bert hubert
>
> On second thought, there is no packet loss. This is expected behaviour, it
> appears, see http://www.kernelnotes.de/kt/latest.html:
>
> Alexey Kuznetsov was critical of this explanation, and said that multipath
> routing worked "perfectly when you need to split load on servers
> talking to
> enough large number of clients. Any
>      http server is good example." He added that Andi''s
suggestion of the
> existing eql, teql and bonding devices, would introcude "even
> worse problem
> of strong tcp reordering. Actually,
>      experiments show that load balancing works only in the
> situations, when
> congestion window is bounded by 3 packets. If it is not made artificially,
> it occurs automatically on each connection
>      after some amount of excessive retransmissions. Total single TCP
> connection throughput is never better in this case. Actually, it hints to
> the thought that "true load blalancing" has to
>      involve tracking connections and avoiding reordering TCP
packets."
> There was no reply to this, but there was a bit of implementation
> discussion
> elsewhere, along the lines of Andi''s
>      explanations.
>
> ----
>
> You might consider using google a bit to find out about packet
> reordering -
> packets arrive out of sequence on eth1 and eth2, which the kernel
> interprets
> as packetloss.
>
> Regards,
>
> bert hubert
>
> --
> PowerDNS                     Versatile DNS Services
> Trilab                       The Technology People
> ''SYN! .. SYN|ACK! .. ACK!'' - the mating call of the
internet
>
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO:
http://ds9a.nl/2.4Routing/