Re: [WISPA] Redundant Connections

Fri, 13 Jan 2006 10:31:59 -0800

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/






















					Reply via email to