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
