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

Conference netcad::hub_mgnt

Title:DEChub/HUBwatch/PROBEwatch CONFERENCE
Notice:Firmware -2, Doc -3, Power -4, HW kits -5, firm load -6&7
Moderator:NETCAD::COLELLADT
Created:Wed Nov 13 1991
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:4455
Total number of notes:16761

895.0. "DB900MX Filtering capabilities" by DPDMAI::DAVIES (Mark, SCA Area Network Consultant) Mon Apr 11 1994 12:13

    My customer wants to have 3 totally autonomous LANs (ethernets) on each
    floor of his buildong.  He is putting a DEChub 900 on each floor. 
    Totally autonomous means that users on LAN A cannot communicate with
    users on LAN B or C, etc, etc.
    
    Ou plan is to put a DECbridge 900MX in each hub, connect each LAN to a
    separate DEChub 900 backplane channel, attach each backplane channel to
    a port on the DECbridge 900MX and then use FDDI as the backbone.
    
    My questions are on filtering supported by the DECbridge 900MX.  We are
    not concerned about the filtering of data coming off the FDDI backbone
    into the DB900MX, since it will automatically be sent to the correct
    LAN that has the targetted destination address.  Our question revolves
    around the filtering of datagrams coming into the DB900MX from the
    different ethernets.
    
    We can filter by SOURCE ADDRESS and by PROTOCOL.
    
    By this, we assume that we can create a filter that says the "only TCP/IP
    can pass from ethernet port 1 to the FDDI port".
    
    Is this correct?
    
    Or we can create multiple filters which would do the same by specifying
    each and every node address on each LAN.  The amount of work envolved in
    doing this initially and maintaining this across 30+ DEChubs is not very
    acceptable to this customer.
    
    Is this also correct? (Both the capability and maintenance)
    
    WHat would really be nice is if we could apply a filter based on the
    port #.  This would allow the creation of a filter that specified that
    "data from ethernet port #1 can only pass to the FDDI port".
    
    Is this possible?
    
    Thanks,
    
    Mark
    
    
    PS	Our competition is Kalpana.
    
T.RTitleUserPersonal
Name
DateLines
895.1LEVERS::ANILMon Apr 11 1994 19:1253
I've listed below the various filtering options that the DECbridge 900MX does
support, to see if we can figure out a way to accomodate the requirement:

- Address filtering: you can tell the bridge that an address is "allowed"
  on an arbitrary port or set of ports.  This works both as a source address
  filter (in that a packet with this address as source will only be
  forwarded if it came in on one of the allowed set of ports); and as
  a destination address filter (in that a packet with this address as
  destination will only be forwarded to the allowed set of ports, and
  in particular, only to the port on which the address was learnt if this
  information is available).

- Protocol filtering: the bridge can be told to restrict an Ethernet Protocol
  type, or an 802 DSAP, or an 802 SNAP PID, to a set of "allowed ports".
  A packet with this protocol will only be forwarded if both of the
  following are true: the source port is in the set of allowed ports for
  the protocol; and the destination ports is also in the set of allowed
  ports for the protocol.

- Manual mode: The bridge can be put in manual mode, also known as secure
  mode, on an arbitrary set of ports.  In this mode the bridge will shut off
  its learning capability on the specified port and forward packets only
  according to the configured address filters (specified as explained above).

- Other-Protocol switches: You can specify the forwarding action of the
  bridge for a protocol (again, a separate switch for each of the 3 types of
  protocol) that is not in its protocol filter table.  By default, a bridge
  will forward an unknown protocol (all protocols are unknown if you haven't
  configured protocol filtering); instead, the bridge can be told to NOT
  forward a packet which is unknown.

What you cannot do is tell the bridge to base its decision on the input
port -- that is, given a port on which the packet came in, have the bridge
forward it to a set of ports that is unique for this incoming port.
However, given the kind of secure environment that your requirement seems to
imply, the manual mode described above seems to be the best fit.  This
does require some configuration, esp. if the number of stations on each
LAN is significant.

A comment on something you said:

>    My questions are on filtering supported by the DECbridge 900MX.  We are
>    not concerned about the filtering of data coming off the FDDI backbone
>    into the DB900MX, since it will automatically be sent to the correct
>    LAN that has the targetted destination address.

If an address has been aged out (2 minutes is default aging time), a packet
destined to it will be flooded to all ports.  Susbsequently, if the address
speaks up (and it usually will, since one-way traffic is rare) then it will
be learnt and no more flooding should take place.  In any case you can't
depend on packets automatically being sent to the right LAN every time.

Anil
895.2Thanks, I need more...DPDMAI::DAVIESMark, SCA Area Network ConsultantTue Apr 12 1994 12:2518
    First, thank you very much for the clear response.
    
    Now...  we have run into a hitch which appears to be a dead end for the
    use of FDDI as the backbone.  They want to have 3 separate ethernets,
    totally autonomous.  The problem, as we see it, will be that there will
    be no way for us to filter off each ethernets multicasts/broadcasts,
    ie, either none get onto the FDDI or they all do.  And if they all do,
    then service advertisements will be seem by all, but be unreachable by
    many (those on the wrong ethernet).
    
    Could this maybe be handled by filtering off multicats via group codes?
    
    How about broadcasts?
    
    Thanks,
    
    Mark
    
