These are PTP wired links - 3 of them combined together - > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Tom DeReggi > Sent: Friday, January 13, 2006 1:32 PM > To: WISPA General List > Subject: Re: [WISPA] Redundant Connections > > Have you used that backhaul to carry one of your high end business client's > cisco VPNs? > Most people don't even know how to detect that packets are getting sent out > of order, and don't realize bandwidth is being wasted on packet drops. > The reason is the only way to know is to go into the logs of the end user's > VPN routers. Cisco VPN gear has some good tools to test the VPN and report > the loss. It was the tech company of the subscriber, that it brought it to > our attention and noticed it. And on $500 a month ARPU subs, if they see > something like that, it means cancellation, if it can't be resolved. The > reason is high end customers shoot for 100% not 99.9%. Andwhen things aren't > perfect, the smarter techs realize that a less than perfect link could > effect many different things that get troubleshooted over time, so the goal > is to make it perfect to rule it out from ever being a factor. If fiber can > make it perfect and wireless can't, wireless goes. That has been my > experience. > > So my question to you is... when you use Mikrotik for Per Packet load > balancing, does the Mikrotik, just guarantee that the packets arrive in > order, or does the Mikrotik correct any errors in the packets getting > received out of order, or are your links lucky to just be capable of > delivering the packets in order? Technically, if a radio has a buffer or > queue, its possible for the protocols to re-order the packets so they are > back in order by the time they leave the other end of the Mikrotik router. > At a small penalty of latency, re-ordering could be acheived. Its also > possible that the end user VPN protocols could also already take care of > that. I don't know enoguh about the VPN venders to know which protocols > self-correct/guarantee correct packet ordering. > > When using the per packet load balancing of theMikrotik, is the Mikrotik > also the radio, apposed to it be jsut the router connected Ethernet to > external radios of another brand. Its possible that without Ethernet > involved in between that they jsut get to the destination in order more > frequently. > > Running per packet load balancing is much more reliable over circuits with > fixed factors such as wired and fiber connections. In an RF enviroment its > a much different situation. There are many factors in RF that can cause a > packet to get delayed in delivery individually. For example an RF link that > automatically adjusts modulation when errors occur. Because two RF links may > transfer at different rates, the packets could arrive at different times. > > I did not specify previously, but when mentioning the risk of per packet > load balancing, I was referring to using it within an RF environment. And I > was referring to it being used for loadbalancing for a PtP link. Load > balancing per packet between two different ISP transit providers, also could > result in serious out of order packet problems, thus justifying per session > load balancing. > > A PTP wired link, very well may be a preferred method to use per packet load > balancing. > > Tom DeReggi > RapidDSL & Wireless, Inc > IntAirNet- Fixed Wireless Broadband > > > ----- Original Message ----- > From: <[EMAIL PROTECTED]> > To: "'WISPA General List'" <[email protected]> > Sent: Thursday, January 12, 2006 8:22 PM > Subject: RE: [WISPA] Redundant Connections > > > >I think it depends on the links involved and the remote termination, I > >currently > > run per packet round robin load balance across 3 T1's, no issue's with > > VoIP or > > VPN - of course the remote ends points are the same devices > > > >> -----Original Message----- > >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > >> Behalf > >> Of Tom DeReggi > >> Sent: Thursday, January 12, 2006 5:17 PM > >> To: WISPA General List > >> Subject: Re: [WISPA] Redundant Connections > >> > >> It important to consider the possibilties of packets arriving out of > >> order. > >> Some VPN protocols (deployed by corporate subscribers), will discard the > >> packets when they arrive out of order, and is almost as bad as packet > >> loss. > >> And VOIP quality can be degrated as well. Per session is preferred. > >> > >> Tom DeReggi > >> RapidDSL & Wireless, Inc > >> IntAirNet- Fixed Wireless Broadband > >> > >> > >> ----- Original Message ----- > >> From: "Paul Hendry" <[EMAIL PROTECTED]> > >> To: "'WISPA General List'" <[email protected]> > >> Sent: Thursday, January 12, 2006 3:22 PM > >> Subject: RE: [WISPA] Redundant Connections > >> > >> > >> > Running a EoIP tunnel across both the T1 and your link you should be > >> > able > >> > to > >> > load-balance across both links for incoming and outgoing traffic by > >> > bonding > >> > both EoIP interfaces at the customer site and your Mikrotik box. I have > >> > done > >> > this in the past but it has been across a couple of wireless links with > >> > similar round trip delays. If you use per-packet load balancing there > >> > may > >> > be > >> > issues with packets arriving out of order but if you do it per session > >> > it > >> > should work fine. With per session load balancing you won't get an > >> > aggregate > >> > throughput of both links with a single stream but should use both links > >> > if > >> > multiple streams are flowing. > >> > > >> > Cheers, > >> > > >> > P. > >> > > >> > -----Original Message----- > >> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > >> > Behalf Of John Scrivner > >> > Sent: 12 January 2006 19:11 > >> > To: [email protected] > >> > Subject: [WISPA] Redundant Connections > >> > > >> > A little feedback from the collective is appreciated here. I have a > >> > high > >> > school who has bought a connection from me but is also stuck with an > >> > old > >> > T1 circuit under contract for the next 3 years. They want both > >> > connections to be used all the time and for all traffic to > >> > automatically > >> > go through the working connection if one fails. Basically they want > >> > load > >> > balancing and failover. All addresses are nat'd private space IPs. I > >> > would think I should be able to do this with Mikrotik and/or Star OS > >> > but > >> > I do not know how. Your thoughts and or other suggestions are highly > >> > appreciated. If only failover or only load balance is possible then > >> > suggestions on that are welcome also. By the way, the T1 provider is > >> > not > >> > me and will likely not work with me unfortunately. We have to leave > >> > their network settings intact. > >> > Scriv > >> > > >> > -- > >> > WISPA Wireless List: [email protected] > >> > > >> > Subscribe/Unsubscribe: > >> > http://lists.wispa.org/mailman/listinfo/wireless > >> > > >> > Archives: http://lists.wispa.org/pipermail/wireless/ > >> > > >> > -- > >> > No virus found in this incoming message. > >> > Checked by AVG Free Edition. > >> > Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: > >> > 11/01/2006 > >> > > >> > > >> > -- > >> > No virus found in this outgoing message. > >> > Checked by AVG Free Edition. > >> > Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: > >> > 11/01/2006 > >> > > >> > > >> > -- > >> > WISPA Wireless List: [email protected] > >> > > >> > Subscribe/Unsubscribe: > >> > http://lists.wispa.org/mailman/listinfo/wireless > >> > > >> > Archives: http://lists.wispa.org/pipermail/wireless/ > >> > >> -- > >> WISPA Wireless List: [email protected] > >> > >> Subscribe/Unsubscribe: > >> http://lists.wispa.org/mailman/listinfo/wireless > >> > >> Archives: http://lists.wispa.org/pipermail/wireless/ > >> > >> > >> -- > >> No virus found in this incoming message. > >> Checked by AVG Free Edition. > >> Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: > >> 01/11/2006 > >> > > > > -- > > No virus found in this outgoing message. > > Checked by AVG Free Edition. > > Version: 7.1.371 / Virus Database: 267.14.17/227 - Release Date: > > 01/11/2006 > > > > > > -- > > WISPA Wireless List: [email protected] > > > > Subscribe/Unsubscribe: > > http://lists.wispa.org/mailman/listinfo/wireless > > > > Archives: http://lists.wispa.org/pipermail/wireless/ > > -- > WISPA Wireless List: [email protected] > > Subscribe/Unsubscribe: > http://lists.wispa.org/mailman/listinfo/wireless > > Archives: http://lists.wispa.org/pipermail/wireless/ > > > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.1.371 / Virus Database: 267.14.17/228 - Release Date: 01/12/2006 >
-- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.17/228 - Release Date: 01/12/2006 -- WISPA Wireless List: [email protected] Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
