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'" <wireless@wispa.org>
> 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'" <wireless@wispa.org>
> >> 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: wireless@wispa.org
> >> > 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: wireless@wispa.org
> >> >
> >> > 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: wireless@wispa.org
> >> >
> >> > Subscribe/Unsubscribe:
> >> > http://lists.wispa.org/mailman/listinfo/wireless
> >> >
> >> > Archives: http://lists.wispa.org/pipermail/wireless/
> >>
> >> --
> >> WISPA Wireless List: wireless@wispa.org
> >>
> >> 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: wireless@wispa.org
> >
> > Subscribe/Unsubscribe:
> > http://lists.wispa.org/mailman/listinfo/wireless
> >
> > Archives: http://lists.wispa.org/pipermail/wireless/
> 
> --
> WISPA Wireless List: wireless@wispa.org
> 
> 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: wireless@wispa.org

Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless

Archives: http://lists.wispa.org/pipermail/wireless/

Reply via email to