search for: fq_codel

...ing all the other flows, we end up with about 40ms of > induced delay on this test. While I have a better codel (gets below > 20ms latency, not deployed), *fq*_codel by identifying individual > flows gets the induced delay on those flows down below 5ms. But that should improve with ECN if fq_codel is configured to use that, right? > At one level, tinc being so nicely meshy means that the "fq" part of > fq_codel on the gateway will have more chance to work against the > multiple vpn flows it generates for all the potential vpn endpoints... > > but at another... look...

...ress type='pci' domain='0x0000' bus='0x0f' slot='0x00' function='0x0'/> </interface> # virsh start rhel Domain rhel started 2. login guest and check the interfaces: # ip addr ... 2: enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 00:0c:29:e7:9b:cb brd ff:ff:ff:ff:ff:ff inet 192.168.122.142/24 brd 192.168.122.255 scope global dynamic noprefixroute enp5s0 valid_lft 3584sec preferred_lft 3584sec inet6 fe80::351c:686a:863e:4a7f/64 scope link noprefixroute val...

...ws, we end up with about 40ms of >> induced delay on this test. While I have a better codel (gets below >> 20ms latency, not deployed), *fq*_codel by identifying individual >> flows gets the induced delay on those flows down below 5ms. > > But that should improve with ECN if fq_codel is configured to use that, > right? Meh. Ecn is very useful on very short or very long paths where packet loss as an indicator of congestion is hurtful. In the general case it adds a tiny bit to overall latency for other flows as congestion is not cleared for an RTT, instead of at the bottlenec...

I have long included tinc in the cerowrt project as a lighter weight, meshy alternative to conventional vpns. I sat down a few days ago to think about how to make vpn connections work better through fq_codel, and decided I should maybe hack on a vpn to do the job. So I picked up tinc's source code for the first time, got it working on IPv6 as a switch in a matter of minutes between two endpoints (very impressed, thx!), and started hacking at it to see where I would get. This is partially the outgr...

...of >>> induced delay on this test. While I have a better codel (gets below >>> 20ms latency, not deployed), *fq*_codel by identifying individual >>> flows gets the induced delay on those flows down below 5ms. >> >> >> But that should improve with ECN if fq_codel is configured to use that, >> right? >> >>> At one level, tinc being so nicely meshy means that the "fq" part of >>> fq_codel on the gateway will have more chance to work against the >>> multiple vpn flows it generates for all the potential vpn endpo...

...lt;LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group defaul t qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP grou p default qlen 1000 link/ether 42:dd:fe:41:26:2e brd ff:ff:ff:ff:ff:ff inet 206.189.47.8/20 brd 206.189.47.255 scope global eth0 valid_lft forever preferred_lft forever inet 10.15.0.10/16 brd 10.15.255.255 scope global eth0 valid_lft forever preferred_lft f...

...ense 2.4.4-RELEASE-p1 (amd64) on pfSense ***    LAN (lan) -> vtnet0 -> v4: 10.0.20.1/24 DEV tap0:    [root@server ~]# ip tuntap add tap0 mode tap    [root@server ~]# ip l set tap0 up    [root@server ~]# ip l show tap0    49: tap0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN mode DEFAULT group default qlen 1000        link/ether ce:9e:95:89:33:5f brd ff:ff:ff:ff:ff:ff    [root@server ~]# virsh start pfsense    [root@server opt]# ip l show tap0    49: tap0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN mode DEFAULT group def...

I'm deploying a CentOS 7 box as a gateway and I'm trying to figure out how to set up traffic shaping. Historically I've used the Wondershaper script but apparently it's not deprecated in favor of superior queue management. I haven't yet found a packaged solution and I'm wondering what others do to configure this kind of thing. Apparently the new modules are available

.../2014-December/000680.html but it was only two nights of hacking, then I had to go to something else. The original observation of mine was that we were bottlenecking on the tinc output stage, and dropping at the input stage, with about 30ms latency on the hardware I was trying - where I said AHA! fq_codel in vpnspace might be useful, might scale better to multiple cores, even... and then there was another AHA! when I realized the meshy bits of tinc could be mapped over a received /64 without exposing all that much over a single flow tinc.... making the vpn bits incur nearly zero delay for everything...

...OWN group default link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 90:2b:34:68:84:c0 brd ff:ff:ff:ff:ff:ff inet 192.168.1.8/24 brd 192.168.1.255 scope global enp5s0 valid_lft forever preferred_lft forever inet6 fe80::922b:34ff:fe68:84c0/64 scope link valid_lft forever preferred_lft forever 3: vi...

