I have chain of three machines. 192.168.42.2 is connected by an ethernet link to the middle machine 10.0.0.1 which is connected in turn to a dialup internet connection through ppp0.
From machine 10.0.0.1 I can ping machine 192.168.42.2 and the IP server 195.92.65.96.
From machine 192.168.42.2 I can ping machine 1.0.0.1, but not the server 195.92.65.96.
Running /sbin/route on machine 10.0.0.1 yields the following: Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.42.2 0.0.0.0 255.255.255.255 UH 0 0 0 eth1 195.92.65.96 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0 0.0.0.0 195.92.65.96 0.0.0.0 UG 0 0 0 ppp0 The first line is set by an entry in /etc/sysconfig/network/route. The value for /proc/sys/net/ipv4/ip_forward is 1 There is no firewall and the output from iptables -L is: Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination What must I do to enable me to ping the IP server from machine 192.168.42.2 ? Basil Fowler
On Monday 02 June 2003 13.51, Basil Fowler wrote:
I have chain of three machines. 192.168.42.2 is connected by an ethernet link to the middle machine 10.0.0.1 which is connected in turn to a dialup internet connection through ppp0.
From machine 10.0.0.1 I can ping machine 192.168.42.2 and the IP server 195.92.65.96.
From machine 192.168.42.2 I can ping machine 1.0.0.1, but not the server 195.92.65.96.
since 192.168.x.x are private IP addresses, I assume the server doesn't know how to answer. You probably need to set up masquerading. Either with a command like iptables -t nat -I POSTROUTING -s 192.168.42.2 -j MASQUERADE or, perhaps preferable, by configuring SuSEfirewall2 for routing and masquerading, check Togan's unofficial FAQ for the details on that If you have full control of all three machines, and you don't want to set up masquerading for whatever reason, then you need to make sure that the routing table on the server has a correct path back to 192.168.42.2
Thank you for your advice - but the system still doesn't work. All I get is when I ping the end of the chain from machine 192.168.42.42 is Destination host Unreachable On Monday 02 Jun 2003 12:01, Anders Johansson wrote:
On Monday 02 June 2003 13.51, Basil Fowler wrote:
I have chain of three machines. 192.168.42.2 is connected by an ethernet link to the middle machine 10.0.0.1 which is connected in turn to a dialup internet connection through ppp0.
From machine 10.0.0.1 I can ping machine 192.168.42.2 and the IP server 195.92.65.96.
From machine 192.168.42.2 I can ping machine 1.0.0.1, but not the server 195.92.65.96.
since 192.168.x.x are private IP addresses, I assume the server doesn't know how to answer. You probably need to set up masquerading. Either with a command like
iptables -t nat -I POSTROUTING -s 192.168.42.2 -j MASQUERADE
This I have done on machine 10.0.0.1. The command iptables -t nat -L gives the following: Chain PREROUTING (policy ACCEPT) target prot opt source destination Chain POSTROUTING (policy ACCEPT) target prot opt source destination MASQUERADE all -- 192.168.42.2 anywhere
or, perhaps preferable, by configuring SuSEfirewall2 for routing and masquerading, check Togan's unofficial FAQ for the details on that
I have read the FAQ, the instructions on SuSEfirewall2 and tried that, but no luck. That is why I have reduced everything to the simplest possible. Unless I can get a basic setup to work, what chance have in a more complex situation
On Monday 02 June 2003 19.07, Basil Fowler wrote:
Thank you for your advice - but the system still doesn't work. All I get is when I ping the end of the chain from machine 192.168.42.42 is
I'm going to assume you meant 192.168.42.2. If I'm wrong in that assummption, you need to explain more
Destination host Unreachable
What is the output of "route -n" on 192.168.42.2? Does it have 10.0.0.1 as the default gateway? And while we're on the subject, it's usually a good idea, if only for sanity, to keep machines that are physically connected on the same subnet. Mixing 10.* addresses with 192.168.* addresses can be made to work, but I can't see a good reason for it.
On Monday 02 June 2003 19.07, Basil Fowler wrote:
Thank you for your advice - but the system still doesn't work. All I get is when I ping the end of the chain from machine 192.168.42.42 is
I'm going to assume you meant 192.168.42.2. If I'm wrong in that assummption, you need to explain more
Destination host Unreachable
What is the output of "route -n" on 192.168.42.2? Does it have 10.0.0.1 as
The end machine is 192.168.42.2 While I agree that in a working environment the machines should be on the same subnet, for sanity's sake during this investigation, I have given each of my two machines a completely different number to avoid confusion for myself and others :) Machine 192.168.42.2 has a routing table (given by netstat -rn) Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.42.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 192.168.42.2 0.0.0.0 UG 0 0 0 eth0 It is running RedHat 7.0 with a late model 2.2 kernel. The corresponding output from machine 10.0.0.1 has vales of 40 for the MSS column. Is this significant? Another discovery that might be significant. I was studying the man page for netstat, when I noticed the option -M for listing masqueraded connections. Seeing that I had input a MASQUERADE line in iptables on machine 10.0.0.1, I was surprised to read the following output: netstat: no support for `ip_masquerade' on this system. Is this relevant? Thanks in advance for everyone's help. Basil Fowler On Monday 02 Jun 2003 17:14, Anders Johansson wrote: the
default gateway?
And while we're on the subject, it's usually a good idea, if only for sanity, to keep machines that are physically connected on the same subnet. Mixing 10.* addresses with 192.168.* addresses can be made to work, but I can't see a good reason for it.
-- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
On Monday 02 June 2003 22.47, Basil Fowler wrote:
The end machine is 192.168.42.2
While I agree that in a working environment the machines should be on the same subnet, for sanity's sake during this investigation, I have given each of my two machines a completely different number to avoid confusion for myself and others :)
Machine 192.168.42.2 has a routing table (given by netstat -rn)
Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.42.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 192.168.42.2 0.0.0.0 UG 0 0 0 eth0
Here's your problem, your default route is localhost. That can never work. You need to set the default route to the 10.0.0.1 machine, however that's done in redhat manually from the command line it's route del -net 0.0.0.0 route add default gw 10.0.0.1 dev eth0 I can't say how it's configured in a red hat system
--- Anders Johansson
On Monday 02 June 2003 22.47, Basil Fowler wrote:
The end machine is 192.168.42.2
While I agree that in a working environment the machines should be on the same subnet, for sanity's sake during this investigation, I have given each of my two machines a completely different number to avoid confusion for myself and others :)
Machine 192.168.42.2 has a routing table (given by netstat -rn)
Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.42.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 192.168.42.2 0.0.0.0 UG 0 0 0 eth0
Here's your problem, your default route is localhost. That can never work. You
There is a situation where default gateway set to localhost may work - there has to be some other host set up for proxy arp. One of the disadvantages with such setup is your host would arp for every single packet to be send out of the local subnet.
need to set the default route to the 10.0.0.1 machine, however that's done in redhat
Doesn't default gateway need to be on the same subnet? Martin
manually from the command line it's
route del -net 0.0.0.0 route add default gw 10.0.0.1 dev eth0
I can't say how it's configured in a red hat system
-- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
__________________________________ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com
On Tuesday 03 June 2003 00.56, Martin wrote:
Doesn't default gateway need to be on the same subnet?
Not necessarily, although that is the sane way to do it :) With "dev" set in the routing rule, it should work anyway, since the packet should be thrown out on the local LAN and picked up by the other machine with target IP set to 10.0.0.1 on the packets. It should work.
--- Anders Johansson
On Tuesday 03 June 2003 00.56, Martin wrote:
Doesn't default gateway need to be on the same subnet?
Not necessarily, although that is the sane way to do it :)
Well, I get this error when trying to do so and that's what I remembered from the past. My IP is 171.x.x.x. linux:/ # route add default gw 192.168.0.1 SIOCADDRT: Network is unreachable Martin
With "dev" set in the routing rule, it should work anyway, since the packet should be thrown out on the local LAN and picked up by the other machine with target IP set to 10.0.0.1 on the packets. It should work.
-- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
__________________________________ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com
oops, yes, my bad. Sorry I didn't try it first. An extra command is needed to make this work route del -net 0.0.0.0 route add -host 10.0.0.1 dev eth0 route add default gw 10.0.0.1 dev eth0
I can't say how it's configured in a red hat system
Which means to say that I don't know where to put this to make it take effect at bootup on a red hat machine
I am pleased to announce that thanks to everyone's help, I have resolved my problem. I doubt if I would ever have solved it without your help. As routing seems to a be a hardy perennial on this list, I would like to summarise the errors and solutions for the benefit of others. On a router machine ip forwarding must be enabled: ie 'cat /proc/sys/net/ipv4/ip_forward' should give '1' and masquerading must be enabled. To check, run 'iptables -t nat -L as root and an entry like Chain POSTROUTING (policy ACCEPT) target prot opt source destination MASQUERADE all -- anywhere anywhere must be present. On the end machine, there must be TWO defaults and gateways. My previous post the routing table for machine 192.168.42.2 was a little distorted, with the lines being wrapped. The correct version is below ( 'metric' and 'ref' columns have been omitted to avoid line wrapping) 192.168.42.0 0.0.0.0 255.255.255.0 U eth0 127.0.0.0 0.0.0.0 255.0.0.0 U lo 0.0.0.0 192.168.42.2 0.0.0.0 UG eth0 When the line: 0.0.0.0 10.0.0.1 0.0.0.0 UG eth0 was added either manually or with RedHat's GUI netcfg, everything worked perfectly. My error was to believe that there can only be one default route and one gateway. Basil Fowler On Monday 02 Jun 2003 21:03, Anders Johansson wrote:
On Monday 02 June 2003 22.47, Basil Fowler wrote:
The end machine is 192.168.42.2
While I agree that in a working environment the machines should be on the same subnet, for sanity's sake during this investigation, I have given each of my two machines a completely different number to avoid confusion for myself and others :)
Machine 192.168.42.2 has a routing table (given by netstat -rn)
Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.42.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 192.168.42.2 0.0.0.0 UG 0 0 0 eth0
Here's your problem, your default route is localhost. That can never work. You need to set the default route to the 10.0.0.1 machine, however that's done in redhat
manually from the command line it's
route del -net 0.0.0.0 route add default gw 10.0.0.1 dev eth0
I can't say how it's configured in a red hat system
-- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
On Tuesday 03 June 2003 17.52, Basil Fowler wrote:
My error was to believe that there can only be one default route and one gateway.
That's not an error, that's exactly right. There can be only one default route (also known as a default gateway). That is inherent in the word "default". Considering how routing works, it doesn't make any sense to have two
Tuesday, June 3 at 3:52pm, Basil Fowler wrote:
On the end machine, there must be TWO defaults and gateways. My previous This is not correct, as Anders already pointed out.
post the routing table for machine 192.168.42.2 was a little distorted, with the lines being wrapped. The correct version is below ( 'metric' and 'ref' columns have been omitted to avoid line wrapping)
192.168.42.0 0.0.0.0 255.255.255.0 U eth0 127.0.0.0 0.0.0.0 255.0.0.0 U lo 0.0.0.0 192.168.42.2 0.0.0.0 UG eth0
You may have something that "works" but it's still not correct. I'm responding because I don't want others on the list to believe everything needs to be the way you worked it out. You should not have the line 0.0.0.0 192.168.42.2 0.0.0.0 UG eth0 in your route table for the end host. This is the default route entry, and the second column is the gateway host address, which must not be the address of the end system. It must be the address of a gateway host, in your case 10.0.0.1. Linux WILL allow you to configure multiple default routes, but this generally makes sense only if you have multiple interfaces, or you are running a routing protocol. On your end host, which appears from your descriptions to have only a single interface, neither having multiple default routes nor running a routing protocol is necessary. Regards, Jim
Linux WILL allow you to configure multiple default routes, but this generally makes sense only if you have multiple interfaces, or you are running a routing protocol. On your end host, which appears from your
I don't think this is true either. It makes sense to have multiple default gateways even with one interface as you may want to do load balancing via 2 or more next hops or for redundancy purpose and has nothing to do with routing protocol as static default route is mostly being used for end nodes not running any routing protocols. The other thing is that doing routing the way the default gateway is on the different IP subnet then host even being on the same physical 'cable' impose significant performance degradation as for each packet there has to be done recursive route lookup plus arp-ing, so even Anders showed it's possible to make it work it's not the best practice. Martin
descriptions to have only a single interface, neither having multiple default routes nor running a routing protocol is necessary.
Regards, Jim
-- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
__________________________________ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com
On Tuesday 03 June 2003 20.56, Martin wrote:
The other thing is that doing routing the way the default gateway is on the different IP subnet then host even being on the same physical 'cable' impose significant performance degradation as for each packet there has to be done recursive route lookup
Standard scenario: packet to 1.2.3.4 routing table 192.168.0.0/24 eth0 0.0.0.0 192.168.0.1 Match rule 1? No Match rule 2? Yes, so send packet to 192.168.0.1 New packet, containing the first, but embedded in a packet targetted for 192.168.0.1 Match rule 1? Yes, so arp for 192.168.0.1 and ship it off on eth0. Weird scenario: packet to 1.2.3.4 routing table 192.168.0.0/24 eth0 10.0.0.1/32 eth0 0.0.0.0 10.0.0.1 Match rule 1? No Match rule 2? No Match rule 3? Yes, so send packet to 10.0.0.1 Match rule 1? No Match rule 2? Yes, so arp for 10.0.0.1 and ship it off on eth0
plus arp-ing,
You always get arping, and I don't see why the arp cache should cease to function just because it's on a different subnet. Remember, the arp protocol doesn't know about subnets. It should cache both. As far as I can see, you may get an extra rule lookup from it, but it shouldn't affect performance in any directly noticable way
so even Anders showed it's possible to make it work it's not the best practice.
Of course it's not best practice. Neither is having localhost as default gateway, or running Red Hat. There wasn't much in that mail that had "best practice" :)
Tuesday 3 June 2003 at 11:56am, Martin wrote:
Linux WILL allow you to configure multiple default routes, but this generally makes sense only if you have multiple interfaces, or you are running a routing protocol. On your end host, which appears from your
I don't think this is true either. It makes sense to have multiple default gateways even with one interface as you may want to do load balancing via 2 or more next hops or for redundancy purpose and has nothing to do with routing protocol as static default route is mostly being used for end nodes not running any routing protocols. I disagree. An end host with a single interface, as in this situation, has no business trying to make load-balancing decisions that would be best made by the router owning the multiple interfaces with the information about the state of those interfaces as well as the knowledge about traffic on them from other end hosts. Moreover, router redundancy is handled by routers, not hosts, as it is very undesirable that hosts actually have to make decisions about what router to attempt to reach. VRRP, for example, makes it simple to hosts not to need to worry about what router to contact.
The other thing is that doing routing the way the default gateway is on the different IP subnet then host even being on the same physical 'cable' impose significant performance degradation as for each packet there has to be done recursive route lookup plus arp-ing, so even Anders showed it's possible to make it work it's not the best practice.
I don't understand what recursion you're talking about. There is a single route table in the end host that is searched using longest prefix match until (in this case) the default route entry is found and the packet sent to the next hop gateway. ARP-ing should not be a factor whether the gateway host is on the same subnet or not. ARP is done once for each IP address on the wire, and the MAC address received cached in the ARP table until it expires. I've not tested the performance of this type of configuration, but I would be surprised if it were different at all, let alone significantly different. I do agree that this type of configuration is not the best practice. Regards, Jim
--- Jim Cunning
Tuesday 3 June 2003 at 11:56am, Martin wrote:
Linux WILL allow you to configure multiple
default
routes, but this generally makes sense only if you have multiple interfaces, or you are running a routing protocol. On your end host, which appears from your
I don't think this is true either. It makes sense to have multiple default gateways even with one interface as you may want to do load balancing via 2 or more next hops or for redundancy purpose and has nothing to do with routing protocol as static default route is mostly being used for end nodes not running any routing protocols. I disagree. An end host with a single interface, as in this situation, has no business trying to make load-balancing decisions that would be best made by the router owning the multiple interfaces with the information about the state of those interfaces as well as the knowledge about traffic on them from other end hosts. Moreover, router redundancy is handled by routers, not hosts, as it is very undesirable that hosts actually have to make decisions about what router to attempt to reach. VRRP, for example, makes it simple to hosts not to need to worry about what router to contact.
Agreed, but VRRP/HSRP was not subject here ... there are still some routers which don't support that, subject was whether it makes sense :) and to me it does if you don't have any other options. Not that I would ever do that but I've seen folks doing it this way for redundancy or just for heck of it they could.
The other thing is that doing routing the way the default gateway is on the different IP subnet then host even being on the same physical 'cable' impose significant performance degradation as for each packet there has to be done recursive route lookup plus arp-ing, so even Anders showed it's possible to make it work it's not the best practice.
I don't understand what recursion you're talking about. There is a single
RT is not that simple to me, say you have RT below Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 99.99.99.99 * 255.255.255.255 UH 0 0 0 eth1 10.6.141.0 * 255.255.255.0 U 0 0 0 eth1 loopback * 255.0.0.0 U 0 0 0 lo default 99.99.99.99 0.0.0.0 UG 0 0 0 eth1 and there is packet with DIP 100.100.100.100 to be send, so you try to find the match from top to the bottom where you get last default route match pointing to 99.99.99.99 but then you have to search through same RT one more time to find out how to get to 99.99.99.99 as it's not on your directly connected subnet. In such case the performance degradation won't be most likely so impacting for small data transfer but for big data transfer you'd see the difference.
route table in the end host that is searched using longest prefix match until (in this case) the default route entry is found and the packet sent to the next hop gateway.
ARP-ing should not be a factor whether the gateway host is on the same subnet or not. ARP is done once for each IP address on the wire, and the MAC address received cached in the ARP table until it expires. I've not tested the performance of this type of configuration, but I would be surprised if it were different at all, let alone significantly different.
Ok, I must take this back, as I've tried both and Linux builds the arp cache and re-arps every ~60 seconds regardless so most likely 60 seconds is arp aging time. If that's the case is it configurable? Martin
I do agree that this type of configuration is not the best practice.
Regards, Jim
-- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
__________________________________ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com
Tuesday, 3 June 2003 at 9:05pm, Martin wrote: [snip]
I disagree. An end host with a single interface, as in this situation, has no business trying to make load-balancing decisions that would be best made by the router owning the multiple interfaces with the information about the state of those interfaces as well as the knowledge about traffic on them from other end hosts. Moreover, router redundancy is handled by routers, not hosts, as it is very undesirable that hosts actually have to make decisions about what router to attempt to reach. VRRP, for example, makes it simple to hosts not to need to worry about what router to contact.
Agreed, but VRRP/HSRP was not subject here ... there are still some routers which don't support that, subject was whether it makes sense :) and to me it does if you don't have any other options. Not that I would ever do that but I've seen folks doing it this way for redundancy or just for heck of it they could.
This is getting intriguing.... Assuming it makes sense, what I'd like to understand then, on a system with a single ethernet interface and a route table with two default routes, how is the kernel going to know which of the two gateways to use? Suppose one of the gateway hosts has its far side interface down for some reason--how will the end host learn that gateway router isn't really usable? I suppose that the router will return an ICMP "Host not reachable" or "Network not reachable", but I don't see how that will help. You also mentioned load-balancing earlier. I'm aware of load balancing a web site with multiple servers using DNS round robin or with NAT, and there are others, such as supersparrow, which uses BGP, IIRC. But how does one do load balancing from a single host with a single network interface and using only a static route table? I'm not trying to be stubborn about this--I truly would like to know, and if you've seen people do it, please describe it. Thanks. Jim
--- Jim Cunning
I disagree. An end host with a single interface, as in this situation, has no business trying to make load-balancing decisions that would be best made by the router owning the multiple interfaces with the information about the state of those interfaces as well as
knowledge about traffic on them from other end hosts. Moreover, router redundancy is handled by routers, not hosts, as it is very undesirable
hosts actually have to make decisions about what router to attempt to reach. VRRP, for example, makes it simple to hosts not to need to worry about what router to contact.
Agreed, but VRRP/HSRP was not subject here ...
are still some routers which don't support that, subject was whether it makes sense :) and to me it does if you don't have any other options. Not that I would ever do that but I've seen folks doing it
Tuesday, 3 June 2003 at 9:05pm, Martin wrote: [snip] the that there this
way for redundancy or just for heck of it they could.
This is getting intriguing.... Assuming it makes sense, what I'd like to understand then, on a system with a single ethernet interface and a route table with two default routes, how is the kernel going to know which of the two gateways to use? Suppose one of the gateway hosts has its far side interface down for some reason--how will the end host learn that gateway router isn't really usable?
I don't know about the kernel but I guess this should be up to routing daemon to make the inteligent decision which gateway/NIC to use. The only difference having 2 NICs and 2 default gateways pointing to each of them versus 1 NIC and 2 default gateways is NIC level redundancy but same routing daemon functionality must be there in both cases. This type of setup doesn't provide the best redundancy for the reason you've mentioned, you'd need vrrp/hsrp 'tracking' functionality or you have to run some routing protocol between the to gateways.
I suppose that the router will return an ICMP "Host not reachable" or "Network not reachable", but I don't see how that will help.
You also mentioned load-balancing earlier. I'm aware of load balancing a web site with multiple servers using DNS round robin or with NAT, and there are others, such as supersparrow, which uses BGP, IIRC. But how does one do load balancing from a single host with a single network interface and using only a static route table?
the genuine purpose of having multiple routes to the same destination prefix is redundancy and/or load balancing. Of course it's a matter of routing daemon implementation, I assume not all of them (Linux ones) can do per packet or per flow/session load balancing with static or dynamic routing. I believe, zebra should be able to do so. Otherwise, why would be this option available if it doesn't make sense at all?
I'm not trying to be stubborn about this--I truly would like to know, and if you've seen people do it, please describe it.
Imagine host with one NIC connected to switch where you also have two gateways with same RT and slow serial link. You choose it's up to your host routing daemon functionality/config to use one or both gateways simultaneously. This should work flawless with possible caveats but folks sometime do so because they want to have more control and didn't like the idea they have to relay only on network to do forwarding decisions. In this particular case the host traffic would always go through just one link if vrrp/hsrp or one gateway is used/set up. Optimal links utilization can be achieved with vrrp/hsrp as well but not from one host perspective. Martin
Thanks.
Jim
-- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
__________________________________ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com
Now that I have got the system to work, I have performed certain experiments. I used route -del to remove the route 0.0.0.0 192.168.42.2 etc, leaving the 'correct' default in the routing table. This worked perfectly. I tried to set a system using netcfg and netconfig to avoid the duplicate. I failed. It seems that the requirements are not covered properly by the RedHat scripts. It seemed that the system needed to know firstly that all packets had to be directed to the interface eth0 #192.168.42.2, and then, having a route out of the machine, the packets could be dispatched to 10.0.0.1. I also tried to change the IP of the end machine to one in the 10.0.0.0 range, and the results were catastrophic. I note the the use of RedHat is considered not best practice, but for me it has one overwhelming advantage. I have found that on old hardware I can always load RH 7, and SuSE 8.0 invariably fails to boot. Regards Basil Fowler On Tuesday 03 Jun 2003 17:19, Jim Cunning wrote:
Tuesday, June 3 at 3:52pm, Basil Fowler wrote:
On the end machine, there must be TWO defaults and gateways. My previous This is not correct, as Anders already pointed out.
post the routing table for machine 192.168.42.2 was a little distorted, with the lines being wrapped. The correct version is below ( 'metric' and 'ref' columns have been omitted to avoid line wrapping)
192.168.42.0 0.0.0.0 255.255.255.0 U eth0 127.0.0.0 0.0.0.0 255.0.0.0 U lo 0.0.0.0 192.168.42.2 0.0.0.0 UG eth0
You may have something that "works" but it's still not correct. I'm responding because I don't want others on the list to believe everything needs to be the way you worked it out.
You should not have the line
0.0.0.0 192.168.42.2 0.0.0.0 UG eth0
in your route table for the end host. This is the default route entry, and the second column is the gateway host address, which must not be the address of the end system. It must be the address of a gateway host, in your case 10.0.0.1.
Linux WILL allow you to configure multiple default routes, but this generally makes sense only if you have multiple interfaces, or you are running a routing protocol. On your end host, which appears from your descriptions to have only a single interface, neither having multiple default routes nor running a routing protocol is necessary.
Regards, Jim
-- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
-----Original Message-----
From: Basil Fowler
Now that I have got the system to work, I have performed certain experiments.
I used route -del to remove the route 0.0.0.0 192.168.42.2 etc, leaving the 'correct' default in the routing table. This worked perfectly.
I tried to set a system using netcfg and netconfig to avoid the duplicate. I failed. It seems that the requirements are not covered properly by the RedHat scripts. <snip>
Perhaps you need to go to the RedHat lists for help with their scripts.
On Wednesday 04 June 2003 01.41, Basil Fowler wrote:
I also tried to change the IP of the end machine to one in the 10.0.0.0 range, and the results were catastrophic.
Catastrophes are usually what teaches you the most. Or rather, understanding why it fails, and setting things straight. For example: you said catastrophic. In what sense? Assuming you changed the ip to 10.0.0.2 with a netmask of 255.255.255.0 and a routing table that looks something like 10.0.0.0/24 eth0 0.0.0.0/0 10.0.0.1 Could you still ping the middle machine? I'll bet you could. So I'm guessing that you forgot about the iptables rule you set up on the middle machine to allow routing, and that that rule had the source address 192.168.42.2 hard coded. Just a guess, mind you.
I did the experimentation late at night. I have decided on my layout - it works. The routing table for the middle machine is now Destination Gateway Genmask Flags Iface 10.0.0.0 0.0.0.0 255.255.255.0 U eth0 10.0.0.0 0.0.0.0 255.255.255.0 U eth1 192.168.42.0 10.0.0.1 255.255.255.0 UG eth1 0.0.0.0 10.0.0.138 0.0.0.0 UG eth0 This makes perfect sense to me: anything destined for the 192.168.42.0 subnet is dispatched to eth1, and anything else to 10.0.0.138 via eth0. I will leave the settings with on the end machine as described previously. My interpretation of the situation on that machine (which I requote below) seems perfectly plausible, but the details I leave to the real experts. The more I delve into the subject, the more I admire the pure intellectual force that got the protocols to the state where they work.
It seemed that the system needed to know firstly that all packets had to be directed to the interface eth0 #192.168.42.2, and then, having a route out of the machine, the packets could be dispatched to 10.0.0.1.
It should be noted that the machines are directly connected through a crossover cable (no hub) so the question of load sharing does not arise I believe that my problems with a 10.0.0.0 subnet was the presence of zeros. The choice of 10.0.0.0 was determined by my ASDL router, which used DHCP to impose an IP number of 10.0.0.1. I have now changed the settings in the router not to use DHCP, but a static number. To avoid unnecessary trouble, I chose 10.0.0.1 for my static IP. To use a less troublesome number, I have to change the routing tables for the router, and there is always a risk that once I alter the tables, I cannot get back in. In any case, I am not going to pretend after this that I am a routing expert! Quote: "In the land of the blind, the one-eyed man is king." So thanks to all for the help. I have something that works and seems to hold water intellectually, so why fix it? Basil Fowler On Tuesday 03 Jun 2003 23:53, Anders Johansson wrote:
On Wednesday 04 June 2003 01.41, Basil Fowler wrote: I also tried to change the IP of the end machine to one in the 10.0.0.0
range, and the result>s were catastrophic.
Catastrophes are usually what teaches you the most. Or rather, understanding why it fails, and setting things straight.
For example: you said catastrophic. In what sense? Assuming you changed the ip to 10.0.0.2 with a netmask of 255.255.255.0 and a routing table that looks something like
10.0.0.0/24 eth0 0.0.0.0/0 10.0.0.1
Could you still ping the middle machine? I'll bet you could.
So I'm guessing that you forgot about the iptables rule you set up on the middle machine to allow routing, and that that rule had the source address 192.168.42.2 hard coded. Just a guess, mind you.
-- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
Monday, June 2, at 8:47pm, Basil Fowler wrote:
The end machine is 192.168.42.2
While I agree that in a working environment the machines should be on the same subnet, for sanity's sake during this investigation, I have given each of my two machines a completely different number to avoid confusion for myself and others :)
Machine 192.168.42.2 has a routing table (given by netstat -rn)
Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.42.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 192.168.42.2 0.0.0.0 UG 0 0 0 eth0
I haven't kept the earlier parts of this thread, but it looks to me like this is (part, at least) of your problem: Machine 192.168.42.2 has a routing table with a default gateway of 192.168.42.2 -- itself!! Of course, it can't reach any address not on its subnet. The gateway address should be something like 192.168.42.xx, where xx is the address of your dual-homed machine, i.e., the one on the 10.0.0.0 network as well. Jim Cunning
What is your default gateway setup? Check out netstat
-rn.
Martin
--- Basil Fowler
Thank you for your advice - but the system still doesn't work. All I get is when I ping the end of the chain from machine 192.168.42.42 is
Destination host Unreachable
On Monday 02 Jun 2003 12:01, Anders Johansson wrote:
On Monday 02 June 2003 13.51, Basil Fowler wrote:
I have chain of three machines. 192.168.42.2 is connected by an ethernet link to the middle machine 10.0.0.1 which is connected in turn to a dialup internet connection through ppp0.
From machine 10.0.0.1 I can ping machine 192.168.42.2 and the IP server 195.92.65.96.
From machine 192.168.42.2 I can ping machine 1.0.0.1, but not the server 195.92.65.96.
since 192.168.x.x are private IP addresses, I assume the server doesn't know how to answer. You probably need to set up masquerading. Either with a command like
iptables -t nat -I POSTROUTING -s 192.168.42.2 -j MASQUERADE
This I have done on machine 10.0.0.1. The command iptables -t nat -L gives the following:
Chain PREROUTING (policy ACCEPT) target prot opt source destination
Chain POSTROUTING (policy ACCEPT) target prot opt source destination MASQUERADE all -- 192.168.42.2 anywhere
or, perhaps preferable, by configuring
masquerading, check Togan's unofficial FAQ for the
SuSEfirewall2 for routing and details on that
I have read the FAQ, the instructions on SuSEfirewall2 and tried that, but no luck. That is why I have reduced everything to the simplest possible. Unless I can get a basic setup to work, what chance have in a more complex situation
-- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
__________________________________ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com
participants (5)
-
Anders Johansson -
Basil Fowler -
Jim Cunning -
Ken Schneider -
Martin