-----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
