Dear Craig and All, Adding to my earlier posting, the sequence of events that led me to get things working *had* left LAN service on.
So, this morning I ran utadm -l Off and I am delighted to report that after cold restarting SunRay services it is still serving my private interconnect just fine... craig.ben...@oracle.com said: > Did the vendor class tags get inserted into DHCP macros? I think it has... =========================================================== root@wiked:/etc# dhtadm -P Name Type Value ================================================== 192.168.199.0 Macro :Include=SunRay-net1:Subnet=255.255.255.0:FWSrvr=192.168.199.7:Intf="net1":Broadcst=192.168.199.255:MTU=1500:Router=192.168.199.7:NewTVer="11.0.1.0_05_2012.05.29.21.30": SunRay-net1 Macro :Include=SunRay:AuthSrvr=192.168.199.7:AltAuth=192.168.199.7: SunRay Macro :LeaseTim=86400:LeaseNeg:AuthPort=7009:LogHost=193.60.11.7:LogKern=6:LogNet=6:LogUSB=6:LogVid=6:LogAppl=6: wiked Macro :Include=Locale:Timeserv=193.60.11.7:LeaseTim=86400:LeaseNeg:DNSdmain="dcs.aber.ac.uk":DNSserv=193.60.11.252 193.60.11.253: Locale Macro :UTCoffst=0: BarrierLevel Symbol Vendor=SUNW.NewT.SUNW,36,NUMBER,4,1 NewTFlags Symbol Vendor=SUNW.NewT.SUNW,34,NUMBER,4,1 Intf Symbol Vendor=SUNW.NewT.SUNW,33,ASCII,1,0 FWSrvr Symbol Vendor=SUNW.NewT.SUNW,31,IP,1,1 LogAppl Symbol Vendor=SUNW.NewT.SUNW,29,NUMBER,1,1 LogVid Symbol Vendor=SUNW.NewT.SUNW,28,NUMBER,1,1 LogUSB Symbol Vendor=SUNW.NewT.SUNW,27,NUMBER,1,1 LogNet Symbol Vendor=SUNW.NewT.SUNW,26,NUMBER,1,1 LogKern Symbol Vendor=SUNW.NewT.SUNW,25,NUMBER,1,1 LogHost Symbol Vendor=SUNW.NewT.SUNW,24,IP,1,1 NewTBW Symbol Vendor=SUNW.NewT.SUNW,30,NUMBER,4,1 NewTVer Symbol Vendor=SUNW.NewT.SUNW,23,ASCII,1,0 AuthPort Symbol Vendor=SUNW.NewT.SUNW,22,NUMBER,2,1 AltAuth Symbol Vendor=SUNW.NewT.SUNW,35,IP,1,0 AuthSrvr Symbol Vendor=SUNW.NewT.SUNW,21,IP,1,1 root@wiked:/etc# ================================================== which to me looks very close to what I see on my old Solaris 10 SunRay private interconnect connection. Here's my output of utadm -x root@wiked:/etc# /opt/SUNWut/sbin/utadm -x begin general allowlanconnection=false serviceonline=true end begin interface interface=net1 hostname=wiked-net1 ip=192.168.199.7 network=192.168.199.0 netmask=255.255.255.0 broadcast=192.168.199.255 end root@wiked:/etc# So, I think I may have things working o.k.? Do folks agree? My reason for going against the LAN option, as I said before, is that we have always seen various "performance" issues with SunRay screens refreshing and so what I am trying to do is to eliminate any network factors by having the SunRay traffic, and only the SunRay traffic all running in one isolated network. SunRay not leaking to other and others not leaking traffic to the SunRays. To make sure this was happening, I re-rigged five SunRays and the interface to the Solaris 11 SunRay server on to a new, completely isolated network swicth this morning and that's working fine. We normally run 40 SunRays fed from two T5140s. I have not yet added the "set hires_tick=1" entry to /etc/system. I presume that will still work in Solaris 11?? These are used by students doing software development and/or learning to use Unix. So, some usage is low demand command line tools (editors, awk, sed, shell scripting an fso on) and other usage is more demanding software development, typically Netbeans being used to develop C and/or C++ code etc. I would be *VERY* interested to hear from other people using a SunRay service in this way and whether or not you have experienced problems with "slow interactive response" in tools like netbeans or web browsers etc. So, I am now going to backtrack to an earlier BE and see if I can again recreate what I have working now but with less random steps :-) Thanks, folks. Dave Price _______________________________________________ SunRay-Users mailing list SunRay-Users@filibeto.org http://www.filibeto.org/mailman/listinfo/sunray-users
