Well, adding to /etc/netmasks didn't get it. 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
