Etherchannel can be a Good Thing (tm) but it doesn't do what I was trying to do.
I hadd four adapters on my TSM server bundled as an etherchannel. I also bundled two adapters each on my R3 Database Servers as an etherchannel. Here's the way this worked in a Cisco switch environment: DB server opens session 1 to TSM; AIX decides to usee port 1 of the etherchannel. The switch sees the incoming data and decides that Dbserver1 will use port 1 of the destination etherchannel. So far, so good. Now, DB server opens second session to TSM; AIX uses port 2 of the etherchannel (the other adapter). Still good-to-go. And then the switch steps in -- and says "since you are Dbserver1 accessing TSM, you get port 1 (again)". So now I have two gigabit cards on my DB server feeding one gigabit card on my TSM server. Not what I'd planned. Note that this is NOT an issue if (A) you're feeding multiple 100 Mb feeds to gigabit adapters, or (B) feeding multiple source systems with one interface each to the TSM server. It only crops up when trying to feed one etherchannel to another. Tom Kauffman NIBCO, Inc -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Ben Bullock Sent: Tuesday, July 18, 2006 10:12 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: Network tuning question -- AIX to AIX Those settings look good, but don't you also have to set this value "rfc1323 = 1" so you can take advantage of TCP send and receive sizes larger than 64K? Ben -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Jacques Van Den Berg Sent: Tuesday, July 18, 2006 7:07 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: Network tuning question -- AIX to AIX Hi, I assume you are using TSM & AIX. We have applied the following settings on AIX for our GIGABIT ETHERS. original settings: sb_max = 1048576 udp_recvspace = 42080 udp_sendspace = 9216 tcp_recvspace = 16384 tcp_sendspace = 16384 The following settings has been applied: no -o sb_max=2097152 no -r -o sb_max=2097152 no -o udp_sendspace=65536 no -r -o udp_sendspace=65536 no -o udp_recvspace=65536 no -r -o udp_recvspace=65536 no -o tcp_recvspace=262144 no -r -o tcp_recvspace=262144 no -o tcp_sendspace=262144 no -r -o tcp_sendspace=262144 I was looking at setting up Etherchannel in our environment. Do you recon it is not worth doing it? What issue did you experience? Regards, Jacques van den Berg TSM / SAP Storage Administrator Pick 'n Pay IT Email : [EMAIL PROTECTED] Tel : 021 - 658 1711 Fax : 021 - 658 1699 Mobile : 082 - 653 8164 Dis altyd lente in die hart van die mens wat God en sy medemens liefhet (John Vianney). -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Kauffman, Tom Sent: Monday, July 17, 2006 3:59 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Network tuning question -- AIX to AIX We finally figured out that ehterchannel was not doing what we wanted last week, so we re-configured our gigabit ethernet adapters as individual adapters on six separate internal networks. Now I've run into another interesting observation. I can fire up one interface from a client system to my TSM server with the ftp process coverd in the tuning doc (from /dev/zero to /dev/null) and get 110 MB per second over the interface. If I then fire up the second interface on the same client to the TSM server -- I get 110 MB/sec as an aggregate; both interfaces run at 55 to 58 MB/sec. This is not a TSM server constraint; I can get all six interfaces running at 110 MB/sec if I run one process on each of six clients. So it's a client tuning issue -- and not a problem with input from /dev/zero, as these results mirror my TDP/R3 backups this weekend. Any suggestions on what knobs to tweak? Better yet, any suggestions on how to determine what resource constraint I'm hitting? I'm beating my way through the various redbooks that cover network tuning, but this can be time-consuming. TIA Tom Kauffman NIBCO, Inc CONFIDENTIALITY NOTICE: This email and any attachments are for the exclusive and confidential use of the intended recipient. If you are not the intended recipient, please do not read, distribute or take action in reliance upon this message. If you have received this in error, please notify us immediately by return email and promptly delete this message and its attachments from your computer system. We do not waive attorney-client or work product privilege by the transmission of this message. Read our disclaimer at: http://www.picknpay.co.za/pnp/view/pnp/en/page5093? If you don't have web access, the disclaimer can be mailed to you on request. Disclaimer requests to be sent to [EMAIL PROTECTED] Read our disclaimer at: http://www.picknpay.co.za/pnp/view/pnp/en/page5093? If you don't have web access, the disclaimer can be mailed to you on request. Disclaimer requests to be sent to [EMAIL PROTECTED] CONFIDENTIALITY NOTICE: This email and any attachments are for the exclusive and confidential use of the intended recipient. If you are not the intended recipient, please do not read, distribute or take action in reliance upon this message. If you have received this in error, please notify us immediately by return email and promptly delete this message and its attachments from your computer system. We do not waive attorney-client or work product privilege by the transmission of this message.
