On 2/21/07, Bob Doolittle <[EMAIL PROTECTED]> wrote:
ottomeister wrote:
> On 2/21/07, Bob Doolittle <[EMAIL PROTECTED]> wrote:
>> utadm -l should report everything.
>> Typically there's no point in mixing LAN and Interconnect, however.
>> A cleaner config would be utadm -A 192.168.132.0, as I suggested
>> earlier.
>
> That's the right thing to do *IFF* 192.168.132.0 is a properly routed
> part of the intranet.
>
> If 192.168.132.0 truly is an isolated interconnect then telling SRSS
> otherwise will break everything.
Surely not "everything". What are you envisioning?
OK, not everything. Cockroaches, rats and some unicellular
microbes will probably survive, and small bands of humans
will eke out a miserable survival among the frozen remains
of what used to be known as civilisation.
OK, OK, really it'll just completely break redirection on the
interconnect. Redirection between the Linux machines,
which is the only redirection that works today, will stop
working.
> From Suzanna's experience with
> '-L on' and then trying to 'utswitch -h skb-linux' from ndssr01 I'd have
> to believe that 192.168.132.0 really is an isolated interconnect.
I think so too. But I don't see a problem with using -A, what problem
do you see? Craig is right that she'll have to use the 192.* addresses
instead of the public IP addresses, however. Is this what you were
referring to? That's the one advantage to using the Interconnect - it
will translate the public IP to the appropriate private one internally.
Right, but that's not just an advantage, it's crucial. If SRSS
thinks that a Sun Ray is on a LAN segment then on a redirect
it will always send the DTU to the public IP of the target server.
That's fatal if the DTU is in fact on an interconnect. It will never
connect. (If you've undone the stock SRSS configuration and
enabled IP forwarding on a Sun Ray server and told the DTU to
use that server as a router then you will be able to connect, but
you'll lose the connection when that host goes down. Infuriating,
and not easy to debug.)
On the other hand, if you tell SRSS that a subnet is an
interconnect then SRSS is careful to not redirect the DTU to
an address off that subnet or even to an address that is not
known to be reachable on the subnet. If the subnet really is
an interconnect then you need this additional layer of logic.
I strongly suspect that Suzanna never restarted SRSS after utadm -L on,
otherwise we'd see "U" for all interfaces on all networks.
'-L on' would get you an 'A' on any LAN subnet. It won't do
anything for 'U'. Suzanna's 'utgstatus' shows that. Most
interestingly it produced an A on the Solaris machine's
192.168.132.0 interface, which tends to confirm my suspicion
that the 192.168.132.0 interface on the Solaris machine was
defined by 'utadm -A', declaring it as a LAN segment, when
it should have been defined by 'utadm -a' as an interconnect.
The other half of the problem -- this is the 'U' part -- is that the
Solaris box is not receiving multicasts on the 192.168.132.0
subnet, nor are its own multicasts on that subnet being
delivered to the Linux machines. That's why there's no 'U'
for that subnet, and that's the second reason why (in addition
to the missing 'A') SRSS refuses to forward DTUs from Solaris
to Linux or from Linux to Solaris.
So, my suggestion is 'utadm -L off' on all three machines,
then 'utadm -R 192.168.132.0' on the Solaris machine
followed by 'utadm -a hme0' on the Solaris machine. Then
try to figure out why multicast isn't propagating, then (when
nobody can figure that out) work around it by reconfiguring
all three machines to use broadcast rather than multicast.
OttoM.
__
ottomeister.
Disclaimer: These are my opinions. I do not speak for my employer.
_______________________________________________
SunRay-Users mailing list
SunRay-Users@filibeto.org
http://www.filibeto.org/mailman/listinfo/sunray-users
