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?
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
