Linux-Networking Digest #864, Volume #9 Wed, 13 Jan 99 01:13:37 EST
Contents:
Re: Load balancing router for multiple WWW servers (Philip Wall / Wild Card)
Re: Advanced routing question. (bill davidsen)
Re: External ISDN adapter - Does it need to use mlppp? (tom)
Re: Win98 on LAN served by a LINUX (Philip Wall / Wild Card)
Kernel Threads: Dr. Russinovich's response [FWD] ([EMAIL PROTECTED])
Re: stranger on port 9 and 111 (Villy Kruse)
Re: 100% RX packages overruns.. ([EMAIL PROTECTED])
Firewall/arp. (Jon Charette)
Re: /etc/services (Ed Robbins)
Re: SCSI (Johan Kullstam)
----------------------------------------------------------------------------
From: Philip Wall / Wild Card <[EMAIL PROTECTED]>
Subject: Re: Load balancing router for multiple WWW servers
Date: Tue, 12 Jan 1999 22:39:02 -0600
Reply-To: [EMAIL PROTECTED]
Chris Goebel wrote:
>
> Is it possible to configure a linux router so that
> incoming connections to a WWW server IP are "masqueraded"
> between multiple servers?
>
> For example the ideal situation would look like this:
>
> INET
> |
> Linux Router
> / \
> ApacheSrv1 ApacheSrv2
>
> As WWW requests come from the INET I would like the router
> to randomly select ApacheSrv1 or 2 and then use IP masquerading
> to establish the connection.
>
> This could be very useful when you have a site that cannot
> be serviced by a single WWW server. While the feature
> is a very simple variation of the "masquerade"
> feature.
>
> -Chris
The IP_NAT stuff does that pretty much. Or atleast thats what it's
designed to do.
http://www.csn.tu-chemnitz.de/HyperNews/get/linux-ip-nat.html
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Name:Philip Wall
Handle:Wild Card
e-mail:[EMAIL PROTECTED]
Thought of the day:
Disc space -- the final frontier!
------------------------------
From: [EMAIL PROTECTED] (bill davidsen)
Subject: Re: Advanced routing question.
Date: 13 Jan 1999 05:18:32 GMT
In article <[EMAIL PROTECTED]>,
Ben Greear <[EMAIL PROTECTED]> wrote:
| > >Is there a way to force linux (and other routers?) to route based
| > >solely on the destination, and without regard to the physical
| > >interface that it came in on?
| >
| > That's the default behavior, as long as the subnet masks are correct for
| > all clients. Why do you feel you need to use force?
|
| That is the problem, it is possible that there are more than one
| client on the same subnet on the same ethernet port (the converse is
| also true: They may be on different subnets.)
|
| This is non-standard ethernet behavior, but that is what we have.
Sounds standard to me, packets go out based on IP in the routing table.
Period. Unless you diddle interface based routes or firewall stuff,
socket mapping, etc, it works just as you want.
| Each client must send packets directly to the router, as opposed to
| it's 'neighbor' on the same subnet, and same physical port (as seen
| by the router). Normally, the client has already seen this packet,
| so the router will ignore it.
|
| At least that is my understanding of the problem...
You don't understand the problem. If routing is set up properly *on the
client* the packet will go to the router, then the destination. The
destination will *not* have seen it because the destination MAC address
will be that of the router.
If it isn't working that way look for problems in the routing tables of
the non-router machines. I do this in several ways, if the sender has
only the router address for the destination, it sends to the router. If
the MAC address of the destination is the router the final destination
will not see the packet.
This IP vs. MAC is complex, add ICMP redirect and mix with beer...
--
bill davidsen <[EMAIL PROTECTED]> CTO, TMR Associates, Inc
"Too soon we grow old, and too late we grow smart" -Arthur Godfrey
------------------------------
From: [EMAIL PROTECTED] (tom)
Crossposted-To: comp.os.linux.help
Subject: Re: External ISDN adapter - Does it need to use mlppp?
Date: Wed, 13 Jan 1999 05:28:57 GMT
Reply-To: [EMAIL PROTECTED]
>[EMAIL PROTECTED] (Mark Cooperstein) wrote:
>
>> If you've never gotten a mlppp
>>connection, check with your ISP and see if they've enabled your account for a
>>mlppp connection. This ususally means giving your account for two
>>simultaneous login's at one time (which normally they dont allow).
>
>Don't bother. The original poster is at Earthlink, and we do not
>allow multiple logins under any circumstances. You can get a two B
>channel connection, but it's up to the routers at the PoP to give it
>to you. (Second channel gets the same IP, and if it's on a different
>router, down it goes.)
Well I can connect to Earthlink now but only with one channel. I've
read in the HOWTO's that you need to use a '&' between numbers after
your ATD command. Mine looks like this -
ATD 12345551212 & 12345551212
Still I can only connect one channel. Dammit, I can get both channels
in Windows why can't I do it in Linux? Any ideas? Anyone?
Tom
------------------------------
From: Philip Wall / Wild Card <[EMAIL PROTECTED]>
Subject: Re: Win98 on LAN served by a LINUX
Date: Tue, 12 Jan 1999 23:10:21 -0600
Reply-To: [EMAIL PROTECTED]
Alan Shih wrote:
>
> Here is what I have on the LAN:
> * LINUX (Redhat 5.2)
> * NT
> * WIN98
> * WIN95
>
> All of them are networked properly (at least they talk to each other)
>
> When LINUX dials out to ISP and connected to the Internet, I would be able
> to use netscape or read emails on either NT or WIN95, with IP Forwarding
> setup on the LINUX.
>
> Now, I added a WIN98 onto the LAN, and works fine with local machines
> through network. But somehow I could not go to any where on the Internet.
> Seems that WIN98 is not working with the IP forwarding stuff. I checked the
> network setup and to me, it seems to be set up properly (otherwise I would
> expect that it did not talk to any local machine at all!)
>
> Any experience or pointers would be greatly appreciated.
>
> Alan
Check to make sure Win98 is setting up it's default gateway correctly.
One sure way to see is to go to a DOS prompt and type "route print" on
the 98 box. If you've seen printouts of the Linux route command you can
figure this one out. Generally your looking for a line that says the
Network Address is 0.0.0.0 the Netmask is 0.0.0.0 and the gateway is set
to the IP of the Linux machine.
I have seen Windows not set this correctly even after a reboot. The
only fix was to turn the machine of completely, let it set and fire it
back up. All worked then.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Name: Philip Wall
Handle: Wild Card
e-mail: [EMAIL PROTECTED]
Thought of the day:
The goal of science is to build better mousetraps. The goal of nature
is to build better mice.
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To:
alt.linux,alt.os.linux,comp.os.linux,linux.dev.kernel,linux.support.commercial,jaring.pcbase,alt.comp.malaysia
Subject: Kernel Threads: Dr. Russinovich's response [FWD]
Date: Wed, 13 Jan 1999 03:56:07 GMT
Reply-To: [EMAIL PROTECTED]
From: Scott Doty <[EMAIL PROTECTED]>
Date: Mon, 11 Jan 1999 09:25:18 -0800
Subject: Kernel Threads: Dr. Russinovich's response
The following is Dr. Russinovich's response to criticisms of his article.
He points out:
"I expect my criticisms will help, not hinder, efforts to
get Linux ready for the enterprise"
-- for this reason, I thought I'd better forward it.
(Minor change: I've reformatted the paragraphs.)
-Scott
- - -[ begin forwarded message ]- - -
Date: Thu, 07 Jan 1999 13:16:20 -0500
From: Mark Russinovich <[EMAIL PROTECTED]>
Subject: Re: Linux threads -- as seen in NT Magazine (Alan, Linus, please
read)
You are receiving this e-mail in response to correspondence you've sent me
or Windows NT Magazine regarding my statements about Linux and enterprise
applications.
- -----------------------------------------
I've exchanged several rounds of e-mails with Linux developers that, in
spite of my arguments, propose that there is really nothing wrong with
Linux's support for SMPs (as of 2.1.132, which is close to what will be
called Linux 2.2).
I have been straightened out on a few minor
(peripheral) misconceptions I had, like my
original belief that the X library was not reentrant.
However, I can only conclude that I've done a poor job of explaining my
reasoning.
I hope to clarify things here, and want to avoid and
endless religious argument by focusing on substantive
technical shortcomings of Linux�s support for enterprise
applications.
Before I start, I want to make it clear that what I view as flaws in Linux
won't necessarily affect day-to-day applications:
o They definitely affect enterprise (network server)
applications like Web serves, database servers
and mail servers, where competing in the enterprise
means delivering the highest performance possible.
o The SMP support and evolution to real kernel threads
is a work in progress that lags far behind commercial
UNIX and Windows NT.
I expect my criticisms will help, not hinder, efforts to get Linux ready for
the enterprise.
The major limitations with Linux's thread support and SMP scalability are:
- The implementation of select() is not suitable for
high-performance enterprise applications
- The non-reentrancy of the read() and write() paths
will cripple the ability of enterprise applications to
scale on even 2-way SMPs
- The lack of asynchronous I/O make the implementation
of enterprise applications more complex, and also
affects their ability to scale
- Even with asynchronous I/O, there must be support in
the kernel scheduler to avoid thread 'overscheduling',
a concept that I'll explain :
Given the fact that Linux does not support
asynchronous I/O, a network server application
must rely on select() as its method to wait for
incoming client requests.
Most network server applications are based on
TCP, where clients connect via a publicized
socket port address. The server will perform a
listen() on the socket and then select() to wait
for connections.
In order to scale on a SMP the application must
have multiple threads waiting for incoming connections
(alternate architectures where only one thread waits
for requests and dispatches other threads to handle
them introduces serialization of execution and a level
of interprocess synchronization that will adversely
affect performance).
The problem with this approach on Linux is that whenever a connection is
ready on a listen socket, all the threads blocked on the select() for the
non-blocking accept() will be signaled and awaken.
Only one thread will successfully perform the accept(),
and the rest of the threads will block.
This effect of having all waiters wake when there is I/O on a shared socket
has been called the 'thundering herd' problem.
Threads wake up to take CPU time, introduce context
switching, and add addition system calls, all for no benefit.
The non-reentrancy of the read() and write() paths has been downplayed by
even the core Linux developers, which comes as a surprise to me.
To demonstrate why this is such a major problem when it comes to enterprise
application scalability, I'll elaborate.
Let's take a multithreaded SMP network server
application that is being driven by clients to maximum
throughput.
Server applications accept incoming client
requests, typically read some data and then
write (send) it back to the client.
If the application is being driven to capacity
by the clients, the bottleneck will become the
read and write paths through the kernel.
Assuming that these calls don't block because
the data being read is in a memory cache (a web
cache or database cache), and given that these
paths are non-reentrant, read and write execution
is serialized across the SMP.
That means that at any given point in time there can
be at most one thread on the entire machine reading
or writing.
While this might not seem like a big deal, it is actually probably the
biggest problem with Linux�s ability to compete in the enterprise right now.
On Windows NT, the network driver write path is
serialized by NT's NDIS network driver library, and
this alone has put an upper ceiling on NT's ability to
scale and to compete with Solaris.
Microsoft is addressing this in NT 5 (and NT 4SP4)
by deserializing the NIC write path.
My point is that just serializing the network driver is enough to affect
scalability - try to imagine what effect serializing the entire read and
write paths has.
The next limitation is Linux's lack of asynchronous I/O. This causes
problems when a network server application does not find requested file data
(eg. a web page or database records) in its in-memory cache.
The application will have to dedicate a thread to
reading the required data. Because there is no
asynchronous I/O, the thread reading the data will
become indisposed when it blocks waiting for the
disk.
Thus, in the absence of asynchronous I/O Linux is confronted with a dilemma:
* Either launch one thread for each client request, or
* Limit scalability by having a limited pool of threads,
Some or all of which can become a bottleneck because
they block for file I/O.
Either approach limits scalability even in situations where you have a 99%
hit rate, but the misses (which account for much larger responses for
caching servers) account for 90% of the bandwidth. This is the real world...
Even if asynchronous I/O is implemented (I've seen a request for it on the
current Linux wish list), scheduler support must be added to avoid
'overscheduling'.
Overscheduling results when all threads in a server's
thread pool race to get new work. Most of the threads
lose the race, block, and race again. This is inefficient.
The only way around it is to keep threads slightly starved such that they
never block waiting for a request to process. This allows new requests to be
serviced immediately while responses requiring I/O are managed
asynchronously on blocked threads.
When more than two threads are active (running) on a
CPU, they introduce context-switching overhead as
they compete for CPU time.
Thus, the goal of a server application is to have roughly one active thread
per CPU at any given point in time.
Without scheduler support this can only be reasonably
accomplished by limiting the number of threads the
server application creates for each CPU so that the lack
of threads itself will result in missing opportunities to
service new requests.
Without asynchronous I/O, however, this hurts scalability (as the above
paragraph describes).
NT solves this problem with the notion of 'completion ports',
where a completion port represents completed I/O on a
number of file descriptors, and the scheduler limits the
application to having only a certain number of threads
active per port.
When a server thread blocks on I/O it becomes inactive
and the scheduler will wake up another one that is blocked
on the port so that the goal of the 1 thread/CPU goal can
be maintained.
This model works well with asynchronous IO and SMPs and explains NT's good
standing in TPC and (unaccelerated) SpecWeb benchmarks.
Several of developers have boasted about how elegant Linux's clone model is.
From an administrative point of view, it leaves something
to be desired.
On other operating systems where a process is the
container for threads, the threads can be managed as
a unit. They are visibly identifiable as a unit and
administrative tools and programming APIs can treat
them as a unit.
On Linux, the flexibility introduced (which I see no
clear argument for) means that they can only be
treated as unit programmatically if they decide to
share the same process group.
From the visibility standpoint of an administrator wanting to
kill a set of clones that share an address space, or monitor
their resource usage as a unit, the model is lacking.
I can only surmise that Linux kernel developers believe clones are elegant
because their implementation has the minimal impact on the kernel possible
to approximate real kernel threads. I understand the perspective, but the
result is less than elegant.
After careful examination of LinuxThreads, the defacto Linux threading
library, it appears to me that there is at least one severe performance
problem with its current implementation.
That problem lies in the way that the thread library
manages signals on behalf of all the threads by
implementing global signal handlers.
This is especially problematic because all threads
that perform a sigwait() call will wake-up when a
I/O is ready for any file descriptor, regardless of
whether any given thread happens to be waiting for
I/O on that descriptor.
The thread library performs a check for each thread to see if its wait was
satisfied, and if not, puts the thread back in a wait state.
This makes sigwait() useless in any multithreaded
application that cares about performance.
What I don't understand about the LinuxThreads implementation is why the
library doesn't take advantage of process groups to handle signal broadcast,
and otherwise let each thread manage its own signal handlers, using process
ids for targeted delivery?
Is this implementation required because of Linux
architectural limitation or has it simply not been
optimized?
In the same vein, why is there a need for a 'manager'
thread to begin with?
A less significant area where the Linux thread model can be viewed as
immature is in the fact that the Memory Manager is unaware of threads.
When it performs working set tuning (swapping out pages
belonging to a process) it will tend to be much more
aggressive with clones sharing an address space, since the
tuning algorithms will be invoked on the same address space
on behalf of each clone process that shares it.
Several tuning parameters are store privately in a clone's
task control block, like the swapout target, so the
Memory Manager will be unaware of any tuning it has
just recently performed on that address space, and blindly
go through its algorithms anew.
Thus, there are a number of critical areas that must be addressed before
Linux can be considered to have a real (competitive) kernel-mode threads
implementation and a scalable SMP architecture.
And until it has these things Linux cannot compete
in the enterprise with UNIX rivals or with Window NT.
Thanks for your e-mail.
- -Mark
Mark Russinovich, Ph.D.
Windows NT Internals Columnist, Windows NT Magazine
http://www.winntmag.com
The Systems Internals Home Page
http://www.sysinternals.com
- - -[ end forwarded message ]- - -
------------------------------
From: [EMAIL PROTECTED] (Villy Kruse)
Subject: Re: stranger on port 9 and 111
Date: 12 Jan 1999 18:20:40 +0100
In article <[EMAIL PROTECTED]>, Stef <[EMAIL PROTECTED]> wrote:
>A have some stranger connected to ports of the following services:
>discard (9), sunrpc (111), mountd and nfsd
>I see the IP of the stranger via netstat. Since I'm not sure wether he
>can do any harm or not, I stopped mountd and nfsd.
>How can I find out wether my system is vulnerable on these services?
>Is there any danger comming from connections to discard and sunrpc
>services itself?
>I use Debian 2.0
>
If you don't need nfs don't enable the server. If there any other
services you don't need disable them.
Villy
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: 100% RX packages overruns..
Date: Tue, 12 Jan 1999 17:44:45 GMT
[posted and mailed]
You might try to find a copy of ewrk3tools from redhat or your CD
and see if that tells you anything - possibly there's a setup
problem on the card - using the wrong connector or something. Also
have you switched patch cables? can you try another machine on the same
cable?
"Egger" <[EMAIL PROTECTED]> wrote:
> I got the opportunity to buy an HP NetServer 4/66 LC recently. It comes
> along with 32MB of RAM, a SCSI harddrive of 1.2 GB, a 3.5'' floppy drive and
> a SCSI CD-ROM.
> My intention is to set up a network, where this machine is to function as a
> file- and services
> server.
> While I did not have any problem to install and run LINUX (RedHat
> distribution 5.0) on this machine I am not able to configure the ethernet
> network. The network card is o.k, because it is a moved one from another PC,
> where it worked always perfectly under LINUX (identical RedHat installation)
> and also under Windows95.
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (Jon Charette)
Subject: Firewall/arp.
Date: 12 Jan 1999 13:10:14 -0600
Reply-To: [EMAIL PROTECTED]
I'm trying to create a packet filtering firewall.
I'd like to only use forwarding and no proxies if possible as all my
internal machines have real IP addresses.
So far I've been working with ipfwadm to set things up, and things are
looking good.. except..
whenever I try to use my outside interface for IP's not on my network,
I get the following in my kernel log:
Jan 12 14:08:07 wall kernel: ARP: arp called for own IP address
Jan 12 14:08:08 wall kernel: ARP: arp called for own IP address
What does this mean? I've set up the arp table to look like the
following:
/sbin/arp -i eth0 -Ds ouside.turbinegames.com eth0 pub netmask
255.255.255.240
/sbin/arp -i eth1 -Ds inside.turbinegames.com eth1 pub netmask
255.255.255.128
Am I missing something here?
Thanks.
------------------------------
From: Ed Robbins <[EMAIL PROTECTED]>
Subject: Re: /etc/services
Date: Tue, 12 Jan 1999 19:27:15 +0000
/etc/services is simply a text file that allows mapping from a port number to a
name. Reading the man page states that all network applications should use
/etc/services, but it isn't a requirement. The place you want to check for is
in the configuration file for the http server. For instance, given the appache
server, change the port setting in /etc/httpd/conf/httpd.conf to whatever port
you want.
Ed
[EMAIL PROTECTED] wrote:
> Hey all,
> quick question...
>
> I'm playing around with the port addresses of various services...
> And I can't get HTTP to be anything but 80.
> Even if I change it to something like 7080, it only exists on 80!?!
>
> I'm sure I'm missing something stupid. But I kill -HUP inetd and I even tried
> rebooting to make sure. The file /etc/services still retains my changes, is
> there somewhere else I need to play around?
>
> Thanks in advance,
> Jon
>
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Johan Kullstam <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.misc
Subject: Re: SCSI
Date: 12 Jan 1999 11:06:46 -0500
[EMAIL PROTECTED] (Gregory Leblanc) writes:
> Hi there! I've been using NT for the last couple of months, because I
> already understand how to operate it, and I didn't want to run
> something as bad a WinBlows 9x on such a nice box. Ideally, I'd like
> to run Linux and X, but I have a few questions.
> 1) Is SCSI as easy under Linux as it is under NT. I.E. I plug in a
> SCSI zip drive, and provided that it's set to a valid SCSI ID, it
> works, without any drivers or anything.
you need to compile drivers for your scsi controller. while most
popular scsi controllers are supported, check, e.g., the
Hardware-HOWTO, dejanews &c and see.
> If I have support for my SCSI
> card compiled as part of the kernel, will it recognize my ZIP drive as
> a removeable drive, and my CD-R as a WORM, or at least a read-only
> media drive?
the CD-R should be fine.
> 2) I heard someplace that NetGear had some really good 10/100Mbit
> NICs, that had features that were lacking on the 3Com Etherlink XL,
> and Intel 10/100 TX cards. Has anybody heard about this?
netgear was using dec tulip 2114x chips for 10/100Mbit ethercards.
now they are using a clone chip called lite-on pnic. many people
report problems with the clone. try to get real dec tulip. btw many
manufacturers make cards based on the tulip so netgear is not your
only option. i've got a d-link card (21140) and two dec cards (21140
and 21041).
i have two 21140 cards running at 100Mbit on my home lan. i have a
10BT 21041 card talking to cablemodem. the dec tulips are very nice and
i've had no problems with them.
i don't know if the 3Com or Intel card/chipsets are good or bad. i am
not aware of any extra functionality of the dec tulip. but then i am
by no means an expert in the area of networks and network cards.
search dejanews and comp.os.linux.networks.
--
johan kullstam
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.networking) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Networking Digest
******************************
