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

Reply via email to