thanks for your comments Bob. In our situation, we are deploying approximately 2000 DTU's across 30 or so campuses - up to 500Km apart. Several of these campuses will only end up with 4-5 devices. The servers are currently housed at a central site, with a secondary site being considered. In this setting we have a significant number of paths. If the secondary site is deployed, it will be used (in part) for failover and will be physically removed from the primary site. We could therefore have different paths for the two server arrays. So for us, it may be an advantage to limit to a host group?
On Sun, 23 Jul 2006 12:50:49 -0700, ottomeister wrote > On 7/23/06, Marcus Young <[EMAIL PROTECTED]> wrote: > > could the complexity of managing MTU on the server be minimised by having a > > rule base model where the rules reflect the scope. For example, > > Sure, but even assuming that we put this information into the > Sun Ray Data Store so that it is consistent across a host > group, that does nothing for consistency across multiple host > groups. > > Maybe that doesn't matter. If it solves a problem for small > deployments then maybe that's enough justification for doing it. > It doesn't make the problem any worse for large deployments. > Maybe it's not even a good idea to try to have consistency > across groups, because the MTU is path-dependent. > > > x.x.x.x 1500 for default > > 10.88.118.x 1400 for 1400 on 10.88.118.0 subnet > > 10.10.x.x 1423 > > Sure. In fact Bob mentioned a per-subnet scheme earlier. If > we did this I expect we'd allow (perhaps require) netmask > lengths on each entry, and I expect we'd require a keyword > indicating that we were specifying the MTU (on the grounds > that once we have this mechanism we'll find more stuff that > it would be nice to set on a per-subnet basis, so we might as > well plan for it now. So it'd be more like: > > 10.10.88.1/32 mtu=1424 > 10.88.118.0/24 mtu=1400 > 10.10.0.0/16 mtu=1423 > default 1500 > > > On Sat, 22 Jul 2006 10:50:12 +0200, Ivar Janmaat wrote > > > Bob Doolittle wrote: > <snip> > > > > The reasons for specifying it at the client-end is that the > > > > MTU value is a function of the path between the client and > > > > the server, not something global to the server. > > But that has precisely the same issues, just the other way > around. The problem is that the MTU is path-dependent, > not source- or destination-dependent. The only reason why > forcing the MTU at the DTU is a better approach is that it's > far more likely that the DTU is the thing on the end of the > constrained-MTU pipe, therefore reducing the MTU at the > DTU is more likely to give a correct result more often. That > is, you can configure a reduced MTU in one place (DHCP) > and have that setting produce the correct result for the > DTU's connections with hundreds of Sun Ray servers. If > you had to configure the MTU at the server end then you'd > have to perform that configuration step on hundreds of > servers. > > In Ivar's case the balance is the other way around. He has > to configure DHCP in dozens or hundreds of places, whereas > he would only have to configure one (or a small handful) of > servers to achieve the same result. > > > > I would like it if Sun would be able to handle this as a RFE for the > > > next SRSS update. Would this be possible? > > Is there an actual RFE logged with Sun? If not then the > people who decide which features go into which releases > don't even know that anyone wants such a feature. If > there is such an RFE then it'd be good to mention its ID here > so that others who want this feature can add customer > calls to it. Customer call records carry far more weight than > Sun-internal calls. > > Even better, IMO, would be to make the MTU self-tuning. > That's a little harder and a little more work than allowing for > explicit configuration, but if it works then it's much less work > for the customer. Unfortunately some networks are so > broken that we're probably always going to need an explicit > configuration mechanism to fall back on. > > OttoM. > __ > ottomeister > > Disclaimer: These are my opinions. I do not speak for my employer. > _______________________________________________ > 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
