1 |
Dan Farrell wrote: |
2 |
> Thanks for your responses, all. |
3 |
> |
4 |
> |
5 |
> On Wed, 07 Nov 2007 10:30:22 -0800 |
6 |
> kashani <kashani-list@××××××××.net> wrote: |
7 |
> |
8 |
>> First off don't assign separate IPs to each port on your four port |
9 |
>> card, bond them into a single interface. That will simplify your |
10 |
>> config and perform better. |
11 |
> |
12 |
> Perhaps I will; that's not a bad idea. However, I will still have |
13 |
> another interface that is to handle non-NFS traffic. (The reason I |
14 |
> split it this way, by the way, is that NFS is the only network service |
15 |
> that might potentially be limited by bandwith. |
16 |
> |
17 |
>> Second, what sort of routing are you doing? If all the clients are on |
18 |
>> the same subnet as the four port card you should not need routing. |
19 |
>> Additionally if they are on the same subnet you should not be limited |
20 |
>> by the speed of your gateway which may or may not be able to route at |
21 |
>> 4 Gb/s whereas your switch may actually have that sort of |
22 |
>> performaance. Are the clients on a separate subnet and if so can you |
23 |
>> put them on the same subnet? |
24 |
> |
25 |
> No, they're all on the same subnet. Each of the 5 interfaces adds a |
26 |
> route to that subnet (no gateway, as you said, it's the same broadcast |
27 |
> domain) but the routes all have different metrics. The first such |
28 |
> route chosen is the one that gets all the traffic. The NFS server is |
29 |
> used primarily for Read access, so this routing problem does a pretty |
30 |
> good job mitigating any benefit of having so many interfaces. |
31 |
> |
32 |
> Oh, by the way, this is 100-T, not Gigabit. Do I sound rich to |
33 |
> you : ) ? |
34 |
|
35 |
Buying a single GigE card would appear to be simpler and cheaper unless |
36 |
you don't have a GigE switch. :-) |
37 |
|
38 |
> So, let's say I bond the 4 together. Now I have 2 interfaces, a bond |
39 |
> and eth0. I still need to route through one or the other, so I still |
40 |
> have the problem. |
41 |
> |
42 |
> I am reading about policy routing, which should be able to solve the |
43 |
> problem by allowing routing based on the source rather than the |
44 |
> destination. I will keep the lists informed... |
45 |
|
46 |
You should not need to do any routing and I'd be surprised if Linux is |
47 |
actually doing any routing in this case. However depending on how you |
48 |
are testing you might see some issues. |
49 |
|
50 |
Let's assume you've got this network. |
51 |
|
52 |
server eth0 10.11.12.21/24 |
53 |
server eth1 10.11.12.22/24 |
54 |
|
55 |
client1 eth0 10.11.12.101/24 |
56 |
client2 eth0 10.11.12.102/24 |
57 |
|
58 |
The server will have all sorts of nonsense about 10.11.12.21 |
59 |
255.255.255.255 routes and you can ignore all that. Additionally when |
60 |
you initiate a connection from your server it will always originate from |
61 |
eth0 because 0 comes before 1 IIRC. Just one of those things. However |
62 |
when you initiate a connection from a client to eth1 the server should |
63 |
respond out the same interface. I'd play around with tcpdump on a client |
64 |
and see if this is happening like it should be. |
65 |
|
66 |
You might also try forcing portmap to bind to one IP in |
67 |
/etc/conf.d/portmap. |
68 |
|
69 |
If for some reason I'm completely off base and Linux is defaulting out |
70 |
eth0 for connections coming into eth1 you can always do the lo tech |
71 |
solution. Assuming the above network we then assign a separate subnet to |
72 |
eth1 and an alias to each client. |
73 |
|
74 |
server eth0 10.11.12.21/24 |
75 |
server eth1 10.11.88.21/24 |
76 |
|
77 |
client1 eth0 10.11.12.101/24 |
78 |
client1 eth0:0 10.11.88.101/24 |
79 |
client2 eth0 10.11.12.102/24 |
80 |
client2 eth0:0 10.11.88.102/24 |
81 |
|
82 |
The machines connect on 10.11.88.0/24 and you avoid any interface |
83 |
confusion. |
84 |
|
85 |
kashani |
86 |
-- |
87 |
gentoo-user@g.o mailing list |