Google "bonding linux". Basically at the ethernet level you make eth[0-3] = bond0. You'll then have the bandwidth of all the nics as one nic. Your switch might need some extra setup - but this is the best way to go.
On 11/8/07, kashani <[EMAIL PROTECTED]> wrote: > > Dan Farrell wrote: > > Thanks for your responses, all. > > > > > > On Wed, 07 Nov 2007 10:30:22 -0800 > > kashani <[EMAIL PROTECTED]> wrote: > > > >> First off don't assign separate IPs to each port on your four port > >> card, bond them into a single interface. That will simplify your > >> config and perform better. > > > > Perhaps I will; that's not a bad idea. However, I will still have > > another interface that is to handle non-NFS traffic. (The reason I > > split it this way, by the way, is that NFS is the only network service > > that might potentially be limited by bandwith. > > > >> Second, what sort of routing are you doing? If all the clients are on > >> the same subnet as the four port card you should not need routing. > >> Additionally if they are on the same subnet you should not be limited > >> by the speed of your gateway which may or may not be able to route at > >> 4 Gb/s whereas your switch may actually have that sort of > >> performaance. Are the clients on a separate subnet and if so can you > >> put them on the same subnet? > > > > No, they're all on the same subnet. Each of the 5 interfaces adds a > > route to that subnet (no gateway, as you said, it's the same broadcast > > domain) but the routes all have different metrics. The first such > > route chosen is the one that gets all the traffic. The NFS server is > > used primarily for Read access, so this routing problem does a pretty > > good job mitigating any benefit of having so many interfaces. > > > > Oh, by the way, this is 100-T, not Gigabit. Do I sound rich to > > you : ) ? > > Buying a single GigE card would appear to be simpler and cheaper unless > you don't have a GigE switch. :-) > > > So, let's say I bond the 4 together. Now I have 2 interfaces, a bond > > and eth0. I still need to route through one or the other, so I still > > have the problem. > > > > I am reading about policy routing, which should be able to solve the > > problem by allowing routing based on the source rather than the > > destination. I will keep the lists informed... > > You should not need to do any routing and I'd be surprised if Linux is > actually doing any routing in this case. However depending on how you > are testing you might see some issues. > > Let's assume you've got this network. > > server eth0 10.11.12.21/24 > server eth1 10.11.12.22/24 > > client1 eth0 10.11.12.101/24 > client2 eth0 10.11.12.102/24 > > The server will have all sorts of nonsense about 10.11.12.21 > 255.255.255.255 routes and you can ignore all that. Additionally when > you initiate a connection from your server it will always originate from > eth0 because 0 comes before 1 IIRC. Just one of those things. However > when you initiate a connection from a client to eth1 the server should > respond out the same interface. I'd play around with tcpdump on a client > and see if this is happening like it should be. > > You might also try forcing portmap to bind to one IP in > /etc/conf.d/portmap. > > If for some reason I'm completely off base and Linux is defaulting > out > eth0 for connections coming into eth1 you can always do the lo tech > solution. Assuming the above network we then assign a separate subnet to > eth1 and an alias to each client. > > server eth0 10.11.12.21/24 > server eth1 10.11.88.21/24 > > client1 eth0 10.11.12.101/24 > client1 eth0:0 10.11.88.101/24 > client2 eth0 10.11.12.102/24 > client2 eth0:0 10.11.88.102/24 > > The machines connect on 10.11.88.0/24 and you avoid any interface > confusion. > > kashani > -- > [EMAIL PROTECTED] mailing list > >
