Elliott Peeler wrote:
Well, adding to /etc/netmasks didn't get it.
I believe you need to re-add the utadm -A <issue-subnetwork> after
updation of /etc/netmasks file.
Update /etc/netmasks file with <issue-subnetwork> entry
Run utadm -D <issue-subnetwork>
utadm -A <issue-subnetwork>
Thanks
P.S.M.Swamiji
Note: These are my personal opinions, nothing to do with my employer
I Launched dhcpmgr on the sunray server and saw that while there were
*macros* for all three of my new remote subnets, only the one (the one
which had the incorrect subnet mask guess when running utadm) was
actually configured under the Networks tab. If I add one the
non-functioning subnets manually to the list of Networks with dhcpmgr
things start working as expected whether there is an entry in
/etc/netmasks or not.
For kicks I tried the same thing on one of my development sunray
servers which is running SRSS4.1. Same thing. The entry for the subnet
is not getting added to the DHCP scope under Networks even though the
macros for the subnets are in there. Weird.
Elliott
P.S.M.Swamiji wrote:
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
------------------------------------------------------------------------
_______________________________________________
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
