RE: TCP/IP andprogramming connectivityproblem (routingtablequestion) -- MIDRANGE-L

Philip,

An excellent explanation, thank you. Just one question in regard to this:

With the two networks that you have outlined, why am I able to ping the
17.1.6.n network from the 194.130.10.1 AS/400 without a routing table entry
? Is the AS/400 managing to resolve this route somehow ?

Thanks again,
Darren 

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Philipp Rusch
Sent: 01 June 2004 08:29
To: Midrange Systems Technical Discussion
Subject: Re: TCP/IP andprogramming connectivityproblem
(routingtablequestion)

Darren,

don't care about interfaces at the AS/400 side or the side of your
application.
The underlying TCP/IP rouitng stuff should be totally transparent to your
(highlevel-) application(s).
Think of IP networks as clouds:
one cloud is the 194.130.10.x network and another is the 17.1.6.y network.

These clouds don't "know" about each other, they don't "touch" each other
since they are at different IP-ranges. To see hosts from one cloud when
looking from another cloud you need "pointers" how to get there and in case
you have private IPs (thats 10.x.y.z / 172.26.a.b / 192.168.c.d) you need to
"translate" between public and private IP-ranges and vice versa.
Now: to actually contact a system of another cloud BOTH need to know about
each other AND the way of how to get there, AT LEAST they need to know
"somebody" who knows how to reach the others (= gateway).
So it's the gateway's rule to "find a path" for you, in terms if ISP
nomenclatura this is done by inter-gateway routing protocols.
You are still with me ?
Back to your real networks: to see hosts (every machine is a host in terms
of ip networking) from net 17.1.6.y in the net 194.130.10.x you need to
define routing entries at both ends.

My example plan of your net would look like:
(the addresses of the gateways are for example only, ask your network guy)

            17.1.6.254                              194.130.10.254
17.1.6.y --- GATEWAY --< many other nets in between>-- GATEWAY --
194.130.10.x
|

|
this is the VPN network                            this is the company 
network


so the vpn side needs an entry like (windows)

route add 194.130.10.0 mask 255.255.255.0 17.1.6.254

and the company side needs an entry like (AS/400)

(doing from memory, no AS/400 here at hand)

IP=17.1.6.0 mask=255.255.0.0  gateway(=nexthop)= 194.130.10.254

So what you got to find out from your network guy is four things:

1+2: what are the network masks of both nets ?

3+4: what are the both gateways addresses ?

(above values were for explanation purposes only)


HTH, Philipp


Darren McBride schrieb:

>Crikey, this is really starting to confuse the hell out of me. Although 
>I have heard these acronymns before, I haven't a clue about how and 
>when they are used.
>
>All I knew up until now was that, using TCP/IP, I could pass data 
>between two end-points on a network (the client and the server). In my 
>case, I have written a set of client libraries on the AS/400 that use 
>sockets to communicate with my Delphi server application on the PC (the 
>address of which is resolved from the currently active 5250 session 
>from where the client application is started by the user). The Delphi 
>program rebuilds the information sent by the AS/400 application and 
>then executes the requests stored in the data (eg. read PC databases, 
>call Word or Excel or control Outlook etc). The results of the request 
>are returned to the AS/400 by replying to the request received.
>
>Now I know that this data can be sent using TCP or UDP (ICMP is another 
>format for another time), and that there are specific differences 
>between these two formats (packet size etc). I send and receive the 
>data in plain text (although converted between EBCDIC and ASCII during 
>the sending
>process) over TCP, communicating to a port that can be configured on 
>both sides before communication begins.
>
>On the site that I developed the toolset, everything was installed and 
>ran on 70 client desktops the first time (I integrated a native 5250 
>application with their browser based document imaging system so that 
>they could popup documents at the press of a key in their 5250 
>session). Phew. However, when I returned to my office and tried to run 
>the same setup (albeit I was accessing the 5250 session and the AS/400 
>now over a VPN), the AS/400 returns a failure (-1) when sending the 
>data. The IP address range
>(17.1.6.151) on the VPN, is different to the normal network address 
>range where everything works (194.130.10.28).
>
>I have narrowed the problem (hopefully) down to 2 possible problems - a 
>firewall protecting even data coming in over the VPN or this routing 
>table stuff on the AS/400. The routing table on the client site has a 
>few entries, mostly pertinent to similar address ranges as the normal 
>address range mentioned above, and a default route which again appears 
>to be a DNS server in the same range (194.130.10.254).
>
>I have tried adding a routing address for 17.1.6.0, but my application 
>still did not work. What I think I have to do now is to create a new 
>TCP/IP interface for this subnet (if that's what it is), and then add 
>the routing entry for this interface. At least that's the hope. I shall try
it tomorrow.
>
>Does this approach sound valid here ? Has anyone on this list written 
>some of their own TCP/IP communication programs and had any similar
problems ?
>
>Thanks,
>Darren
>
>-----Original Message-----
>From: midrange-l-bounces@xxxxxxxxxxxx
>[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Philipp Rusch
>Sent: 31 May 2004 21:23
>To: Midrange Systems Technical Discussion
>Subject: Re: TCP/IP and programming connectivityproblem
>(routingtablequestion)
>
>Are you guys talking about routing protocols ?
>
>There is RIP Version1 and Version 2, both spoken by an AS/400.
>(RIP = Routing information protocol.)
>
>I somedays read about the AS/400 being able to learn from OSPF-packets 
>as well.
>(OSPF = Open Shortest Path First)
>
>There is more around than this: you have IGRP, which is Internet 
>Gateway Routing Protocol, and EIGRP (most Ciscos do it) which is the 
>enhanced version.
>
>What is needed to "learn" a route ?
>
>Any client side of the above mentioned routing protocols will receive 
>information of the surrounding peers or gateways and will try to 
>establish routes on this base. When you enable the "server"-portion of 
>the protocols, you will be able to propagate this information to other
nodes in the net.
>Security-wise it should be mentioned that normally the client side 
>should suffice, when not acting as a router between networks.
>To achieve maximum safety one should not trust (foreign) routing 
>information packets at all and only put in static routing entries on the
AS/400.
>
>HTH, Philipp Rusch
>
>
>--
>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.
>
>
>  
>

--
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.