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