...> Address = 10.130.17.192 > Subnet = 10.3.0.50/32 > Port = 656 > > -----BEGIN RSA PUBLIC KEY----- > > The result I get when running ip a on either server only shows the first VPN > tunnel: > > 9: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel > state UNKNOWN group default qlen 500 link/none > inet 10.0.0.51/24 scope global tun0 > valid_lft forever preferred_lft forever Could this be as simple as a name conflict ("tun0" for both VPN setups)? The first VPN that comes up is now gainplus after changing details abov...

...default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether bc:ae:c5:02:c7:dc brd ff:ff:ff:ff:ff:ff inet 10.0.0.200/24 brd 10.0.0.255 scope global noprefixroute enp1s0 valid_lft forever preferred_lft forever inet6 fe80::beae:c5ff:fe02:c7dc/64 scope link noprefixroute valid_lft forever pre...

Guys, what i noticed. Look at this. Refused- 1/3/0 (Class 254) ( /24 ) Paully used /16 update 1/3/1 (Class 254) CNAME V-RDS02.mydomain.com CNAME ? And, if he uses in his example samba-tool dns add dc3 mydomain.com V-RDS02 A 130.130.0.252 A record was used. Is resolv.conf checked and it is sure in pointing to the correct DNS of the AD first? addresses: -

Hello, Dave Taht, on Wed 02 Dec 2015 13:21:56 +0100, wrote: > I'd made a start on the send direction here: > https://github.com/dtaht/tinc/commits/master > > Perhaps that will help. Well, converting a sendto call into a sendmsg call is not really "hard" :) What will be really hard is getting multiple packet receive/send over the tap/tun device, because support for it

...EGIN RSA PUBLIC KEY----- /etc/tinc/vpn1/hosts/db2 Address = 10.130.17.192 Subnet = 10.3.0.50/32 Port = 656 -----BEGIN RSA PUBLIC KEY----- The result I get when running ip a on either server only shows the first VPN tunnel: 9: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 500 link/none inet 10.0.0.51/24 scope global tun0 valid_lft forever preferred_lft forever regards Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20190520/...

...pfSense *** >    LAN (lan) -> vtnet0 -> v4: 10.0.20.1/24 > >DEV tap0: >    [root@server ~]# ip tuntap add tap0 mode tap >    [root@server ~]# ip l set tap0 up >    [root@server ~]# ip l show tap0 >    49: tap0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc >fq_codel state DOWN mode DEFAULT group default qlen 1000 >        link/ether ce:9e:95:89:33:5f brd ff:ff:ff:ff:ff:ff >    [root@server ~]# virsh start pfsense >    [root@server opt]# ip l show tap0 >    49: tap0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc >fq_codel state DOWN mo...

...gt; eno4????? <<----- THIS IS UNWANTED > ?????? valid_lft 604778sec preferred_lft 604778sec > ??? inet6 fe80::9257:5654:b211:8dea/64 scope link noprefixroute > ?????? valid_lft forever preferred_lft forever > 7: enp5s0f0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel > state DOWN group default qlen 1000 > ??? link/ether 00:15:17:59:96:44 brd ff:ff:ff:ff:ff:ff > 8: enp5s0f1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel > state DOWN group default qlen 1000 > ??? link/ether 00:15:17:59:96:45 brd ff:ff:ff:ff:ff:ff > 11: wwp0...

...55 scope global dynamic eno4????? <<----- THIS IS UNWANTED ?????? valid_lft 604778sec preferred_lft 604778sec ??? inet6 fe80::9257:5654:b211:8dea/64 scope link noprefixroute ?????? valid_lft forever preferred_lft forever 7: enp5s0f0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000 ??? link/ether 00:15:17:59:96:44 brd ff:ff:ff:ff:ff:ff 8: enp5s0f1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000 ??? link/ether 00:15:17:59:96:45 brd ff:ff:ff:ff:ff:ff 11: wwp0s29f7u1i4: <POINTOPOINT,MUL...

...al br2 valid_lft forever preferred_lft forever inet6 2001:db8:ca2:3::1/64 scope global valid_lft forever preferred_lft forever inet6 fe80::5054:ff:feb0:ac5/64 scope link valid_lft forever preferred_lft forever 12: br2-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master br2 state DOWN group default qlen 1000 link/ether 52:54:00:b0:0a:c5 brd ff:ff:ff:ff:ff:ff *********** virsh net-list --all shows: Name State Autostart Persistent ---------------------------------------------------------- private2 active y...

...fferbloat site suggests that the later "cake" module will be even better, but it requires a newer kernel than CentOS currently ships with. <https://lists.fedoraproject.org/pipermail/devel/2015-March/209508.html> # 51-bufferbloat.conf # Address bufferbloat net.core.default_qdisc = fq_codel