OK Good. I THOUGHT that might be the case but....
First the easy part. Yes, the routing table has redundant information in
it and those are what I refer to as 'Land Mines.' At some point you will
change your network and there will be these rogue routes hanging there
now causing issues.
So the routing table should be:
*DFTROUTE *NONE 5188.8.131.52 *NONE
Or it could be set as:
*DFTROUTE *NONE 5184.108.40.206 5220.127.116.11
*DFTROUTE *NONE 518.104.22.168 522.214.171.124
If you do this do set the routing priority on the two interfaces to
something like 6 or 7, don't use the default of 5. This would allow
The routes are referenced MOST specific to LEAST SPecific. So,
HOST Routes then Network Routes then Default Route.
Now the odd part is why the connection went away and then came back. The
MIMIX connection going away part not so much but the came back part is a
bit odd. That your connection went away is weirder.
The .43 address is on the OTHER IBM i system yes? And yet you lost
connection to that. Is your route to the .43 system pointing to the
local system? (e.g. to .42??)
- Larry "DrFranken" Bolhuis
On 10/22/2013 9:24 PM, Sam_L wrote:
Sorry, obfuscation in the message, courtesy of find and replace. My
bad, should have used xxx.
I'm sorry but I just HAVE to ask, how the heck did you get it to take an
address like 567.17.anything??? That's simply not a valid address!
- Larry "DrFranken" Bolhuis
We have two Ethernet cards with these addresses in our production
Internet Subnet Line Line
Address Mask Description Type
127.0.0.1 255.0.0.0 *LOOPBACK *NONE
5126.96.36.199 255.255.0.0 ETHLINE *ELAN
5188.8.131.52 255.255.0.0 ETHLINE2 *ELAN
5184.108.40.206 255.255.0.0 ETHLINE2 *ELAN
The routes look like this:
Route Subnet Next Preferred
Destination Mask Hop Interface
*DFTROUTE *NONE 5220.127.116.11 518.104.22.168
522.214.171.124 *HOST 5126.96.36.199 5188.8.131.52
5184.108.40.206 *HOST 5220.127.116.11 518.104.22.168
522.214.171.124 *HOST 5126.96.36.199 5188.8.131.52
I'm not sure why this setup or how it got this way. The 567.15
addresses are our offsite backup machine and the 255.42 and 255.43 are
the addresses that Mimix talks on.
We tested a planned Mimix switch. I had a client access session on
5184.108.40.206. Part of the switch disables 5220.127.116.11 (the preferred
interface for 3 of the routes) and when that happened my client access
session disconnected and Mimix processing stalled. I suspect disabling
518.104.22.168 caused both the *DFTROUTE and the 522.214.171.124 destination
to be inoperable. However, somewhere between 30 minutes and an hour
later my client access session reconnected and Mimix took off again.
I have the feeling that the *DFTROUTE should have *NONE as the
interface and the other three entries are unneeded, because the
5126.96.36.199 default gateway on the network knows all these
Second question; Why did everything start working again 30+ minutes
later? I have a feeling there is some retry threshold that was
and is probably configured way too high.
Thirdly, in what order are the routing entries consulted? Is the
*DFTROUTE the last one checked if there is no hit on any other entry?
(Sorry for the long post and if these seem like simplistic questions I
apologize--I'd rather be programming...)
This mailing list archive is Copyright 1997-2013 by MIDRANGE dot 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 here. If you have questions about this, please contact