On Thu, 08 Nov 2007 16:40:26 -0800 kashani <[EMAIL PROTECTED]> wrote:
> I hate to pull the "expert" card, but I was the network > engineer/architect who built Netzero's original network so I've got > some passing familiarity with this stuff. I'm glad you pulled this card; I want to learn about this stuff! FWIW, I'm not entirely new to routing either. Not that I have an 'expert card' to pull, but I've definitely routed together 6 networks or so over a VPN recently so i _think_ i understand the basics of routing, but being self taught is tricky like that. I really appreciate your input. I am glad that you _do_ in fact know your stuff, because i mean to learn ; ) > My handy analogy for non network engineers is a subnet is the block > you live on. You can reach any address on it without crossing the > street. If you want to get to another block you need to use a > crosswalk. Crosswalks require routing. Good analogy! >Because I assumed you were switching the gateway and routes do not >matter. So again, are your client AND server IPs on the same subnet or >not? Yes. The real world numbers are: 192.168.1.0/24 - the subnet. 192.168.1.1 - "davey", the internet gateway and local router (it does route in both our meanings, but it doesn't enter into our discussion) 192.168.1.100 - 'pascal', my workstation, a client w/ a local disk 192.168.1.86 - 'slim', a good example client, as it's diskless and the media box, therefore accounts for a lot of the extra network traffic that i want to get of zeus's address (below) 192.168.1.87 - 'zeus', eth0 on the server 192.168.1.88 - 'nfs', bond0 (eth1-4) on the server >So cough up a diagram of your network with IPs and masks to explain >exactly what you're doing because what you've explained so far makes >little sense to a former network professional. I will gladly continue to do so. Here are some real world numbers from the server. I have freshly rebooted it so that you can see the traffic I see. As the server just rebooted for the first time with the new network device bonding, I feel it's prudent to mention that the bond device came up first. zeus ~ # cat /etc/conf.d/net| grep -v '#'|grep [a-z] modules=("iproute2"); config_eth0=( "192.168.1.87/24 brd 192.168.1.255"); routes_eth0=( "default via 192.168.1.1" ); config_eth1=( "null" ); config_eth2=( "null" ); config_eth3=( "null" ); config_eth4=( "null" ); RC_NEED_bond0="net.eth1 net.eth2 net.eth3 net.eth4" slaves_bond0="eth1 eth2 eth3 eth4" config_bond0=( "192.168.1.88/24 brd 192.168.1.255" ); routes_bond0=( "default via 192.168.1.1" ); zeus ~ # ip route 192.168.1.0/24 dev bond0 proto kernel scope link src 192.168.1.88 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.87 127.0.0.0/8 dev lo scope link default via 192.168.1.1 dev bond0 default via 192.168.1.1 dev eth0 metric 1 == we can both agree from the following that eth0 isn't carrying much traffic. zeus ~ # ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:40:CA:63:BF:00 inet addr:192.168.1.87 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:92 errors:0 dropped:0 overruns:0 frame:0 TX packets:2 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:15621 (15.2 Kb) TX bytes:84 (84.0 b) Interrupt:16 Base address:0x8000 But I've connected to this IP Address from my workstation, 'pascal' (ssh'd in). In fact, I have a few connections to .87 going: [EMAIL PROTECTED] ~ $ netstat -n | grep 87 tcp 0 0 192.168.1.100:52499 192.168.1.87:993 ESTABLISHED tcp 0 0 192.168.1.100:41837 192.168.1.87:19150 ESTABLISHED tcp 0 0 192.168.1.100:42222 192.168.1.87:514 ESTABLISHED tcp 0 0 192.168.1.100:54247 192.168.1.87:22 ESTABLISHED ========== and yet, although the server's .87 interface is showing RX traffic, as to be expected, it still shows the same 84 bytes of TX traffic. (After a few minutes): RX bytes:22672 (22.1 Kb) TX bytes:84 (84.0 b) ==== In comparison, here's the ifconfig output on bond0; clearly it's transmitting quite a bit. zeus ~ # ifconfig bond0 bond0 Link encap:Ethernet HWaddr 00:00:92:A7:C0:B5 inet addr:192.168.1.88 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1 RX packets:76131 errors:4 dropped:0 overruns:0 frame:0 TX packets:227978 errors:22 dropped:0 overruns:20 carrier:2 collisions:0 txqueuelen:0 RX bytes:31019984 (29.5 Mb) TX bytes:262332692 (250.1 Mb) ==== And finally, if you still aren't convinced that network traffic from 192.168.1.87, this tcpdump output should convince you otherwise. zeus ~ # tcpdump -c 5 -i bond0 src 192.168.1.87 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on bond0, link-type EN10MB (Ethernet), capture size 68 bytes 19:47:17.050301 IP zeus.spore.ath.cx.22 > pascal.spore.ath.cx.54247: P 1914753483:1914753595(112) ack 229541663 win 27 <nop,nop,timestamp 107467 14350230> 19:47:17.050358 IP zeus.spore.ath.cx.22 > pascal.spore.ath.cx.54247: P 112:224(112) ack 1 win 27 <nop,nop,timestamp 107467 14350230> 19:47:17.051464 IP zeus.spore.ath.cx.22 > pascal.spore.ath.cx.54247: P 224:416(192) ack 1 win 27 <nop,nop,timestamp 107467 14350257> 19:47:17.051528 IP zeus.spore.ath.cx.22 > pascal.spore.ath.cx.54247: P 416:592(176) ack 1 win 27 <nop,nop,timestamp 107467 14350257> 19:47:17.051567 IP zeus.spore.ath.cx.22 > pascal.spore.ath.cx.54247: P 592:768(176) ack 1 win 27 <nop,nop,timestamp 107467 14350257> 5 packets captured 7 packets received by filter 0 packets dropped by kernel ======== So it seems to me that routing is quite relevant, even if all the hosts in question are on the same subnet. It seems to me that if all traffic is within the subnet and all hosts are connected in the same switch or group of switches. I use the term 'broadcast domain' to describe this network segment in keeping with its definition on wikipedia: broadcast domain is a logical network segment in which any computer or other device connected to the network can directly transmit to any other on the domain without having to go through a routing device... -- http://en.wikipedia.org/wiki/Broadcast_domain What you're talking about (hubs) sounds more like a collision domain ( http://en.wikipedia.org/wiki/Collision_domain ). My only question is, how do I route NFS Transmissions out bond0 and let everything else go through eth0? (the original goal of this whole thing was to segregate NFS traffic so that heavy NFS loads from all the diskless hosts don't compete with other services). Any thoughts on all that? Where am I missing something? -- [EMAIL PROTECTED] mailing list