× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Thanks Pete and Bryan -

Here's what I've found out. I ran a comm trace and verified that my
file transfers were actually using the VLAN interface on both sides. I
reran an FTP and monitored the VRTETH01 lines using iNav. I could see
about 10% utilization on both sides and the results were as before, 60
GB in just over an hour, Transfer rate 12611.165 KB/sec. That's
approximately the same speed as before I set up the VLAN.

Then I started SAVRSTLIB and watched the VLAN utilization go up to
around 20%. This time the SAVRSTLIB completed in about 45 minutes.
(Took 63 seconds to sync.)

I'm not sure what changed. I varied the interface off and on a few
times, changed the subnet masks and changed them back. I never set up
any routing.

I'm guessing that the trace fixed it...

Regards,

Scott Ingvaldson
Senior IBM Support Specialist
Fiserv Midwest


-----Original Message-----
From: Pete Helgren [mailto:Pete@xxxxxxxxxx]
Sent: Monday, January 21, 2008 1:13 PM
To: Midrange Systems Technical Discussion
Subject: Re: Virtual Ethernet

The subnet tells the router/switch/network client whether the
destination is in the same network or needs to be routed. For example
if you had a network IP address scheme that was 10.0.10.xxx and the
subnet was 255.255.255.0. The "255" values basically say to TCI/IP
"Give me an exact match". The 0 value says "Match anything". And let's
say the client has an address of 10.0.10.10. If your target was
10.0.10.100 with the given subnet of "0" then the client "knows" that
the 100 address is on the same network and it doesn't have to go out the
gateway in order to find the target. Since both the client and the
target reside on the same logical network (they are both on the
10.0.10.xxx network, based on the subnet) the client (10) will assume it
can contact the target (100) on the same network. It won't attempt to
go out the gateway to find the target computer.

Leaving everything the same but change the subnet to 255.255.255.240 and
now the client knows it CANNOT contact the target on the local logical
network because the 240 subnet mask "masks" all IP's so that the
10.0.10.10 client can only "see" IP addresses from 10.0.10.1 -
10.0.10.14 because of the subnet it is on. In fact, given the "mask"
255.255.255.240, the "network" for the client becomes
10.0.10.1-10.0.10.14. It cannot get to any other addresses without
going out the gateway. This is all a "logical" networking scheme
enforced by the TCP/IP stack, it has nothing to do with the physical
connections between the two PC's. Even if the two PC's were physically
on the same hub/switch, they couldn't even see each other without
routing. This is the beauty of the TCP/IP stack.

I'll spare you the binary math that makes all this work but suffice it
to say that the subnet mask "tells" the client/router/switch what
network it is on so it know whether to route or not. I won't go into
network "Classes" which can further confuse at this point. And, this is
all very simplistic, leaving out many details.

If you need to see how each network is calculated, take a look at an
online network calculator. I found one here:
http://www.subnet-calculator.com/

In this specific case, Bryan's suggestion to put your vlan on a
completely different network IP scheme is a good one. Your subnetting
won't be as critical since the 10.xxx.xxx.xxx network is completely
different than the 192.168.xxx.xxx network, they will HAVE to use the
gateway to route and therefore you can use some routing entries to make
traffic follow the routes you want (or not add any routing entries at
all so they only see each other and nothing else). Use subnet
255.255.255.0 and the correct gateway and you should be good to go. The
two 10.0.0.xxx addresses should only find themselves on the same logical
network and won't even attempt to route.

I hope this is of some help.

Pete Helgren

Ingvaldson, Scott wrote:
I can try that, but Subnet Masks confuse me. What can I use that will

make ADDTCPRTE happy?

I'm not sure how much growth to plan for, we have 4 LPARs now, but
there is potential for more and I'd like to plan for 32 to be on the
safe side.

Regards,

Scott Ingvaldson
Senior IBM Support Specialist
Fiserv Midwest


-----Original Message-----
From: bryan dietz [mailto:bdietz400@xxxxxxxxx]
Sent: Monday, January 21, 2008 10:05 AM
To: Midrange Systems Technical Discussion
Subject: Re: Virtual Ethernet

I would try using an IP address range for the v-ethernet that is not
close to your regular network.

ie. if you have 192.168.x.x for regular incoming traffic try a
10.x.x.xaddress for the internal v-ethernet.

I have even used 1.1.1.1 and 1.1.1.2 for the two partitions
v-ethernet.

Bryan


On Jan 21, 2008 10:59 AM, Ingvaldson, Scott
<scott.ingvaldson@xxxxxxxxxx>
wrote:


I'm "assuming" that's what is happening, but I'm not sure exacly how
to prove it, short of a trace and I'm thinking that this should not
be



that hard to solve. I can ping the 192.168 addresses from either
LPAR



but not from any network attached workstations (which is what I would
expect.) I set up host table entries to point to the 198.162
addresses and tried to set up a route to force the outgoing traffic
to



the virtual ethernet line, but could not due to msgTCP264F -
SUBNETMASK parameter value not valid, RC0006 - The route does not
have



a subnet mask that masks the corresponding one bits in the host
portion of the route destination.

The LPAR IP addresses are configured as 192.168.10.xxx and I have
tried subnet masks of 255.255.255.0, 255.255.0.0 and 255.255.254.0.

Regards,

Scott Ingvaldson
Senior IBM Support Specialist
Fiserv Midwest


-----Original Message-----
From: Pete Helgren [mailto:Pete@xxxxxxxxxx]
Sent: Friday, January 18, 2008 4:41 PM
To: Midrange Systems Technical Discussion
Subject: Re: Virtual Ethernet

Any chance it is routing the long way around? I don't know how your
network is configured but I had one customer that was using the
"external" ports rather than the V-lan. I think we added some
routing



entries but I don't exactly remember. Use traceroute to see if the
route is OK?

Pete Helgren

Ingvaldson, Scott wrote:

I'm trying to get virtual ethernet connectivity set up between LPARs



on a 550 here. We need to do a daily transfer of a 60 GB library
between LPARs.

I created the resources and lines, gave them IP addresses,
(192.168.10.xxx) varied them on and got them talking. Unfortunately



it doesn't seem any faster than it was before.

This is the LIND on both sides:

CRTLINETH LIND(VRTETH01) RSRCNAME(CMN13) ONLINE(*YES) +
VRYWAIT(*NOWAIT) MAXCTL(40) ADPTADR(*ADPT) +
EXCHID(0569D5FF) ETHSTD(*ALL) LINESPEED(1G) DUPLEX(*FULL) +
MAXFRAME(8996) SSAP((04 1496 *SNA)(12 1496 *NONSNA)(AA +
8996 *NONSNA)(C8 1496 *HPR)) THRESHOLD(*OFF) +
GENTSTFRM(*YES) LINKSPEED(*MAX) COSTCNN(0) COSTBYTE(0) +
SECURITY(*NONSECURE) PRPDLY(*LAN) USRDFN1(128) +
USRDFN2(128) USRDFN3(128) AUTOCRTCTL(*YES) +
AUTODLTCTL(1440) CMNRCYLMT(2 5) MSGQ(*SYSVAL) +
TEXT('Virtual Ethernet')

An FTP using the new interface gave me this:
59497012608 bytes transferred in 4442.494 seconds. Transfer rate
13392.705 KB/sec.

That's 74 minutes for 60 GB, is that a reasonable speed over virtual



ethernet? I can save it to tape faster than that.

Regards,

Scott Ingvaldson
Senior IBM Support Specialist
Fiserv Midwest


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L)
mailing



list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take

a moment to review the archives at
http://archive.midrange.com/midrange-l.








As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.