Conference smurf::dec_mls_plus

          <<< SMURF::DISK$NOTES:[NOTES$LIBRARY]DEC_MLS_PLUS.NOTE;1 >>>
                               -< dec_mls_plus >-
================================================================================
Note 447.0            Routing through MLS+  updated diagram              1 reply
NETRIX::"[email protected]" "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]

          <<< 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::"[email protected]" "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]
    

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?

  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]

    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.

   
   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]

    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.

 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]

    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.

    re: .3
    
    The routing restrictions (from ULTRIX days) apply to routing between
    hosts using "tnet" protocol, to hosts using "tsix" protocol. 

    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

    oskits.zk3.dec.com
    and
    psycho.zk3.dec.com

    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.