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



There's a 'secret' setting for TCPIP that forces the AS/400 to purge its
internal TCP/IP Route Information Table immediately.

My partner in crime at the office, Larry Haynes, describes the problem and
the work-around:

When an IP device is unable to connect to one or more of the AS/400s this
could be the solution. In the past when a location experiences a frame
[relay] outage they may not be able to connect to one or both of the
AS/400's. It has happened to [our Kentucky location] more than once. Also
the same thing happened to one of the Kronos IP clocks.

The problem is with the Internet Control Message Protocol (ICMP) redirect
mechanism. The router sent the message to the AS/400 and the routing table
on the AS/400 was changed to point the device to [the firewall and The
Internet], which is incorrect.

[As I understand the problem, our network default route for any unknown
destination is The Internet (via the firewall).  When the correct connection
to a location drops, the router assumes that the default route is a valid
alternate, and advises the AS/400 to update its Route Information Table.
When the correct connection is once again available, the AS/400 doesn't
clear out the updated route information in a timely fashion.]

[A. GO TCPADM]

[B. select option 7 - Work with TCP/IP network status]

[C. Select option 2 - Display TCP/IP Route Information]

[D. Press F11.  If you see entries with route source of *ICMP that have the
next hop as the address of the firewall and The Internet, you have this
problem.]

Follow these instructions to correct the problem.

1. Go TCPADM

2. Select option 1 - Configure TCP/IP

3. Select option 3 - Change TCP/IP attributes

4. [Note the current value, then change] the field IPRSBTIMO (IP re-assembly
time-out) to 90

[Why change it to 90, you ask?  Why not 47?  Because IBM has cheated--  "90"
is a Special Value; TCP/IP sees 90 and knows that you -really- want it to
clear certain route table information!]

5. [To monitor the progress of the purge:] Go to the TCP/IP Administration
menu and select option - 7 Work with TCP/IP network status.

6. Select option 2 - Display TCP/IP route information

7. Press F11, you should no longer see the entries with a route source of
*ICMP that had the next hop as [the address of the firewall and The
Internet].

8. Repeat steps 2, 3 and 4 BUT THIS TIME CHANGE THE VALUE BACK TO 120
seconds [or whatever value you noted back in step 4].

Note:

IBM stated that there is no PTF to prevent these *ICMP entries because they
are coming from our router. They did inform me that using Operations
Navigator that there is a way to block the *ICMP entries. Redbook SG24-5190
section 10.8.1 explains this technique.


-----Original Message-----
From: PaulMmn [mailto:PaulMmn@ix.netcom.com]
Sent: Thursday, November 29, 2001 11:19 PM
To: PMusselman@BICCGeneral.com
Subject: Fwd: Re: Ping returning wrong address


>Status:  U
>To: midrange-l@midrange.com
>Subject: Re: Ping returning wrong address
>MIME-Version: 1.0
>From: KirkG@PacInfoSys.com
>X-MIMETrack: Serialize by Router on pacstrm/PacInfoSys/US(Release
>5.0.8 |June 18, 2001) at
>   11/28/2001 05:53:01 PM,
>       Serialize complete at 11/28/2001 05:53:01 PM
>Sender: midrange-l-admin@midrange.com
>X-BeenThere: midrange-l@midrange.com
>X-Mailman-Version: 2.0.8
>Precedence: bulk
>Reply-To: midrange-l@midrange.com
>List-Help: <mailto:midrange-l-request@midrange.com?subject=help>
>List-Post: <mailto:midrange-l@midrange.com>
>List-Subscribe: <http://lists.midrange.com/cgi-bin/listinfo/midrange-l>,
>       <mailto:midrange-l-request@midrange.com?subject=subscribe>
>List-Id: Midrange Systems Technical Discussion <midrange-l.midrange.com>
>List-Unsubscribe: <http://lists.midrange.com/cgi-bin/listinfo/midrange-l>,
>       <mailto:midrange-l-request@midrange.com?subject=unsubscribe>
>List-Archive: <http://archive.midrange.com/midrange-l/>
>Date: Wed, 28 Nov 2001 17:52:59 -0800
>
>It's in the AS/400. If I understand correctly.. The Cisco Kid says the DNS
>info says it only valid for 20 minutes?
>
>---------------------------------
>Kirk Goins
>IBM Certified AS/400 Technical Solutions
>Pacific Information Systems - An IBM Premier Business Partner
>503-674-2985           kirkg@pacinfosys.com
>"WE KNOW TECHNOLOGY"
>---------------------------------
>
>
>
>
>
>rob@dekko.com
>Sent by: midrange-l-admin@midrange.com
>11/28/2001 01:16 PM
>Please respond to midrange-l
>
>
>          To:     midrange-l@midrange.com
>          cc:
>          Subject:        Re: Ping returning wrong address
>
>
>
>Where is this cache?  On the 400 or the DNS?  The Cisco kid said there was
>a 20 min cache.  I waited longer than that.



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.