[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference npss::gigaswitch

Title:GIGAswitch
Notice:GIGAswitch/FDDI Jan 97 BL3.1 914.0 documentation 412.1ion 412.1
Moderator:NPSS::MDLYONS
Created:Wed Jul 29 1992
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:995
Total number of notes:4519

989.0. "Flooding destroys complete GIGAswitch ???????" by UTOPIE::BRAUN_R () Tue May 27 1997 07:59

    Hi all,
    
    since last weekend we are using Multiple Spanning Tree with Gigaswitch
    3.1 and two complete independent FDDI-rings. There are 5 GS connected
    to both LANs and everything is working perfectly. Now we are planning
    a disaster test and one point will be a flooding test with multicast 
    addresses generated by a SNIFFER or a WANDEL&GOLTERMANN in one
    of the LANs. This test (100% load) will destroy any communication
    on this LAN, but the cluster traffic (all nodes double-connected in
    both LANs) should do the failover to the other LAN (this works,
    tested with 2 independent FDDI-rings via concentrator).
    But with the GS we have common components in both LANs and the
    failover will, of course, work only, if there are no side effects
    to the other LAN. Traffic should be no problem (other logical bridge
    group), but what about the ability of the common SCP to handle
    this huge amount of multicast traffic ? I've heard of a restriction
    of about 3.000 frames/sec, our storm will be > 10.000 frames/sec.
    Will it affect also the forwarding ability for the other logical
    bridge group (this would be a disaster, as the clusters would crash,
    and our concept of two independent LANS would be damaged severly).
    
    There should be also a difference, if the SNIFFER is connected to
    one's GIGAswitch bridge port or if generated from a concentrator's
    port, thereby affecting ALL GIGAswitches and the whole backbone!!!!!!
    
    This test will be in the second week of June and we will get the
    results (even if they are disappointing). But nevertheless, we would
    like to have some pre-infos, assumptions, inputs for our test, previous
    test results,...
    
    
    Any help will be highly appreciated.
    
    Thanks,
    Ralph
T.RTitleUserPersonal
Name		DateLines
989.1In theory it should work.NPSS::SOLOWAYStu Soloway 226-7651Tue May 27 1997 11:1819
    We try very to make it impossible for an overload of flooded traffic on
    a subset of links to prevent flooding on other links.  In theory, this
    should work.  If there is a low rate of flooded traffic on the other
    spanning tree I would expect it to get through OK, but the latency
    should increase by a millisecond or two.  If there is a high rate of
    flooded traffic on the other spanning tree you should see the available
    flooding bandwidth allocated more or less evenly among the heavily-used
    incoming links.
    
    When you run this test I would suggest that you set the multicast rate
    limit to a very high number.  The rate limit is global, for all
    spanning trees, and if traffic is turned off due to the rate limit it
    will affect both spanning trees.  This would increase the latency on the
    non-offending spanning tree.
    
    Unfortunately, we have never run this particular test, so there is the
    possibility that you could run into something unforeseen.  But in
    theory it should work.
989.2NPSS::MDLYONSMichael D. Lyons DTN 226-6943Tue May 27 1997 15:3020
        Note that your test is not the worst case, and there is no reason
    to expect that your flooding test will cause any problems with unicast
    forwarding.  A worse case is when you apply that flooding load to
    multiple input ports.
    
        See the Digital Technical Journal article (note 174.3 for a
    pointer), particularly the section entitled "Limiting Malicious
    Influences" for a discussion on how and why the GIGAswitch/FDDI system
    has been designed to limit the problems caused by this type of attack.
    
        If you change the rate limits as Stu suggests, be certain that you
    change the appropriate rate limit.  There are separate rate limits for
    multicast and unknown destination address flooding.
    
        Note that the size of the flooded frames is quite significant.  If
    your intention is to tax the SCP as much as possible, use small frames. 
    If your intention is to exhaust the buffers used for multicast, use
    large frames.
    
    MDL
989.3UTOPIE::BRAUN_RWed May 28 1997 04:077
    Hi all,
    
    thanks for your input, we'll keep to up to date. Hopefully, we can
    do this extensive testing, as we have a limited timeframe on the
    weekend, due to production reasons.
    
    Ralph