T.R | Title | User | Personal Name | Date | Lines |
---|
895.1 | | LEVERS::ANIL | | Mon Apr 11 1994 19:12 | 53 |
| 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.2 | Thanks, I need more... | DPDMAI::DAVIES | Mark, SCA Area Network Consultant | Tue Apr 12 1994 12:25 | 18 |
| 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.3 | Do we really have a DEChub900 solution for this? | QUIVER::GALLAGHER | | Tue Apr 12 1994 12:38 | 10 |
| 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.4 | why not a collapsed backbone | PERE::BRUCE | | Tue Apr 12 1994 12:41 | 14 |
| 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.6 | | QUIVER::SLAWRENCE | | Wed Apr 13 1994 10:27 | 9 |
| 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.7 | Thanks for the help | DPDMAI::DAVIES | Mark, SCA Area Network Consultant | Wed Apr 13 1994 13:46 | 15 |
| 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.8 | DECbridge 900MX Static Filter Questions | CGOOA::VAOP35::venner | NIS - Networks Team Vancouver | Fri Apr 15 1994 15:17 | 69 |
| 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.9 | | LEVERS::ANIL | | Fri Apr 15 1994 19:59 | 19 |
| 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
|