| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 446.1 | moved here | SMURF::BAT | Segui la tua beatitudine | Thu Feb 06 1997 23:15 | 43 |
| <<< SMURF::DISK$NOTES:[NOTES$LIBRARY]DEC_MLS_PLUS.NOTE;1 >>>
-< dec_mls_plus >-
================================================================================
Note 447.0 Routing through MLS+ updated diagram 1 reply
NETRIX::"sowards@mail.dec.com" "Mark Sowards" 37 lines 6-FEB-1997 17:33
--------------------------------------------------------------------------------
I re-did the diagram maybe this is clearer
/8.1.1.x---------8.1.1.85-[MLS sys 01]-8.1.7.85----8.1.7.80[MLS sys
02]-8.1.8.80
| | |-------\ |
| | | |
|8.1.1.45 |8.1.1.125 | 8.1.1.82 8.1.8.124
[MLS sys 3] [Sun sys01] [Sun sys 02] [Sun sys 03]
I hope this diagram is some what clear. The two central MLS boxes sit
across
three subnets 8.1.1.x / 8.1.7.x / 8.1.8.x. It is possible to do a remote
display
between the two main MLS boxes; from MLS sys 1 to MLS sys 2 and back (across
8.1.7.x) It is possible to display from MLS sys 1 to Sun sys 2 and back
(across
8.1.1.x) It is not currently working when trying to display from MLS sys 2 to
Sun sys 2 (Across 8.1.7 to 8.1.1) however it is possible to display from
Sun sys 2 to MLS sys 2 (across 8.1.1 to 8.1.7). The same holds true for the
other side MLS sys 2 can display to Sun sys 3 and Sun sys 3 can display over
to
MLS sys 1 but MLS sys 1 cannot Display to Sun sys 3. It looks as though MLS
is
not allowing a double routed Xdisplay, but it is possible to display from
MLS sys 2 to MLS sys 3 (across 8.1.7 to 8.1.1). The ultimate goal is to be
able to remote display from Sun sys 3 to Sun sys 1
(across 8.1.8 to 8.1.7 to 8.1.1).
OK does anyone have an idea? Note when the box MLS sys 1 was digital Unix
this double routed xdisplay saposedly worked.
If you used the Web version of notes the diagram should be fully viewable.
[Posted by WWW Notes gateway]
|
| 446.2 | moved here | SMURF::BAT | Segui la tua beatitudine | Thu Feb 06 1997 23:15 | 19 |
| <<< SMURF::DISK$NOTES:[NOTES$LIBRARY]DEC_MLS_PLUS.NOTE;1 >>>
-< dec_mls_plus >-
================================================================================
Note 447.1 Routing through MLS+ updated diagram 1 of 1
NETRIX::"sowards@mail.dec.com" "Mark sowards" 11 lines 6-FEB-1997 17:39
-< Re diagrammed >-
--------------------------------------------------------------------------------
OK one more try....
8.1.1.x------8.1.1.85-[MLS sys 01]-8.1.7.85----8.1.7.80[MLS sys 02]-8.1.8.80
| |------------------ |
| | | |
8.1.1.45 8.1.1.125 8.1.1.82 8.1.8.124
[MLS sys 3] [Sun sys01] [Sun sys 02] [Sun sys 03]
[Posted by WWW Notes gateway]
|
| 446.3 | some quick question to clarify | SMURF::BAT | Segui la tua beatitudine | Thu Feb 06 1997 23:48 | 84 |
| Hi Mark,
First I need to check some things:
o are the Sun boxes Sun CMW's using MAXSIX, or are they are in
the MLS+ databases as single-level hosts?
o are the MLS+ hosts MLS1 and MLS2 talking to each other using
tsix_1_0 or _tnet protocol?
o are there any other routers (e.g., CISCO) involved?
o what is the response you get when you attempt the display?
There was a discussion in the ULTRIX_MLS_PLUS notes file about using
MLS+ boxes as routers (topic 235). Fran was the original author of
the following excerpt from 235.4 and I'll have to check with him to
see if the principle still applies, but at least it is a start:
"In general, all routers in an extended network containing MLS+
systems must either be all MLS+ systems, or they must all be
unlabelled, unless:
1. the transition from labelled to unlabelled, or
unlabelled to labelled, is the next hop to the end node; or
2. the MLS+ system is the only MLS+ router between
any number of unlabelled systems on either side of it.
In other words, only the following types of routing paths are
possible (where M = MLS+ system, and U = unlabelled system, and ...
means any number of the same type of system):
1. M...M
2. M...Mu
3. Mu...uM
4. Mu...u
5. u...uMu...u
Another way to state the configuration rule, in terms of the
original cases above, might be: all intermediate systems (C1...Cn)
must be the same kind of system -- either labelled or unlabelled --
as the next hop (B) system."
Now my initial interpretation of the above is that Rule #0 applies
to your network (assuming that the Sun systems are unlabelled).
[ Rule #0 = all routers are MLS+ boxes. ] But when you read the
"routing paths" list above, then I'm not so sure. I would diagram
your routing goal as:
6. uM...Mu
And I don't know if that is legal (I would have said it is the same as
#5), but I'll check with Fran on my interpretation of the above.
> It is not currently working when trying to display from MLS sys 2 to
> Sun sys 2 (Across 8.1.7 to 8.1.1)
I would have said that the above is routing path #2:
2. M...Mu
and therefore should work. So much for what I know.
> but it is possible to display from
> Sun sys 2 to MLS sys 2 (across 8.1.1 to 8.1.7).
And this I would have called
uM...M
> The same holds true for the other side
> MLS sys 2 can display to Sun sys 3
> and Sun sys 3 can display over to MLS sys 1
> but MLS sys 1 cannot Display to Sun sys 3.
> The ultimate goal is to be
> able to remote display from Sun sys 3 to Sun sys 1
> (across 8.1.8 to 8.1.7 to 8.1.1).
And I assume this fails when you try this?
|
| 446.4 | Further CLarification Info | NETRIX::"sowards@mail.dec.com" | Mark Sowards | Fri Feb 07 1997 16:58 | 40 |
|
Some answers...
>> o are the Sun boxes Sun CMW's using MAXSIX, or are they are in
the MLS+ databases as single-level hosts?
The Suns are running the latest Sun OS 2.5 something not the CMW. So they
are all set in the MLS network as Single level systems.
>> o are the MLS+ hosts MLS1 and MLS2 talking to each other using
tsix_1_0 or _tnet protocol?
The MLS+ boxes are all running TSIX_1_1 using CIPSO.
>> o are there any other routers (e.g., CISCO) involved?
There is a CISCO router at 8.1.1.254.
>> o what is the response you get when you attempt the display?
The failed response is no response what so ever. Actually there was a
"sniffer" put on the the line and it detected the signals out from the MLS box
through the second MLS box to the SUN and then a response from the Sun back to
the first MLS box (through the intervening MLS+ box) but then no counter
response from the originating MLS+ box. As I said through you are able to
sit
on the other end a produce a display on the MLS+ box.
The assumtions you've made are correct. There are three subnets; the
central one is a subnet of the two MLS+ routers with two different subnets on
either side. You rule 6 description is correct. And actually rule 2 does
work
but only in one direction (u-->M-->M). Meaning the Unlabeld box can display
on
the second MLS box.
I'm now making the assumpion that if the u boxes were CMW boxes, (but not
MLS+ boxes), that this would work??? (c---M...M~~~c)
[Posted by WWW Notes gateway]
|
| 446.5 | promising initial tests on V4 | SMURF::BAT | Segui la tua beatitudine | Sat Feb 08 1997 00:27 | 35 |
| Mark,
MLS+ appears to do route-through fine on V4 at least...
Lee set up a set of systems as follows:
ln0 fza0 ftz0 ln0
|<--> MLS+V4 <----> MLS+V4 <-->|
| "nook" "liszt" |
DU | | DU
V4 V4
"pandit" "medea1"
That is, there were two MLS+ boxes with two interfaces each, i.e.,
three nets. The MLS+ boxes were set up as tsix_1_1 (cipso) running
routed with -s. The two single-level unlabelled systems were vanilla
DIGITAL UNIX V4.0 boxes.
We were able to display as root xclock from pandit to liszt and back,
and able to display xclock from medea1 and from medea1 to pandit.
So at least in V4 we have something working that resembles the routing
setup you want.
We ran out of time and did not test at other-than-syslo labels, or
other-than-root account.
We don't have V3.1A systems on-hand with two interfaces in them, that
would take more time to load up the above or swap boards or whatever.
But we'll double-check on what exactly is supported. There have been
networking changes made between V3.1A and V4, a lot of the code was
re-written, but I don't have details; it may have been that this kind
of routing was one thing that changed. I'll try and find out on
Tuesday.
|
| 446.6 | Great info!!! | NETRIX::"Sowards@mail.dec.com" | Mark Sowards | Mon Feb 10 1997 19:09 | 7 |
|
Your test results sound really good. I had a question or two... What do
you
mean by fza0 and ftz0; are these FDDI connections? Could the same be done
with
an ln0 and an ln1 on each machine?
[Posted by WWW Notes gateway]
|
| 446.7 | who knows what we did differently in the net setup? | SMURF::BAT | Segui la tua beatitudine | Mon Feb 10 1997 19:30 | 9 |
| Yes, they are they were the FDDI interfaces on the specific machines
used in the test configuration. Yes, it should work just the same with
two Ethernet cards.
The bottom line is that we don't know whether your problem setting up
is because of a network design difference between V3.1A and V4.0 or
because there was a non-obvious difference in your setup. We don't
have the cycles to spare to try this setup with V3.1A, but I'll try and
get a design statement tomorrow.
|
| 446.8 | 3.1a is not in the picture | NETRIX::"sowards@mail.dec.com" | Mark Sowards | Mon Feb 10 1997 23:04 | 27 |
|
Sorry if I miss lead you there is no 3.1A concern here, only 4.0.
The customer is now saying that the "sniffer" has detected a dropping of a
packet when the connect is going from the inside (MLS+ thru MLS+ to Sun os)
out. The dropped packet is on the inside between the two MLS+ boxes when
the Sun Box replies to the display request.
Sun <---MLS+4 <---MLS+4 this goes thru but the packet is dropped
on the suns reply Sun ---> MLS+4 |--->MLS+4
In other words the connection is being made but some thing fails before the
display is made on the Sun. The reverse does work though you can display from
the Sun onto the second MLS+ box
Sun OS <----> MLS+4 <---> MLS+4 even though the MLS+4 box must
reply to the Sun.
I'll be getting up early tomorrow to see if I can contact some one back
east.
[Posted by WWW Notes gateway]
|
| 446.9 | fixed in next release probably not good enough :-o | SMURF::BAT | Segui la tua beatitudine | Wed Feb 12 1997 00:32 | 23 |
| Hi Mark -- Ah... so you are doing this on T4.0? -- the EFT MLS+ release?
We are running the latest rev of MLS+ V4.0A, I think rev 34 or 36 (or a
mixture of both :-).
There were some networking bugs in the EFT release -- cheap guess is
that's why ours is working and yours is not -- at least Andy did a
number of bug fixes between EFT and what we are running now. I'll
double check this and see if anything he submitted might have anything
to do with dropping packets.
In any case, I don't know if I can just pick up the tnet .mod files en
masse and use them to build a new kernel on a T4.0 system. More than
likely we are back to the same problem we had with the LAT.
I'm pretty sure at this stage that the engineers here would prefer that
we just send you a new kit, but the best we could possibly do is send a
RIS kit in compressed tar format -- once again, do they have a vanilla
UNIX box they could set up as a RIS server? (It turns out it does not
have to be UNIX V3.2 -- it can be UNIX V4.0*.)
An alternative -- we might be able to build you a system on a disk here
and ship the disk there -- provided you could return it of course.
We'd need an idea about what hardware they are running.
|
| 446.10 | just to clarify what I had missed before | SMURF::BAT | Segui la tua beatitudine | Wed Feb 12 1997 00:36 | 4 |
| re: .3
The routing restrictions (from ULTRIX days) apply to routing between
hosts using "tnet" protocol, to hosts using "tsix" protocol.
|
| 446.11 | to replace external field test kit only | SMURF::BAT | Segui la tua beatitudine | Wed Feb 12 1997 19:55 | 33 |
| Mark,
Dave J set up a copy of the RIS data area which you can use to
RIS a later version of MLS+ V4.0A (not yet the SSB version, but
getting close).
Try anonymous ftp on either
oskits:
cd patches/mls/v4.0a-38
get MLSV4.0A.tar.Z
and if you want some new manuals:
get 4.0_SSB_rnotes.ps
get 4.0_SSB_install.ps
get 4.0_SSB_prog.ps
get 4.0_SSB_smg.ps
psycho:
cd mlsv4.0a-38
get MLSV4.0A.tar.Z
Size/checksum info:
ls -l
total 263120
-rw-r--r-- 1 root system 269280277 Feb 12 14:47 MLSV4.0A.tar.Z
sum MLSV4.0A.tar.Z
20183 262970 MLSV4.0A.tar.Z
BAT
|
| 446.12 | fully qualified names | SMURF::BAT | Segui la tua beatitudine | Thu Feb 13 1997 18:06 | 3 |
| oskits.zk3.dec.com
and
psycho.zk3.dec.com
|
| 446.13 | one more thing down, one more to go | SMURF::BAT | Segui la tua beatitudine | Sat Feb 22 1997 00:45 | 21 |
| re: .8
Mark called and said that they discovered that the reason why there
were packets being dropped between the two MLS+ routers was because the
Sun system's MTU_WINDOW was so large that once the packets were padded
with security attributes they were too large and got dropped. By
manually changing the Sun's so that the MTU WINDOW was smaller, they
are no longer seeing dropped packets.
Also, he called from the site -- they had set up a RIS server and were
trying to RIS the MLS+ V4.0A-38 kit. He was getting an error message
"can't create ... log ... /var". It turns out that I did not pick up
the README from the V4.0-eft kit and give to him, which includes the
special instructions for RIS'ing the tar.Z kit. You must unpack it
with tar -xvpf (the p is the key) and you must MAKEDEV sec and MAKEDEV
std in the unpacked tree.
Also, Lee is setting up a new dual route configuration in the lab
(and discovered that route hangs in multi-cpu config with r39 sigh)
but we should be able to send Mark the /etc/hosts, TNETRHDB,
/etc/rc.config and /etc/routes files as samples for him to use.
|