Comments below.
Mark Post wrote:
On Mon, Aug 6, 2007 at 4:08 PM, in message
<[EMAIL PROTECTED]>, zach pratT
<[EMAIL PROTECTED]> wrote:
I have been receiving some martian source messages in
/var/log/messages as I have been working on our SLES 10 system's
network configuration, and I am attempting to determine what the
solution to these messages.
-snip-
- We're not running z/VM and we do not have an IFL.
You have my sympathies.
- We're running SLES 10 (without SP1, or any other updates) on an LPAR
on our z890 with two shared CP's.
Time to upgrade, then. There's some good stuff in SP1, not to mention the
ever-present security fixes.
- Linux has access to both of our OSA's (shared), and each OSA is
connected to a separate subnet.
Details, please. What are the subnets and network masks?
-snip-
- I am able to access the system from all three interfaces from our
LAN, and I have tested this when either OSA is set as the default
route.
Three interfaces? You only talked about OSAs previously.
-snip-
I am assuming that these messages
are due to the fact that the packet's are being sent out one interface
and replies are arriving on the other interface. I have attempted to
Close, but not quite. What interface the packets leave on isn't the issue.
It's that the system is receiving packets on an interface that it wouldn't
expect them to be arriving on. Packets for the IP address of eth1 arriving on
eth0, etc.
This is asymmetric routing. From a routing perspective, completely
legitimate. You need to figure out why the network routers are sending
packets to this interface for the other. This is probably because of the
routes you are advertising to the adjacent router. You need to either
filter the LAN routes being advertised so that the other LAN does not
get advertised to the wrong router or increase the metric of the one LAN
to the router on the other LAN (preferable for availability to Linux,
but could turn your Linux into a router for other devices on that LAN if
Linux is the only path to that network during a network outage). The
routers can both filter or manipulate the route metrics you are
advertising to eliminate this if the packages you are using can not do
it themselves.
Hardcoding the default route kills availability, the entire reason you
are going through this exercise. You should listen to the default route
advertisements and either increase the metric advertised to you, if you
can, or have the network guys do so with their advertisements.
Further, the OSPF routing protocol is strongly recommended for network
convergence, although it looks like your network uses RIP (HORRIBLY slow
to converge), something that may be hugely difficult to change depending
upon the size of your internal network, but worth doing if you can get
the network guys to see the value. OSPF could also be used just for the
routers that talk to the mainframe and the routers could import the OSPF
routing tables (for just you) into the RIP forwarding tables. I realize
this is beyond your immediate challenge, but worth knowing if your
current environment is just too slow to recover.
solve this with the network guys, but together we have been unable
successfully solved the entire problem.
More details would be needed.
ifconfig -a
route -n
cat /etc/sysconfig/network/routes
I suspect that you've got a router somewhere with a bad routing table in it
(unless the output from those commands shows something more obvious).
Mark Post
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
