Elliott Peeler wrote:
Aha!
Interesting. When I ran the utadm -A I did it for three different
remote subnets. For two of the subnets it guessed the proper subnet
mask so I just accepted the default. For one of them, it guessed
incorrectly and so I entered the correct mask manually. That is only
one that showed up in /etc/netmasks. I was testing on one of the
others (that didn't have an entry) and it wasn't working. When I
tested on the one that does have entry in netmasks, it works.
Is this a bug in utadm perhaps?
I guess it is the responsibility of the admin to make sure that proper
netmasks defined.
Hope your issue is resolved after adding the netmasks entry for the non
working subnet DTUs.
Thanks
P.S.M.Swamiji
Note: These are my personal opinions, nothing to do with my employer
P.S.M.Swamiji wrote:
On 09/22/09 18:18, Elliott Peeler wrote:
Indeed, the DTUs in question are not on the same subnet as the
Sunray server but I have configured a DHCP relay agent to forward
the requests to the Sunray Server. The DTU belongs to 165.127.206.0
as you surmised.
Does /etc/netmasks of Sun Ray server contain your DTU subnetwork entry ?.
Thanks
P.S.M.Swamiji
Note: These are my personal opinions, nothing to do with my employer
We've been running this system with the dedicated interconnect for
some years now with no issues, however we now need to implement
remote, routed DTUs. I'm certain I've just overlooked something
simple. Does DHCP need to be told to offer information over the
public interface in some way above and beyond just utadm -A?
Thanks for the help.
Elliott
P.S.M.Swamiji wrote:
On 09/22/09 02:01, Elliott Peeler wrote:
I have DTUs on a remote subnet. The basic IP information is being
supplied to the DTU by a separate dhcp server. I've configured IP
forwarding on the router to forward to both the DHCP server and
the Sunray server. I've run utadm -A <subnet> on the sunray server
and restarted Sunray services.
The DTU boots and gets an IP address and then goes into 27B
broadcasting for a sunray server but never gets out of that state.
I've run snoop on the Sunray server and can see the inbound DHCP
request but the server never responds to it.
I have a gui firmware on this DTU so I set it to DHCP for basic IP
parameters but specified the Sunray server in the DTU
configuration menu and it works fine. It seems to be specifically
that DHCP on the sunray server is not responding to requests from
the DTU.
As a side note, I also have a dedicated interconnect on this same
server serving DTUs successfully. Is there a restriction that
keeps me from doing both?
No.
However you should make sure that the DTUs and the Sun Ray server
in the same subnet or atleast make sure
that the DHCP relay configured to forward the DHCP requests to the
subnet that's having Sun Ray server.
In the below configuration, I see configured subnetwork is
165.127.206.0 and the auth
server belongs to different subnet 164.254.253.126. Is the DTU
belongs to 165.127.206.0
subnetwork?.
Thanks
P.S.M.Swamiji
Note: These are my personal opinions, nothing to do with my employer
I don't see anything related in /var/adm/messages, or
/var/opt/SUNWut/log/messages etc...
Any advice as to where to look would be appreciated greatly.
Thanks in Advance.
r...@sunray01# /opt/SUNWut/sbin/utadm -l
LAN connections: On
Subnetwork: 165.127.206.0 /(remote subnet)/
Netmask= 255.255.255.0
AuthSrvr= 164.254.253.126
AltAuth= 164.254.253.126
FirmwareSrvr= 164.254.253.126
NewTver= 3.1_120879-06_2007.03.13.15.14
Subnetwork: 172.25.0.0 /(dedicated interconnect)/
Interface= fjgi0 (172.25.0.1)
Netmask= 255.255.0.0
Broadcast= 172.25.255.255
Router= 172.25.0.1
AuthSrvr= 172.25.0.1
AltAuth= 172.25.0.1 255.255.255.255
FirmwareSrvr= 172.25.0.1
NewTver= 3.1_120879-06_2007.03.13.15.14
Ceri Davies wrote:
On Fri, Sep 18, 2009 at 09:48:55AM -0700, Kent Peacock wrote:
On 09/18/09 09:22, Joerg Barfurth wrote:
If you are using .parms files anyhow, you can put it there. This works
best, if all DTUs need the same MTU.
Actually, this should be a last resort. The characteristics of the
network should really be given by the tools that give the other
characteristics of the network, primarily DHCP. Any path MTU issues
should be discovered when the DTU sees fragmented packets. The only
reason I put this into the .parms file is that a customer had a
situation where there was transparent fragmentation occurring within a
VPN connection. It caused a performance issue, and couldn't be detected
by the DTU's seeing fragmented packets.
Oh. I had taken the presence of this option as an implication that the
DTUs didn't do path MTU discovery properly. Documentation might be
clearer on that point.
Good news, though.
Ceri
------------------------------------------------------------------------
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
------------------------------------------------------------------------
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
------------------------------------------------------------------------
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
------------------------------------------------------------------------
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
------------------------------------------------------------------------
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
