I think another problem is that most WISP gear lacks the proper *tools*
to troubleshoot and diagnose problems at layer2.
That's been one of my "beefs" for awhile with layer2 designs, as the
tools to monitor and test them aren't prevalent in networks that aren't
'metro.
A long time ago I proposed to Accedian's upper management that they come
out with a version of "rflo" but based on SPB. I wish someone would pick
up that torch. Sure, you'll have vendor lock in (which I am not a fan
of), but if the ITU/IEEE/ITF/whoever isn't going to design a standard
protocol to work with our types of networks... well, we have to do what
we have to dotoacquire and maintain acompetitive advantage.
josh reynolds :: chief information officer
spitwspots :: www.spitwspots.com
On 12/01/2014 08:01 AM, Mark Radabaugh via Af wrote:
It�s a tough one. MEF/ITU/IEEE Ethernet standards do have a lot of
the mechanisms from SONET that allows you to specify reversion time on
circuits to limit damage from flapping.
Performant was the only one who seems to have tried to do anything
with automated bandwidth detection and making forwarding decisions.
Unfortunately it�s such a niche market that I doubt there was an
economic case for it. Everyone else just throws fiber and bandwidth
at the problem.
WISP�s have a somewhat unique problem in that it�s very easy for us to
make mesh type backhaul networks yet difficult to logically segment
the network at the Ethernet level. G8032.v2 attempts to solve the
issue but I don�t think there is a great deal of demand from the
bigger carriers for the mesh design given that bigger carriers can
just throw another fiber or wavelength at the problem to segregate the
network.
Mark
On Dec 1, 2014, at 11:43 AM, Josh Reynolds via Af <af@afmug.com
<mailto:af@afmug.com>> wrote:
I've never seen a protocol that handled flapping well :/
I really wish somebody would design a routing protocol with
extensions fordetermining bandwidth tho (sound familiar? :/ )
josh reynolds :: chief information officer
spitwspots ::www.spitwspots.com
On 12/01/2014 07:03 AM, Mark Radabaugh via Af wrote:
The biggest issue we have with MSTP is the inability to deal with
unstable links. �A high capacity backhaul flapping is disastrous
with MSTP due to the constant bridge table flushing. �G.8032
should be able to deal with this type of failure more gracefully.
�I think MPLS also has ways of dealing with it but I have not
investigated that route as much of our existing equipment does not
support MPLS. � We have to deploy new equipment at the tower sites
so MPLS would be an option, but so far we are thinking MEF over MPLS
solutions.
Mark
On Dec 1, 2014, at 10:55 AM, Josh Reynolds via Af <af@afmug.com
<mailto:af@afmug.com>> wrote:
This info may be a bit outdated with MSTP, I haven't looked, but it
used to be that the size of your tree should beno larger than 7 nodes.
josh reynolds :: chief information officer
spitwspots ::www.spitwspots.com
On 12/01/2014 01:50 AM, Forrest Christian (List Account) via Af wrote:
Do you really need something faster than one of the spanning tree
variants?
The topology at Montana Internet is to have a layer 3 switch at
each site and a big flat rapid spanning tree ring for all of the
OSPF speaking layer 3 switches (Aka routers) to talk on. � If I
yank a ring cable, I lose about a second on two is all.
-forrest
On Sun, Nov 30, 2014 at 11:11 PM, Scott Vander Dussen via Af
<af@afmug.com <mailto:af@afmug.com>> wrote:
Looking to add Ethernet ring protection switching into our
network.� I've attached a PDF demonstrating the topology of
the test tower set.� I'm leaning toward a G.8032v2
implementation simply because it's ITU standards based and not
vendor specific.� Other options include Brocade MRP, Moxa
Turbo Chain, etc.� Any shared wisdom would be greatly
appreciate before we get ourselves pot committed.
Scott