895.3Do we really have a DEChub900 solution for this?QUIVER::GALLAGHERTue Apr 12 1994 12:3810
I can't answer your questions about the bridge's filtering, and I don't
mean to interrupt this thread but...

It sounds to me like the customer wants separately routed networks and
probably won't get the network they want using bridges.  I realize
that this solution doesn't help you sell DEChub900s.

What other solutions have you considered?  What am I missing?

						-Shawn
895.4why not a collapsed backbonePERE::BRUCETue Apr 12 1994 12:4114
    Hi Mark
    
    This may sound like a stupid question but why go through all of the
    filtering
    
    why not bring each of the seperately repeated lans down to a collapsed
    backbone  in the basement  with a DECrepeater 900FP.
    
    you'd have to do a little work to understand the scalability and
    traffic management characteristics but I think it will be a much more
    manageable network. Since each lan would be on totally physically
    separate Lan Channels as well there would probably be more security
    between the lans.
    
895.6QUIVER::SLAWRENCEWed Apr 13 1994 10:279
    It sounds to me as though your interconnect would be better served
    using the DEFMM; since each port pair can be switched to different
    backplane segments you could use one in each 'floor' hub.
    
    The DEFMM provides 6 port pairs; each of your 3 lans can get two port
    pairs, so each floor can be repeated directly to each of the others,
    and still maintain the isolation you want.  
    
    It definitly sounds like you can't use any bridge we make now.
895.7Thanks for the helpDPDMAI::DAVIESMark, SCA Area Network ConsultantWed Apr 13 1994 13:4615
    Thanks for all the comments.
    
    The idea in using FDDI as the backbone is that:
    
    1. You only need a single set of fibers no matter how many autononous
       ethernets you need.
    
    2. You have a single high speed backbone.
    
    Looks like the follow-on PE2000 may have answers nest year.
    
    Thanks,
    
    Mark
    
895.8DECbridge 900MX Static Filter QuestionsCGOOA::VAOP35::vennerNIS - Networks Team VancouverFri Apr 15 1994 15:1769
Hello Anil,

Thanks for your response to note 895 (DECbridge 900 Filtering)and the 
following email from Krisna on how to use the ELAN MIB to set the 
filter masks.

I would like to outline a customers network and the filtering requirements 
to outline my concerns with regards to the limitations of the filtering.

DECbridge 900MX	Computer Room		DECbridge 900MX Wiring Closet
*************************		*************************
*		       _*_______________*_			*
*		      |___________________|			*
*		       	*	FDDI	*			*
* 2    3    4    5    6 *		* 2    3    4    5    6 *
*************************		*************************
       |         |				    |         |
   +-------+  +-------+				+-------+  +-------+
   |       |  |       |				|       |  |       |
   |       |  |       |				|       |  |       |
   +-------+  +-------+				+-------+  +-------+
   Server A    Server B				Client A   Client B


The diagram above shows 2 DECbridge 900s connected by an FDDI ring.
This is a small representation of the customers network. The customer 
wants to provide access to 30 servers from a number of closets. The FDDI 
ring extends from the computer room to each closet.

In this environment (Banyan) the client boots and requests services from
any server via a BROADCAST. The first server to respond becomes the clients
server. If that client requires information from any other server the 
request is routed through the initial server. This is not the most efficient
use of server resources.

The customer would like to use static filtering to point specific clients
to a server. This does not appear to be possible using the the static 
filtering descibed in the note. If Client A wants to connect to Server A
the detination address must be known. If the destination is known the bridge 
would connect client A to Server A by the normal learning process. Static 
filtering should provide the ability to manipulate traffic flow above and
beyond the normal learning process. Tying the filter capabilities in the 
following manner seems very strange.

	      1. Go to ports------> based on destination address
	      2. Come from ports--> based on source address

As mentioned above point 1 is part of the normal learning process and 
as for point 2, a devive is normally connected to a specific lan segment.
In todays LAN environments, if the customer is going to the trouble of static
filtering they are creating work groups (vitual LAN). The filtering 
requirements for this type of scenairio are opposite to that mentioned 
above.

	      1. Go to ports------> based on SOURCE address
	      2. Come from ports--> based on DESTINATION address 

This type of filtering would provide far greater flexibility and would 
allow our customers the ability to create workgroup LANS across the FDDI
network.

After all of this I have 2 questions.

1. What was the original intent of static filtering? (Am I way off base?)

2. Is it possible to change the filtering? ( If not, WHY ???)

Regards Gary Venner
NIS Vancouver.          
895.9LEVERS::ANILFri Apr 15 1994 19:5919
Gary,

Filtering in the DECbridge 900MX is useful for secure environments.
This is why "source" is "from" (makes sense since the source address of a
packet is filled in by the station it comes *from*), and the DA is to
(destination).

Consider a secure station A that is known to be on LAN 3.  In order to
prevent stations on other LANs from masquerading as station A, the filtering
in the DB900MX can be used to lock-down A on LAN 3.

You could also, if you want, channel all broadcast and multicast traffic
to a backbone port.  Say your servers were on FDDI, and you don't want
the Ethernet LANs' multicasts to go to any of the other Ethernets.
In this case, you could lock-down a multicast or broadcast address to
the FDDI, which would prevent the bridge from flooding such packets to
any of the other Ethernet ports.

Anil