I'm trying to configure two nics on our p550 application server box.
One nic connects to our core HP switch and I'd like to configure the
other to talk directly to our Oracle database server. On the Oracle
database server p560 box, I'd like to do the same, with one nic
connected to our core HP switch and the other to the application
server. I want to direct connect the two boxes with a patch cable so
the traffic does not go thru the HP switch. Are there configuration
files I need to modify to enable the routing of this traffic to go from
box-to-box and not thru the HP switch?

jdmash55@gmail.com wrote:
> I'm trying to configure two nics on our p550 application server box.

> I want to direct connect the two boxes with a patch cable so
> the traffic does not go thru the HP switch.

For a direct connection you will need a crossover patch cable. Be aware
that these are different for Fast and GBit Ethernet.
AIX Ethernet and TCP/IP Configuration for the direct connection is not
special. Configure the Ethernet Ports to a fixed speed ("smit
ethernet"), choose IP adresses from a private network like
192.168.0.0/16 , configure the interfaces accordingly and set up routing
(a single host route on either side will do) : "smit tcpip".

Check with "route get <remote-IP>" which interface your traffic is
routed to.

Joachim

Joachim Gann <nomail@nomail.com> wrote:
> For a direct connection you will need a crossover patch cable. Be
> aware that these are different for Fast and GBit Ethernet.

Indeed. Gigabit Ethernet doesn't need a cross-over cable to do
back-to-back, although it will work with a cross-over cable too. I
think the official term for it is that Gigabit Ethernet over UTP
requires Auto-MDIX, but I may be wrong on that.

I'd be curious to know why the OP wants to bypass the switch.

rick jones

still puzzling, over proper means of CPU utilization measurement for
AIX wrt HW threading

http://www.netperf.org/svn/netperf4/...glib_migration
--
The computing industry isn't as much a game of "Follow The Leader" as
it is one of "Ring Around the Rosy" or perhaps "Duck Duck Goose."
- Rick Jones
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

Rick Jones wrote:
> Joachim Gann <nomail@nomail.com> wrote:
> > For a direct connection you will need a crossover patch cable. Be
> > aware that these are different for Fast and GBit Ethernet.
>
> Indeed. Gigabit Ethernet doesn't need a cross-over cable to do
> back-to-back, although it will work with a cross-over cable too. I
> think the official term for it is that Gigabit Ethernet over UTP
> requires Auto-MDIX, but I may be wrong on that.
>
> I'd be curious to know why the OP wants to bypass the switch.
>
> rick jones
>
> still puzzling, over proper means of CPU utilization measurement for
> AIX wrt HW threading
>
> http://www.netperf.org/svn/netperf4/...glib_migration
> --
> The computing industry isn't as much a game of "Follow The Leader" as
> it is one of "Ring Around the Rosy" or perhaps "Duck Duck Goose."
> - Rick Jones
> these opinions are mine, all mine; HP might not want them anyway...
> feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...



I was under the impression that I would get better throughput bypassing
the switch due to the other server traffic already going thru it. The
switch is an HP 4108gl. If by going thru the switch I would get the
same or better performance, I'd rather eliminate the box-to-box cabling.

jdmash55@gmail.com wrote:
> Rick Jones wrote:
>
>>Joachim Gann <nomail@nomail.com> wrote:
>>
>>>For a direct connection you will need a crossover patch cable. Be
>>>aware that these are different for Fast and GBit Ethernet.
>>
>>Indeed. Gigabit Ethernet doesn't need a cross-over cable to do
>>back-to-back, although it will work with a cross-over cable too. I
>>think the official term for it is that Gigabit Ethernet over UTP
>>requires Auto-MDIX, but I may be wrong on that.
>>
>>I'd be curious to know why the OP wants to bypass the switch.
>>
>>rick jones
>>
>>still puzzling, over proper means of CPU utilization measurement for
>>AIX wrt HW threading
>>
>>http://www.netperf.org/svn/netperf4/...glib_migration
>>--
>>The computing industry isn't as much a game of "Follow The Leader" as
>>it is one of "Ring Around the Rosy" or perhaps "Duck Duck Goose."
>> - Rick Jones
>>these opinions are mine, all mine; HP might not want them anyway...
>>feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
>
>
>
>
> I was under the impression that I would get better throughput bypassing
> the switch due to the other server traffic already going thru it. The
> switch is an HP 4108gl. If by going thru the switch I would get the
> same or better performance, I'd rather eliminate the box-to-box cabling.
>

The whole purpose of a network "switch" is to separate the traffic
between source and destination. The "hub" didn't have this intelligence
and presented all traffic to all nodes connected to it. The switch is
different. The intelligence of the switch hardware segregates the
traffic from port to port. The only thing you would be successful in
filtering out is broadcast and multicast traffic. If that traffic is
really an issue, you may have bigger problems. If you are seeing more
than that, then maybe your switch is set to some sort of dumb mode,
which I have never heard of, but I come from a Cisco background.

I just looked over the documentation, and it doesn't look like it does
anything like that. In a nutshell, you may gain little, but produce
larger problems in your infrastructure down the road.

What is the problem you are experiencing?

jdmash55@gmail.com wrote:
> I was under the impression that I would get better throughput bypassing
> the switch due to the other server traffic already going thru it. The
> switch is an HP 4108gl. If by going thru the switch I would get the
> same or better performance, I'd rather eliminate the box-to-box cabling.

It depends how you measure performance. You are likely to get the same
performance for a sample ftp transfer on the direct link as over the
switch. But the dedicated link will give you dedicated bandwitdh to run
the connection to the database and other traffic at the same time.
The best solution is probably to configure the two ports as etherchannel
on both machines. You'll have double bandwidth, ethernet failover all at
the same time at the expense of two Gbit ports on the switch per server.

Markus

Markus Baertschi <markus@markus.org> wrote:
> jdmash55@gmail.com wrote:

>> I was under the impression that I would get better throughput
>> bypassing the switch due to the other server traffic already going
>> thru it. The switch is an HP 4108gl. If by going thru the switch
>> I would get the same or better performance, I'd rather eliminate
>> the box-to-box cabling.

> It depends how you measure performance. You are likely to get the
> same performance for a sample ftp transfer on the direct link as
> over the switch. But the dedicated link will give you dedicated
> bandwitdh to run the connection to the database and other traffic at
> the same time. The best solution is probably to configure the two
> ports as etherchannel on both machines. You'll have double
> bandwidth, ethernet failover all at the same time at the expense of
> two Gbit ports on the switch per server.

IIRC there is a fair bit of internal bandwidth in the 4108's. While
the internal bandwidth of the switch is not "dedicated" I suspect that
if all three systems (IIRC there were three?) were connected to the
switch that for all incense and porpoises one would not see a
difference with the extra links between being pt-pt and going through
the switch. This assumes we are talking about one switch and not
interconnected switches.

Now, if one simply shared the existing links to/from the switch then
the issue of shared bandwidth might be more pressing, but would still
be one of those "it depends" kinds of things.

I like the trunking idea, so long as one is careful about selection of
load balancing algorithms.

rick jones
--
a wide gulf separates "what if" from "if only"
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...