Steffen; Thank you for your response and suggestion for me to revisit my configuration. The configurations are similar, in that I am using unrouted IP addresses, but a different set and with different default routes. What I did realize was that on the 220R, the DNS server is running and correctly configured and in the test environment of the 240, the dns server is not always available and wasn't available for my testing.
When logging in, the host I'm connecting to does a reverse dns lookup for the source ip address, which in my test environment fails. In the past, under Solaris 2.5, through I think 2.9, all that was necessary was to configure the host in the /etc/host file and ip lookups were resolved by the hosts file, assuming that the hosts entry in the nsswitch.conf listed files before dns. I understood that my dns server was not available, but relied on past experience and assumed that the ip lookups would be resolved by the hosts file. I can resolve the apparent network responsiveness issue by editing the nsswitch.conf file to eliminate all dns references, ipnodes and hosts. When I do this, no reverse lookups are directed to the dns server. So, I am learning a bit more about Solaris networking. Other than editing my nsswitch.conf or ensuring the availability of the dns server, is there a better way to handle hosts IP resolution? This behavior I am observing seems to be a step back, but perhaps I lack understanding. Can you help me better understand the address resolution process? Daniel >>> [EMAIL PROTECTED] 10/12/2006 5:31 PM >>> Hi Daniel, Don't have anything to go by, but in general, these types of problems are due to naming or other configuration problems, which can manifest themselves because each zone has its own name space. I have run zones on systems with bge, eri, hme, nge, e1000g, and other interfaces, and haven't seen problems like that due to zones. What are some of the differences between the 220 and 240, for starters? Steffen Daniel Synnott wrote On 10/12/06 15:20,: > > I am encountering network performance issues, which I believe may be > related to network > drivers. I am observing an unresponsive network configuration on a Sol > 10 host configured > with 3 whole root zones. Outside connections to global and non-global > zones are demonstrating > 'lag' time when connecting with ssh, telnet, or remote dtlogin. > Internal connections from any > zone to another are equally impacted and are more of a concern at the > moment. In a current > configuration, pings from zones are dropped. What makes this a bit > more confusing is that > different hardware platforms display a wide range of performance > charactoristics, from no > issues with lag time observed to extremely long response times. > > I've configured three servers, ( a v240, a 220R, and a v880), with very > similar > whole root zone configurations and each displays different network > responsiveness. > The configuration involves initial installation 6/06 version and > recommended patching, 9/29/2006, > a single shared interface, all zone ip addresses on same subnet, and > all zones have netmasks, > default router, and dns configured. Each system has a very light load > because of early stages > of installation. > > The 220R with its internal hme port is very responsive, no problem at > all. I can ping each > zone internally, I can remote dtlogin from global zone to non-global > zones, ssh and telnet > work as expected. > > The v240 with its bge port configured is significantly worse. remote > dtlogin from global zone > connectivity is intermittant requiring several attempts to login. > ping, ssh, and telnet display a 'lag' time. > > The v880 non-global zones, with the eri network port, is very > unresponsive and almost unusable. > telnet and ssh demonstrate significant lag time. remote dtlogin from > global zone is impossible. > > I've found references to bge driver issues and bge driver patch, but > nothing for the eri driver. > > I'd like to collect information but would need suggestions on DTrace > scripts that would shed > light on the issues. Any suggestions? > > Daniel Synnott > _______________________________________________ > networking-discuss mailing list > [email protected] _______________________________________________ networking-discuss mailing list [email protected]
