Conference 7.286::fddi

    I just heard from someone who uses these bridges all the time that this
    is a known "implementation decision" (is this new DEC-speak for **BUG**!?)
    
    So, the default filtering only works inbound which is consistent with
    what I am seeing.
    
    So, I'm screwed.
    
    Just out of curiousity, can anyone come up with a scenario where the
    way it currently works is useful?

From the application point of view it makes no difference -- if the protocol
is blocked even one way, no communication is possible.  So if the goal is to
prevent communication by DECnet, this will do it.

If the goal is to minimize traffic from protocols you don't want, then this
does part of the job but not all of it.  Depending on how the nodes are
distributed, it may do nearly all.

I don't remember this particular decision, but as a guess it was done because
the processor that's doing the filtering on the FDDI side is (a) very hard
to program (it's a 2900 bitslice machine) and (b) very short on time (it has
to handle 450,000 packets per second).  Thus the "design decision".

	paul

    >> I just heard from someone who uses these bridges all the time that this
    >> is a known "implementation decision" (is this new DEC-speak for **BUG*?)
    
    No, it's not a bug. The original developer designed the bridge around
    an inbound port filtering architecture. This gave it great flexibility
    on a per protocol/ per port basis, but actually made it more difficult
    to implement an "all others" type filter. So the "filter other types" 
    switch really only affects inbound traffic, not outbound. 
    
    This issue came to my attention back in February when Mike Bukowsky was
    trying to set up the same type of filtering as you. I looked into what it
    would  take to change the code so that outbound packets would also be
    filtered. It turned out to be a significant code change in both the 
    RBMS and SNMP responders, and would also necessitate extended testing.
    We were nearing completion of V1.3 testing, with resources already 
    committed to new projects, and decided it was more work than we could
    support.
    
    I agree, the feature would be much more useful if the packets were
    filtered in both directions. I talked with some engineers developing 
    new bridge products, and their approach to "filter other types" will
    give you the bi-directional filtering you desire. 
    
    Dave
     
    

    re: .2 "...it makes no difference..."
    
    In most *applications* it makes no difference, but in a (theoretical)
    application that only sends packets in one direction, it could make a
    big difference.  
    
    However, it does make a difference to DECnet routing!  I'm getting
    router and end-node hellos in one direction only now.  And that is
    breaking my DECnet/OSI network.
    
    re: .3...   
    
    If it is not a bug, then why doesn't the documentation clearly explain
    how it works?

    >> If it is not a bug, then why doesn't the documentation clearly explain
    >> how it works?
    
    Well, I wasn't in this business when the product first came out, but
    just guessing I'd say it essentially fell through the cracks. Up until
    this February, I don't think we got any comments from the field
    regarding the default protocol filtering, so it just wasn't an issue. I
    too assumed it would be bi-directional, until I looked at the code. 
    
    The DECbridge 500/600 series is a mature product, ripe for replacement.
    With the recent downsizing, I think management decided that it makes
    more sense to concentrate on the new products.
    
    

Re .4: I said what you said...

Meanwhile, bridges currently under development do filtering both ways
(over my objections, since it slows them down -- though fortunately not
by much).

	paul

>Meanwhile, bridges currently under development do filtering both ways
>(over my objections, since it slows them down -- though fortunately not
>by much).

    Not quite true, Paul.  The *hardware* for certain new bridges does all
    classification and filtering at the input port.  The management *software*
    sets up the filter matrix so the user perceives outbound filtering in
    addition to inbound filtering.  That is, no matter what port a packet
    comes in, that packet gets filtered if it goes to port 6.  This is
    achieved by setting a "filter stuff to port 6" inbound filter at every
    other port in the bridge.  The filter is added to all other ports in
    response to the user's request for a "single" outbound filter at port 6.

    I suppose bridges accomplish port-to-port-specific filters with various
    combinations of hardware or software and the input or output ports.

Oh, ok, I forgot about that one.  Some bridges do all this hairy stuff at full
speed in hardware, and it costs only  management code.  Others do the work in
software, and then having things like this cuts your forwarding performance
(albeit not by more than a few percent).

	paul

    This still bugs me.  My orginization bought over 200k worth of
    DECbridge 610's to retrofit our MKO topology, and now we can't
    this filtering option.  Oh well, we'll just have to wait untill
    the next gereration comes out and spend another quater of a 
    million.  BTW: I haven't heard anything lately about the HUB 900
    series.  Isn't that what these new bridge products consist of?
    Any idea what quarter/year is targeted for FT?  We in MKO/ZKO would
    like to FT this stuff.
    
    Mike
    
                             

Hi,

After reading this note and wondering how I am going to explain this
to my customer (filtering on the DB620 being one directional only), I 
came up with an idea that might help them.  This seems like a lot of work
(and may not function anyway) but I though it was worth persuing.

Can the customer setup filters on each port (using the mapping function)
to effectively "block" all protocols (at their source ports) from being 
forwarded out of the port we are really trying to filter?

Here is the dilema:

The customer has a DB620 that he wants to filter all protocols except DECnet.
This port is port 3.  Could we (and here's where all the work comes in) setup
filters on each port (1-4) specifically mapping each protocol on the network
(incoming port on bridge) to each outgoing port we are allowing it to go to?
If the answer is yes, we could then block all protocols coming into ports
1,2 and 4 (except DECnet) from going to port 3.  Then setup a filter on port
3 that only allows DECnet to pass into the bridge and out to the other ports.

Will it work?

Thanks,
Walt