From: stephan on
Hi,

even though this is a weird config, but my customer
wants this:


a ring structure with 14 switches (29xx-class) in a chain.

------switch-----...----switch---|
| |
----------------------------------

.... stands for 12 (!) more switches.
every switch to switch connection is done by a microwave-p2p-link
with 4 to 8Mb bandwith.
All switches have an IP adress in the same subnet (vlan1).
Connected to every switch is 1 to 4 MS-server.
Traffic- and bandwithprofile of those servers: unknown

Yes, I know that this conflicts with about every rule I learned
in the past and I do not agree at all to do it this way.

Q:
What does the customer has to expect?
Will this ever come up?


--

thanks
joe
________________________________________
mailto:%79%65%6c%6c%6f%77%32%40%67%6d%78%2e%6e%65%74

From: Walter Roberson on
In article <6527c$480e2c23$544b0fc5$16821(a)news.hispeed.ch>,
stephan <banana.joe9(a)bluewin.ch> wrote:

>a ring structure with 14 switches (29xx-class) in a chain.

>------switch-----...----switch---|
>| |
>----------------------------------

>... stands for 12 (!) more switches.
>every switch to switch connection is done by a microwave-p2p-link
>with 4 to 8Mb bandwith.
>All switches have an IP adress in the same subnet (vlan1).

>Q:
>What does the customer has to expect?

If there is a single point to point failure, traffic will continue
to flow around the ring, possibly just having to take the long
way instead of the short route.

To find out whether this is an effective solution, one would
have to know the traffic patterns, the ETF (estimated time to failure),
whether failures are correlated (e.g., is the area prone
to hurricanes that might knock several links out of alignment?),
and the value that the customer places on maintaining connectivity.

If this is a closed private network, then going to a routing
protocol would be of benefit only to the extent that the routing
protocol might (if tuned properly) allow faster detection and
redirection than would otherwise be the case through Spanning Tree
Protocol.

Spanning Tree Protocol limits were traditionally given in terms
of number of hops, but with full duplex links, the -effective-
limit is on the latency of getting a query out from the potential
root node all the way to the furthest node and back again. You
don't happen to mention the distances involved in that microwave
link; if there is non-trivial latency involved, then the spanning
tree protocol might not be able to converge, in which case
a routing protocol would have to be used instead.
From: Bod43 on
On 23 Apr, 08:57, rober...(a)hushmail.com (Walter Roberson) wrote:
> In article <6527c$480e2c23$544b0fc5$16...(a)news.hispeed.ch>,
>
> stephan  <banana.j...(a)bluewin.ch> wrote:
> >a ring structure with 14 switches (29xx-class) in a chain.
> >------switch-----...----switch---|
> >|                                |
> >----------------------------------
> >... stands for 12 (!) more switches.
> >every switch to switch connection is done by a microwave-p2p-link
> >with 4 to 8Mb bandwith.
> >All switches have an IP adress in the same subnet (vlan1).
> >Q:
> >What does the customer has to expect?
>
> If there is a single point to point failure, traffic will continue
> to flow around the ring, possibly just having to take the long
> way instead of the short route.
>
> To find out whether this is an effective solution, one would
> have to know the traffic patterns, the ETF (estimated time to failure),
> whether failures are correlated (e.g., is the area prone
> to hurricanes that might knock several links out of alignment?),
> and the value that the customer places on maintaining connectivity.
>
> If this is a closed private network, then going to a routing
> protocol would be of benefit only to the extent that the routing
> protocol might (if tuned properly) allow faster detection and
> redirection than would otherwise be the case through Spanning Tree
> Protocol.
>
> Spanning Tree Protocol limits were traditionally given in terms
> of number of hops, but with full duplex links, the -effective-
> limit is on the latency of getting a query out from the potential
> root node all the way to the furthest node and back again. You
> don't happen to mention the distances involved in that microwave
> link; if there is non-trivial latency involved, then the spanning
> tree protocol might not be able to converge, in which case
> a routing protocol would have to be used instead.

As Walter has implied the network is over the
802.1d STP maximum network diameter of 8 bridges.

First of all check the current standards, there have been
a number of changes in STP e.g. Rapid STP, and perhaps
this limit has been changed in some of the new variants.

As far as I am aware there is nothing that actually
enforces the 8 hop limit and with your simple network
topology and with modern equipment I would expect
STP would be expected to behave correctly.
The one thing that would worry me would be the
reliability of the radio links and the interaction of
unreliable links with STP. If the links did drop
packets you could consider changing the timers
such that either more or fewer hellos were lost
before re-convergence occurred.

If STP did turn out to be a problem you could consider
finding some switches that did not do STP at all
and were transparent to the STP packets.
With your topology it is only necessary to have a single switch
running STP, all of the others just have to pass that
switches STP frames. I don't know what the
behaviour of Cisco switches might be with STP
disabled with regard to the forwarding of STP packets.

From: Walter Roberson on
In article <d5bcd7da-65b5-43e5-8db1-53dbcf84fd2a(a)m44g2000hsc.googlegroups.com>,
<Bod43(a)hotmail.co.uk> wrote:

>If STP did turn out to be a problem you could consider
>finding some switches that did not do STP at all
>and were transparent to the STP packets.
>With your topology it is only necessary to have a single switch
>running STP, all of the others just have to pass that
>switches STP frames. I don't know what the
>behaviour of Cisco switches might be with STP
>disabled with regard to the forwarding of STP packets.

My recollection (and I haven't looked for a couple of years) is
that proper switches "must not" transparently forward BPDU.

That said, I have encountered more than 1 inexpensive low port-count
switch totally unmanaged switch that ignored the existance of STP and
forwarded all packets including BPDU.

If you only have one switch actually doing STP then you have a
single point of failure in STP. If the problem is that that switch
drops out of communications (link dies, switch dies) then the ring
is broken and there is no loop. However, it has been known for
switches to fail locked into forwarding state (#$@# things!)
so single point of failure remains an issue.