Re: trunk interface (was (no subject))
Am Donnerstag, den 18.05.2006, 18:05 -0700 schrieb Julian Elischer: > Thomas Vogt wrote: > > > Hi > > > > Thanks. I know about the netgraph ether/fec interfaces. But I thought > > about a solution without netgraph. AFAIK Netgraph implies overhead > > and ng_ehter is more complicated to set up. This is a problem with > > non technical people. I'm happy they already know a bit about > > ifconfig commands. > > > two items. > 1/ ng_fec only uses the config framework of netgraph. For data it goes > direct to the interfaces. Ah good to know. Since this is for a network course it would be easier if this "trunk" could be setup via ifconfig command. But I will try it. > 2/ netgraph is not that high an overhead. (what made you think it was?) Well I heard that netgraph has some overhead on various conferences. I'm planning to use such a feature on very very high loaded GigE router, every extra kernel hook could cost some performance, IMHO. Thanks and cheers, Thomas ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Can't delete route
On Thu, May 18, 2006 at 02:52:19PM -0300, Alexandre Biancalana wrote: > > > # route add 128.110.0.0 255.255.0.0 10.0.0.17 > > > add net 128.110.0.0: gateway 255.255.0.0 ... > > >Running netstat -nr I get the following: > > > > > > 0&0xa11255.255.0.0UGSc 15 332 fxp0 => ... > Have some way to remove this stupid route without flushing the routing > table ??? > This machine is main gateway of the company and I can't do a route flush > now, but I need to have this new route working... Try: # route delete -net 0.0.0.0 -netmask 10.0.0.17 (i.e. network 0, netmask &a11, like the netstat entry shows). I've tried it here, it successfully removes your junk route under 6.0 Regards, Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[SOLVED] Can't delete route
Brian Candler wrote: On Thu, May 18, 2006 at 02:52:19PM -0300, Alexandre Biancalana wrote: # route add 128.110.0.0 255.255.0.0 10.0.0.17 add net 128.110.0.0: gateway 255.255.0.0 ... Running netstat -nr I get the following: 0&0xa11255.255.0.0UGSc 15 332 fxp0 => ... Have some way to remove this stupid route without flushing the routing table ??? This machine is main gateway of the company and I can't do a route flush now, but I need to have this new route working... Try: # route delete -net 0.0.0.0 -netmask 10.0.0.17 (i.e. network 0, netmask &a11, like the netstat entry shows). I've tried it here, it successfully removes your junk route under 6.0 Great Brian !! It works on 4.10 too !! Thank you !! Alexandre Biancalana ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
improving transport over lossy links ?
I am looking for a way to improve the reliability of a lossy link (dialup from remote sites). I am going to try multilink PPP but was wondering if something like ng_one2many might work as well ? Does anyone have any suggestions for avenues to explore ? For multilink ppp, does mpd offer any better performance / reliability over the stock ppp ? The application is low bandwidth, but doesnt deal that well with packet loss and the phone lines in these remote locations tend to be noisy and drop connections frequently. ---Mike Mike Tancsa, tel +1 519 651 3400 Sentex Communications,[EMAIL PROTECTED] Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: improving transport over lossy links ?
On Fri, 19 May 2006 at 11:06:48 -0400, Mike Tancsa wrote: > I am looking for a way to improve the reliability of a lossy link > (dialup from remote sites). I am going to try multilink PPP but was > wondering if something like ng_one2many might work as well ? Does > anyone have any suggestions for avenues to explore ? For multilink > ppp, does mpd offer any better performance / reliability over the stock ppp ? No idea whether these options may help, but .. > The application is low bandwidth, but doesnt deal that well with > packet loss and the phone lines in these remote locations tend to be > noisy and drop connections frequently. If by 'drop connections' you mean physical loss of line / carrier, then tuning the modem/s to be (preferably much) less aggressive about forcing the modem connection rate high - ie being easily satisfied to drop back to lower rates during hard times - has helped a lot with a dozen or so remote spots hereaboots. Finding the knobs for some modems can be hard. Assuming that V.42 error correction is working properly - forced if need be - there shouldn't =be= any data loss, however slow getting through, this side of protocol timeouts of course. I can't guess your mystery application, but often slower connections are better than dropped ones, or even ones that spend half their time trying to retrain at high rates. cheers, Ian ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: improving transport over lossy links ?
At 12:06 PM 19/05/2006, Ian Smith wrote: Assuming that V.42 error correction is working properly - forced if need be - there shouldn't =be= any data loss, however slow getting through, this side of protocol timeouts of course. I can't guess your mystery application, but often slower connections are better than dropped ones, or even ones that spend half their time trying to retrain at high rates. Hi, Thanks for the reply. Even at 28.8 I am seeing loss with the connection dropping and seeing dropped packets (e.g. May 19 12:04:43 soekris4801 ppp[3404]: tun0: Phase: 1: HDLC errors -> FCS: 1, ADDR: 0, COMD: 0, PROTO: 0) Error correction is on and negotiated, from the terminal server's perspective at least and I imagine the modem too Testing here at the office Card Type: LU1674 Chipset State: ACTIVE Active Port: S26 Transmit Rate: 28800 Receive Rate: 26400 Connection Type: LAPM/V42BIS Chars Sent: 215666023 Chars Received: 58090941 Retrains: 0 Renegotiations: 4 The application is TCP based and monitors remote machinery. (And no, there is no chance at this point to re-write the application). The transport is over a VPN (either IPSEC or OpenVPN) which ever deals better with the lossy connection. However, many of the sites have dynamic IP addresses which makes it a pain to use with IPSEC and FreeBSD. One think I observed with multi-link so far is that if I kill one of the connections, the modem does not tell ppp that it has lost carrier right away. Instead, I have to wait for the LCP echo timeout. In the mean time, I get 50% packet loss for about 20 seconds. However I can reduce that by setting the lqrperiod to a lower value. However, I dont want that too low, otherwise it spends all its time chewing up the link with LCP traffic. I was going to look at the one2many ng module to see if I can send out the same packets on both links at the same time as a sort of "as long as one packet gets there strategy" Although the customer doesnt use wireless right now, we might have some sites that would need it in the fture and this might be an approach. I imagine satellite users run into this as well no ? ---Mike ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: improving transport over lossy links ?
Ian Smith wrote: On Fri, 19 May 2006 at 11:06:48 -0400, Mike Tancsa wrote: > I am looking for a way to improve the reliability of a lossy link > (dialup from remote sites). I am going to try multilink PPP but was > wondering if something like ng_one2many might work as well ? Does > anyone have any suggestions for avenues to explore ? For multilink > ppp, does mpd offer any better performance / reliability over the stock ppp ? No idea whether these options may help, but .. mpd does well, bit keep the mtu on the interface relatively small if you have a lot of line noise. I have not tried ppp with multilink. > The application is low bandwidth, but doesnt deal that well with > packet loss and the phone lines in these remote locations tend to be > noisy and drop connections frequently. If by 'drop connections' you mean physical loss of line / carrier, then tuning the modem/s to be (preferably much) less aggressive about forcing the modem connection rate high - ie being easily satisfied to drop back to lower rates during hard times - has helped a lot with a dozen or so remote spots hereaboots. Finding the knobs for some modems can be hard. Assuming that V.42 error correction is working properly - forced if need be - there shouldn't =be= any data loss, however slow getting through, this side of protocol timeouts of course. I can't guess your mystery application, but often slower connections are better than dropped ones, or even ones that spend half their time trying to retrain at high rates. cheers, Ian ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: improving transport over lossy links ?
Julian Elischer wrote: Ian Smith wrote: On Fri, 19 May 2006 at 11:06:48 -0400, Mike Tancsa wrote: I am looking for a way to improve the reliability of a lossy link (dialup from remote sites). I am going to try multilink PPP but was wondering if something like ng_one2many might work as well ? Does anyone have any suggestions for avenues to explore ? For multilink ppp, does mpd offer any better performance / reliability over the stock ppp ? No idea whether these options may help, but .. mpd does well, bit keep the mtu on the interface relatively small if you have a lot of line noise. I have not tried ppp with multilink. Agreed. If you can live with doing so, using an MTU of around 512 worked pretty well back in the days that I was using a 19200 baud DOV (data over voice modem) that tended to experience line noise & hence packet drops when you got an incoming voice call; if you've got a high-noise environment, well, that would be similar. Of course, you should make sure that obvious fixes like replacing phone cabling or re-punching down the phone lines at your demarc (assuming you have 66 or 110 blocks) doesn't help. -- -Chuck ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: improving transport over lossy links ?
At 03:32 PM 19/05/2006, Chuck Swiger wrote: Agreed. If you can live with doing so, using an MTU of around 512 worked pretty well back in the days that I was using a 19200 baud DOV (data over voice modem) that tended to experience line noise & hence packet drops when you got an incoming voice call; if you've got a high-noise environment, well, that would be similar. Of course, you should make sure that obvious fixes like replacing phone cabling or re-punching down the phone lines at your demarc (assuming you have 66 or 110 blocks) doesn't help. Thanks, unfortunately, these are very remote sites in industrial and rural areas where xconnect boxes tend to be rusty posts. I will try a lower MTU size to see how it deals with errors. ---Mike ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: improving transport over lossy links ?
On Fri, 19 May 2006 at 12:38:31 -0400, Mike Tancsa wrote: > At 12:06 PM 19/05/2006, Ian Smith wrote: > > >Assuming that V.42 error correction is working properly - forced if need > >be - there shouldn't =be= any data loss, however slow getting through, > >this side of protocol timeouts of course. I can't guess your mystery > >application, but often slower connections are better than dropped ones, > >or even ones that spend half their time trying to retrain at high rates. > > Hi, > Thanks for the reply. Even at 28.8 I am seeing loss with > the connection dropping and seeing dropped packets (e.g. > May 19 12:04:43 soekris4801 ppp[3404]: tun0: Phase: 1: HDLC errors -> > FCS: 1, ADDR: 0, COMD: 0, PROTO: 0) A lot of those, Mike, or just 1 FCS error per connection? I'm using a modem right now that often reports just 1 FCS upon linkup, then works fine for the day. Ah, 'often' includes this call I'm on now since: May 19 22:31:33 paqi ppp[2559]: tun0: Phase: deflink: HDLC errors -> FCS: 1, ADDR: 0, COMD: 0, PROTO: 0 .. so on its own that mightn't indicate much but maybe a chipset HDLC bug, but bunches of these are most often seen (inbound) where a caller negotiates a non-EC connection at 14400 or more; they rarely last long. Even then, FCS errors indicate link-level packet retries, not drops. Line loss is more likely physical, poor signal to noise over too long a time for desired line quality, which factors may well be tunable, at either end. I suppose the calling modems are a variety of types, and you've really only any control over the inbound modem config? > Error correction is on and negotiated, from the terminal server's > perspective at least and I imagine the modem too A lot depends on the calling modems of course .. some do, some don't. > Testing here at the office > > Card Type: LU1674 Chipset > State: ACTIVE >Active Port: S26 > Transmit Rate: 28800 > Receive Rate: 26400 >Connection Type: LAPM/V42BIS > Chars Sent: 215666023 > Chars Received: 58090941 > Retrains: 0 > Renegotiations: 4 Depends how long a call that represents I guess; it wouldn't look too shabby here, but we average less than 1GB/mth with ~3-5 redials/mth. Retrains 0, Rate renegs 4 over 215Mb doesn't look problematic. > The application is TCP based and monitors remote machinery. (And no, > there is no chance at this point to re-write the application). The > transport is over a VPN (either IPSEC or OpenVPN) which ever deals > better with the lossy connection. However, many of the sites have > dynamic IP addresses which makes it a pain to use with IPSEC and FreeBSD. Well if you redial a lost connection (-ddial etc) and regain the same IP address, TCP should chug on fine, ie remain lossless, while delayed. If not, open (link) TCP connections are shot, if that's the lossy you mean? > One think I observed with multi-link so far is that if I kill one of > the connections, the modem does not tell ppp that it has lost carrier > right away. Instead, I have to wait for the LCP echo timeout. In the > mean time, I get 50% packet loss for about 20 seconds. However I can > reduce that by setting the lqrperiod to a lower value. However, I > dont want that too low, otherwise it spends all its time chewing up > the link with LCP traffic. Mmm, 50% loss sounds about right for half the link :) Sorry, I've only a vague idea how multilink PPP works, getting way out of my depth here. 20 seconds sounds about right for successful redial / negotiation, but why isn't modem !DCD telling ppp right away? Is that a config issue? > I was going to look at the one2many ng module to see if I can send > out the same packets on both links at the same time as a sort of "as > long as one packet gets there strategy" Although the customer doesnt > use wireless right now, we might have some sites that would need it > in the fture and this might be an approach. I imagine satellite users > run into this as well no ? ng_one2many looks great, but there's still its Link Failure Detection to satisfy, which still has to come back to noticing modem !carrier, no? (Satellite users run into everything at some stage; weather, sunspots .. we replaced one with ADSL last year. ssh over sat was pretty tedious, even with 128k ISDN back. Outside wifi can get soggy in the wet, too!) cheers, Ian ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: trunk interface (was (no subject))
Thomas wrote: Am Donnerstag, den 18.05.2006, 18:05 -0700 schrieb Julian Elischer: Thomas Vogt wrote: Hi Thanks. I know about the netgraph ether/fec interfaces. But I thought about a solution without netgraph. AFAIK Netgraph implies overhead and ng_ehter is more complicated to set up. This is a problem with non technical people. I'm happy they already know a bit about ifconfig commands. two items. 1/ ng_fec only uses the config framework of netgraph. For data it goes direct to the interfaces. Ah good to know. Since this is for a network course it would be easier if this "trunk" could be setup via ifconfig command. But I will try it. 2/ netgraph is not that high an overhead. (what made you think it was?) Well I heard that netgraph has some overhead on various conferences. I'm planning to use such a feature on very very high loaded GigE router, every extra kernel hook could cost some performance, IMHO. it is possible that the extra overhead in netgraph may influence such a high throughput system, but one would have to test to know how much.. its overhead is nto as high as one might think, despite the fact that it was not designed to handle such high throughputs, it does a reasonable job. it is possible that the use of netisr() in some places slows it down however.. Thanks and cheers, Thomas ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
