Re: new CARP implementation
Gleb Smirnoff wrote: Hello networkers, I'd like to present for review and early testing (for brave ones) a new CARP implementation. Super! I'll use it but am not brave enough for alpha. Maybe beta. :) Will this support multiple VHID per interface? Rudy ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Odd TCP RFC1323 Behavior
On Fri, Aug 12, 2011 at 2:43 PM, Chip Marshall wrote: > I've been digging into an issue with SSH throughput and > discovered that one of the servers involved isn't using RFC1323 > window scaling and timestamps. > > The server is running 7.3-RELEASE-p3, and has > net.inet.tcp.rfc1323 set to 1. > > When connecting out from the server, it sets both Window Scale > and TimeStamp options in the SYN packet and everything is fine. > > When a connection comes into the server with WS and TS set in > the SYN, the response varies. For port 53 (named) the SYN/ACK > has WS/TS options. For port 22 (sshd) the SYN/ACK does not have > WS/TS options, unless the connection is via lo0. > > ssh is OpenSSH_5.2p1, compiled from ports with default options. > > I'm really at a loss to explain this. > > Why does named use RFC1323 on bce0 when sshd doesn't? > Why does sshd use RFC1323 on lo0 but not on bce0? > > I can provide PCAPs of the SYN, SYN/ACK exchanges if that > will help. Try installing security/openssh-portable from ports and enable the HPN patches. As it stands today, openssh locks the window size to a tiny value. This causes performance over wide area links to be simply terrible. Take a look at http://fasterdata.es.net/fasterdata/say-no-to-scp/ for more information on the issue. As you will see there, window scaling is the least of the performance issues with openssh. -- R. Kevin Oberman, Network Engineer - Retired E-mail: kob6...@gmail.com ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Odd TCP RFC1323 Behavior
I've been digging into an issue with SSH throughput and discovered that one of the servers involved isn't using RFC1323 window scaling and timestamps. The server is running 7.3-RELEASE-p3, and has net.inet.tcp.rfc1323 set to 1. When connecting out from the server, it sets both Window Scale and TimeStamp options in the SYN packet and everything is fine. When a connection comes into the server with WS and TS set in the SYN, the response varies. For port 53 (named) the SYN/ACK has WS/TS options. For port 22 (sshd) the SYN/ACK does not have WS/TS options, unless the connection is via lo0. ssh is OpenSSH_5.2p1, compiled from ports with default options. I'm really at a loss to explain this. Why does named use RFC1323 on bce0 when sshd doesn't? Why does sshd use RFC1323 on lo0 but not on bce0? I can provide PCAPs of the SYN, SYN/ACK exchanges if that will help. -- Chip Marshall http://weblog.2bithacker.net/ KB1QYWPGP key ID 43C4819E v4sw5PUhw4/5ln5pr5FOPck4ma4u6FLOw5Xm5l5Ui2e4t4/5ARWb7HKOen6a2Xs5IMr2g6CM pgppV7HnTM9AZ.pgp Description: PGP signature
panic: m_uiotombuf: progress != total
Hi. Just after upgrade from 8.2 to 9.0 kernel panics: panic: m_uiotombuf: progress != total cpuid = 1 KDB: enter: panic [ thread pid 1194 tid 100132 ] Stopped at kdb_enter+0x3b: movq$0,0x913242(%rip) db> bt Tracing pid 1194 tid 100132 td 0xfe0005c8f8c0 kdb_enter() at kdb_enter+0x3b panic() at panic+0x180 m_uiotombuf() at m_uiotombuf+0x142 sosend_generic() at sosend_generic+0x2c8 kern_sendit() at kern_sendit+0x191 sendit() at sendit+0xdc sendmsg() at sendmsg+0x87 syscallenter() at syscallenter+0x1aa syscall() at syscall+0x4c Xfast_syscall() at Xfast_syscall+0xdd --- syscall (28, FreeBSD ELF64, sendmsg), rip = 0x8019ad33c, rsp = 0x7fffd8f8, rbp = 0x7fffd930 --- ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: tcp failing to recover from a packet loss under 8.2-RELEASE?
Hi, On Thu, Aug 11, 2011 at 9:54 AM, Slawa Olhovchenkov wrote: > On Thu, Aug 11, 2011 at 11:33:37PM +1000, Lawrence Stewart wrote: > >> >>> Autotunig w/o limits is bad idea. This is way to DoS. >> >> >> >> Depends how it is implemented. With appropriate backpressure mechanisms >> >> put in place, it could be perfectly safe. I envisage reassembly segments >> >> being at the bottom of the heap in terms of importance, so if a machine >> >> were to come under memory pressure, they would be the first thing to be >> >> reclaimed. TCP would continue to operate if they got pulled out from >> >> under the connection as the protocol doesn't consider segments held in >> >> reassembly to have been delivered, so would recover via retransmission. >> > >> > Yes, TCP would continue to operate. But attacker don't allow to put >> > system under memory pressure. >> >> Without a concrete patch to discuss, let's just agree to disagree for >> the time being. FreeBSD does a fairly good job autoscaling and reacting >> to pressure with the VM subsystem for example. I don't see why we >> can't > > Yes, and VM system allow to set different memory limits for proccess (and now > for jails). > >> become good at doing it with the netstack. Manual tuning sucks and can >> be just as dangerous if you tune things up to get performance, which >> opens you up to the same problems. > > Autoscaling with limits is good. > Automatic computation of limits (from available resources) also is > good (currently limits frequently to small for modern installation, > but don't remember about embeded systems). > All the useless limitation BSD puts all over the place wrt. memory management is a huge pain to deal with. nmbcluster, zone limitation and friend are just useless. Just try to use NetGraph with a consequent number of nodes and a high enough pps and the stuff with will start dropping packet all over the place, even if the box has Gigs of free memory. - Arnaud ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
