Once again, please bear with me. I am having some difficulty in following
elements of your description. I will do the best I can to offer some
comments that you might find helpful, but since I remain a bit confused
about some details of your setup, as well as hazy on teh details of a
variant as outdated as LRP 2.9.8, I may be making some mistakes in respoding.
At 07:47 PM 5/31/02 -0400, Nachman Yaakov Ziskind wrote:
>Ray Olszewski wrote (on Tue, May 28, 2002 at 12:15:09PM -0700):
>| You will need to make some allowances in reading this response (and
>| probably any others you get here), since LRP 2.9.8 is pretty much ancient
>| history to most active LEAF users. (In face, I didn't even remember that
>| 2.9.8 included the "ip" command.)
>|
>| Both interfaces are shown as having addresses on the same private-address
>| network. That's odd and it suggests a fundamental error in your physical
>| setup. Perhaps you can tell us what the physical setup is and what networks
>| the internal and external interfaces are *supposed* to be connected to? I
>| see that you specified adjacent addresses by hand in /etc/network.conf, but
>| that doesn't tell us what the underlying physical setup is (or perhaps we
>| need to know *why* you want two interfaces connected to the same LAN and
>| network).
>
>I picked consecutive ip addresses for convenience. This is my setup:
>
>Lan -> LRP -> DSL Router -> DSL Provider & 'the cloud'.
>
>I'm not why the two interfaces cannot be on the same subnet,
Because it messes up the routing table, in the way I already explained. The
kernel picks the first route it finds that matches, and as a result (with
your former setup), it tries to find the gateway (the DSL router) on the
wrong physical connection.
>but I changed it
>to clarify matters:
>
>IF0_IFNAME=eth0
>IF0_IPADDR=10.1.1.202
>IF0_NETMASK=255.255.255.0
>IF0_BROADCAST=10.1.1.255
>IF0_IP_SPOOF=YES
>
>IF1_IFNAME=eth1
>IF1_IPADDR=10.1.2.203
>IF1_NETMASK=255.255.255.0
>IF1_BROADCAST=10.1.2.255
>IF1_IP_SPOOF=YES
>
>NET0_NETADDR=10.1.1.0
>NET0_NETMASK=$IF1_NETMASK
>NET0_GATEWAY_IF=$IF1_IFNAME
>#NET0_GATEWAY_IP=10.1.2.248
>NET0_IPMASQ=YES
>NET0_IPMASQ_IF=$IF0_IFNAME
>
>GW0_IPADDR=10.1.2.248
>GW0_IFNAME=$IF1_NAME
>GW0_METRIC=1
OK. There is one problem here, an old typo in the LRP config files that
never seems to get corrected. This line is wrong:
GW0_IFNAME=$IF1_NAME
It needt to read:
GW0_IFNAME=$IF1_IFNAME
Otherwise, this part looks good. You are using eth1 as the external
interface, eth0 as the internal interface. This is the reverse of the usual
convention on LEAF systems, but there is no reason why it should not work.
>route add 10.1.2.248 eth1 # from the network_direct file
>
>(where 10.1.2.248 is the address of the DSL router).
I'm surprised you need this entry. Possibly it is needed to compensate for
the typo I spotted above.
>shemesh# netstat -rn
>Kernel IP routing table
>Destination Gateway Genmask Flags MSS Window irtt Iface
>10.1.2.248 0.0.0.0 255.255.255.255 UH 0 0 0 eth1
>10.1.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
>10.1.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
>0.0.0.0 10.1.2.248 0.0.0.0 UG 0 0 0 eth1
The routing table now looks good.
>This seems to work a littler better; I can ping into the box and telnet from
>both ends. But I cannot go *through* the box; i.e. I cannot telnet into
>the DSL
>router from the LAN. This is where I am stuck.
Now we need some diagnostics. If you try to ping the DSL router from the
LAN, what result does the workstation you are pinging from report? (Be as
exact as possible; don't just tell us it "can't" ping.) Ideally, use a
Linux workstation for this test if one is available, as I and others here
are more familiar with error codes from Linux ping than from, say, Windows
ping. In any case, tell us what OS the test workstation is running.
Possible sources of this problem are:
1. The test workstation does not know that the LRP router is its route to
the DSL router. Check the workstation's routing table to see if it is
configured properly.
2. The LRP router is not correctly NAT'ing the LAN addresses. Check either
the ipfwadm or the ipchains rulesets to make sure the router is set to NAT
the eth0 traffic. (Which one you check depends on whether you are using
kernel 2.0.x or 2.2.x; as I recall, LRP 2.9.8 comes in both versions.)
3. The DSL router has a problem in its routing table. Since it and the LRP
router's external interface appear to be on the same network, this answer
is improbable. But not impossible.
4. The LRP router's firewall is blocking traffic to the DSL router's
address. Here is where my memory of LRP is too faint to be of real help.
Newer LEAF routers typically include default firewalls that block traffic
to private-range IP addresses (including 10.0.0.0/8) on the external
interface. If your LRP router does the same, then it will block traffic
from the LAN to or through the DSL router. How to check this again depends
on which kernel your LRP router uses.
For some general guidance on how to supply appropriate diagnistics to this
list, please see the "SR FAQ" link listed below.
>| The second interface is not being used because there is no reason local to
>| the router to use it; the routing table has identical entries for the two
>| interfaces, and eth0 comes first. I'm a wee bit surprised that this affects
>| the arp responses as well as higher level ones, though ... unless the
>| pinging machine itself has a fairly unusual routing table.
>
>But the outside world does not ask the kernel which internal interface to use;
>it just supplies it with an IP address. This address was supplied -
>already, at
>boot time - to the dormant card. Are you telling me that Linux 'revokes'
>the IP
>address assignment dynamically? This would be a way cool feature. But if it
>does, why does ifconfig still show the assignment to eth1?
This is where I get confused. What does all of this mean? What address is
"supplied" by "the outside world" at "boot time", and *how* is it supplied?
Not by magic. And you have not specified any way other than magic --
youhave the config file of the router set up to assign addresses to both
interfaces using information in the config file, not information supplied
by some outside entity (like a DHCP server or a PPPoE link).
The only address ever actually assigned to eth1 is the one in your config
file. When you try to connect (ping, telnet, or whatever) *to that address
from a device that is either physically connected to that network or set to
use the DSL router as its gateway to that network, then the incoming packet
reaches that interface. But (under your *old* setup, with both interfaces
on the same network) the LRP router looks at the routing table to figure
out what interface to send the *reply* packet on. Because the routing table
lists both interfaces as connecting to the same network, it uses the first
one it finds, which is the wrong one. Or, as I wrote the last time ...
>| Even if you disconnect the first card from the LAN, the routing table still
>| believes it to be the route to the LAN, so it tries to use it (and fails)
>| to respond to pings.
>|
[old stuff deleted]
--
-----------------------------------------------"Never tell me the
odds!"--------------
Ray Olszewski -- Han Solo
Palo Alto, California, USA [EMAIL PROTECTED]
-------------------------------------------------------------------------------------------
_______________________________________________________________
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
------------------------------------------------------------------------
leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
