Dear Craig, I hve just come back into work and am glancing through your reply. I'll answer a few things now, based on what I have, and then I'll answer more when I run again from a new BE from a milestore or so back.
craig.ben...@oracle.com said: > You would have had to have at least created /etc/hostname.<INTF> and / > etc/defaultrouter as those aren't part of S11 anymore and also, was > this an interface you had already plumbed up? I definitely did not create a file called /etc/defaultrouter at all and indeed, checking that is not there. I used a text installer from DVD to install Solaris 11 and I set a fixed IP address for net0 as part of that process and the IP address of the router as reached via the net0 interface. netstat -rn shows a proper line for "default". I do have root@wiked:/etc# !svcs svcs | grep rou online 19:55:30 svc:/network/routing-setup:default online 19:55:33 svc:/network/routing/route:default online 19:55:41 svc:/network/routing/ndp:default root@wiked:/etc# and I have RIP running on the router and that has led to other routes being learnt too. I am fairly sure that the defauly route is fixed statically but I have not yet spotted where it is. It is certainly not in /etc/defaultrouter as that simply does not exist. I will dig about a bit more. At various points I did create /etc/hostname.<INTF> for both net0 and net1, but if my brain remembers correctly, I finally removed the net1 version. Also, as part of my sequence (when earlier I tried to use utam -A), I had used ipadm to manually configure and indeed give an IP address to net1. I removed at least some of that before use utm -a, but I probably would effectively have at least left net1 plumbed in, but via my ipadm command not via using ifconfig. craig.ben...@oracle.com said: > Did the vendor class tags get inserted into DHCP macros? Not sure, I will check that shortly. craig.ben...@oracle.com said: > Part of a private interface is that it starts with a unplumbed NIC. > Which is why utadm -a takes an interface arg. utadm -A can look a lot > like private interconnect but it's for a subnet, not a NIC. There > are several other differences, but NIC vs Subnet is one of the > largest. I did of course try -A first, but that would not let me have an easy way to set up DHCP things it seemed. I then later tried utadm -a so I may have a bit of a hybrid... craig.ben...@oracle.com said: > -A is not considered a private interconnect. It's a LAN based > interconnect with the ability to serve DHCP vendor class tags for many > different (even non-local) subnets with DHCP Helpers on routers. I believe my -A "broke" the final thing that I did get to run was utadm -a 192.168.199.0 and that eventually asked all the setup questions re DHCP and firmware servers and so on and seemed to them work. craig.ben...@oracle.com said: > Basic networking config, prior to S11, was done through files. No > longer the case, and one of the reasons utadm -a is broken. So if you > really created a private interconnect, you'd would have had to use > dladm/ipadm to manually configure the NIC. Yes, I did definitely make some use of ip[adm in an active way but I did not directly use dladm. craig.ben...@oracle.com said: > Another observation/question. It sounds like will have multiple DHCP > servers on the same segment? At least that's how I understood your > range comment. > Is that true? > If so, how are you preventing PC's from using the Sun Ray Server's > DHCP and vice versa? There will be two on 192.168.199.0 on the two SunRay servers each allocated a slice of the IP range each (one gets 16 -> 19 and the other gets 80-143). We do NOT have any devices other than the SunRays and the interfaces to the two SunRay server machines on 192.168.199.0. I am hoping (but I must check) that the SunRay server will NOT attempt to hand out those, or any other IP addresses, on the SunRay servers other IP interfaces. As I commented before, we normally bring up three interfaces (0,2,3) leading to mixed networks of servers and personal computers etc and just use net1 to lead to the other SunRay server and the SunRays themslves. craig.ben...@oracle.com said: > I can tell you why it work would, even if a Sun Ray gets an address > the other server, it's because when the Sun Ray didn't get all of the > info it needed to connect, so it sent out a DHCPInform request, which > the DHCP Server on the Sun Ray answered (even it if didn't provide > the IP address). You'd actually see this via utquery. You'd have > two different values for DHCP server and DHCPInform server. The > default of -A is not to offer IP addresses. Well, all I can say is that my "test" SunRay definitely got given an IP{ address from the range allocated by me on the new SunRay server last night (the other server uses different addresses as noted above) and the test SunRay then loaded firmware etc and after various reboot type events latched onto the "new SunRay server and display a Solaris 11 logon which worked fine. craig.ben...@oracle.com said: > If that's how you been used to doing things, then there really is no > reason to do anything but LAN only connections. > On the DHCP server that was serving the PCs, you could set option 66 > (tftpserver) and point it to the Sun Ray Server. This was you are > provision/controlling the Sun Ray clients from via parameter files. > There is also DHCP option 49, but option 49 will just let the Sun Ray > find the server for a session, it won't tell it the firmware server. Our main DHCP server does *not* have an interface into the SunRay network. That's isolated to just the SunRays and the two interfaces to the SunRay servers. craig.ben...@oracle.com said: > There are a few other options, such using DNS names. > sunray-config-servers.fqdn is like option 66 sunray-servers.fqdn is > like option 49 > So instead worrying about making changes to many dhcp servers or > messing with vendor class options, LAN based interconnects with these > more standardized provisioning options is far easier. Now I am awake again, I will carefully try to check exactly what I do have and then I will go back to an older BE and run forward through this last phase again so I know more exactly what I did. I will then report back again. I need to know properly as I havbe the "other" server to deal with (assuming we do decide to risk going to Solaris 11 for our production teaching service) so I need some accurate instructions/records. I am also going to grab an old switch and set up a totally isolated network with a dozen of so SunRays and the interface to just the one server so I can be really confident no traffic is leaking in or out. We do have some VLAN traffic on some of our switch and trunk interconnections. I am confident that is not confusing the issue but a replacement totally isolated switch will remove even the faintest doubt. Anyway, thank you and the others, you all kept me going and the combination of things was really good. If I do get an accurate set of notes about making "private interconnect" work (if that is what I have achieved) perhaps that might be a contribution to the greater good. Off for a coffee, then I shall start looking, measuring and tinkering again. Dave Price _______________________________________________ SunRay-Users mailing list SunRay-Users@filibeto.org http://www.filibeto.org/mailman/listinfo/sunray-users