T.R | Title | User | Personal Name | Date | Lines |
---|
1162.1 | protocol by protocol only.. | PADNOM::PEYRACHE | Jean-Yves Peyrache Country Support Group France | Tue Jun 28 1994 10:03 | 20 |
| Faraday,
try this,
on two Decbridge900 MX
for IP selection:
add filter entry by protocol type
select IP procotol (08-00)
select port 3,1 for "passed action" (green arrow)
select port 2 for "blocked action" (red arrow)
add some filter entries for all protocols type involved in your configuration
(ie Lat ,Decnet, SCS)
select port 2 ,1 for "passed action" (green arrow)
select port 3 for "blocked action" (red arrow)
Jean-Yves
|
1162.2 | Not possible to set filters in this case... | NACAD::KRISHNA | | Tue Jun 28 1994 16:56 | 21 |
| Hi Faraday,
This is a very tricky problem, because on paper it looks like
there should be no problems in setting up the filters, but in practice
it is not possible to do so. This is because of the Spanning Tree
algorithm that runs on all bridges. In your configuration you have a
loop between ports 2 and 3 of your two bridges. If your configuration
just consist of the 2 bridges, one of them would be elected root of the
spanning tree, let us say DB900MX #1, all its ports would go into
forwarding, but one of the ports of DB900MX #2 would go into backup,
usually it is the higher numbered port, so in this case it would be
port 3. This is because traffic destined for Lan #2 from Lan #4 can go
through port 2 of DB900MX #2 to Lan #1 and be received on port #2 of
DB900MX #1 and then be forwarded to Lan #2 through port 3 of DB900MX
#1.
So in order for IP traffic sourced from Lan #4 to reach Lan #2, they
have to traverse Lan #1, but your requirements state that Lan #1 should
not carry IP traffic ! Hence we get into this situation where setting
up filters to match the requirements is not feasible.
Krishna
|
1162.3 | Other configurations possible... | NACAD2::KRISHNA | | Thu Jun 30 1994 08:57 | 40 |
|
The reason for not being able to achieve the filtering requirements is
because the Lans connecting the two bridges have restrictions on the
type of traffic they can carry. The other important point to note in
this configuration is that there is redundancy built into it. If any
one of the bridges failed the hosts on the Lan connected to port 1 of
the other bridge could still communicate with the IP and Non-IP Lans.
If complete redundancy is not an objective and if you can
compromise the loss of connectivity in case of a bridge failure to the
hosts connected to the other bridge's port 1, there are configurations to
support that. Let us say that the hosts connected to DB900MX #2 port 1
need not have connectivity to the IP Lan in case DB900MX #1 failed,
then the configuration below would meet the other filtering requirements.
Host#3 Host#4 Requirements are:
| |
o--+-----+-------+-----+--o LAN#1 (1) No IP is allowed on LAN#1
| | (2) Only IP is allowed on LAN#2
| o-+-------------o |
|2 |3 LAN#2 |2 Objectives are:
+-+---+-+ +-----+-+
|DB900MX| |DB900MX| (1) Host#1 and Host#2 communicate
| #1 | | #2 | with each other using IP
+--+----+ +--+----+
|1 |1 (2) Host#1 communicate with Host#3
o--++--O LAN#3 o--++--o LAN#4 and Host#4 using non-IP,
| | similarly for Host#2 with
Host#1 Host#2 Host#3 and Host#4
Now in this configuration there are no loops and hence no link would go
into backup, but if DB900MX #1 failed, Host #2 cannot communicate with
hosts on Lan #2, but still would be able to communicate with Hosts #3
and #4 on Lan #1.
There are other configurations that are possible, depending on how
strict your requirements are. If you are interested send me mail.
Krishna
|
1162.4 | Please explain... | COMBAT::JONSSON | Lars Jonsson | Fri Sep 09 1994 12:39 | 6 |
| Krishna,
How is it possible for host#1 and host#2 to communicate using IP, without
generating IP-traffic on LAN#1 ? Perhaps I'm missing something here.
Lars
|