Re: routing setup question
On Tue, 15 Apr 1997, Jens B. Jorgensen wrote:
> > > > lisa.thenet.ch icemark.thenet.ch firefranc
> > > > ppp0 193.135.252.75 193.135.252.47
> > > > eth0 192.168.101.1 192.168.101.2
> > [...]
> > > > The new setup should look like:
> > > > ISP My systems
> > > > lisa.thenet.ch icemark.thenet.ch firefranc.thenet.ch
> > > > <--- ppp0 ---> <--- eth0 --->
> > > > 193.135.252.75 193.135.252.47 193.135.252.179
>
> Ok, I'm not sure why Rick wanted to swap the IP addresses for icemark
> and firefranc, but here's a setup that should work based upon the
> info you provided.
>
> Icemark will use 193.135.252.47 as the IP address for *both* the
> ppp interface and the ethernet interface. That is, icemark's
> /etc/init.d/network should look like this:
>
> #!/bin/sh
> ifconfig lo 127.0.0.1
> route add -net 127.0.0.0
> IPADDR=193.135.252.47
> NETMASK=255.255.255.0
> NETWORK=193.135.252.0
> BROADCAST=193.135.252.255
> #GATEWAY=none
> ifconfig eth0 ${IPADDR} netmask ${NETMASK} broadcast ${BROADCAST}
> route add -net ${NETWORK}
> #route add default gw ${GATEWAY} metric 1
>
> You won't set the default route at boot time since it doesn't exist.
> Instead, make sure that you include the 'defaultroute' option in
> your /etc/ppp/options or on the command line for pppd. Now, on
> firefranc, you'll have the following for you /etc/init.d/network
>
> #!/bin/sh
> ifconfig lo 127.0.0.1
> route add -net 127.0.0.0
> IPADDR=193.135.252.179
> NETMASK=255.255.255.0
> NETWORK=193.135.252.0
> BROADCAST=193.135.252.255
> GATEWAY=193.135.252.47
> ifconfig eth0 ${IPADDR} netmask ${NETMASK} broadcast ${BROADCAST}
> route add -net ${NETWORK}
> route add default gw ${GATEWAY} metric 1
>
> This should do the trick. Yes, this means that if you do an ifconfig -a
> when the ppp link is up on icemark, you'll see that ppp0 and eth0
> *both* have 193.135.252.47 as their IP Address. This is ok, as long as
> the netmasks are right.
but the netmasks are wrong. 255.255.255.0 is for a /24 (i.e. class C)
network. The network and broadcast addresses are wrong too, for the same
reason.
> The reason you saw looping before when you tried a traceroute to
> firefranc from icemark was probably because you still had the eth0's
> IP address set to 192.168.101.1. Thus icemark routed the packet
> for 193.135.252.179 to it's default route, the only one it knew.
> lisa justly sent the packet back to icemark since it is set up to
> route 193.135.179 to icemark. This behavior is as expected from your
> settings. Now you know why IP packets have a Time-To-Live field!
The only problem with this is that neither machine will be able to
communicate directly with other machines on the 193.135.252/24 network -
with a netmask of 255.255.255.0 they will expect the entire 193.135.252
network to be on the local ethernet.
This could be a big problem if, for example, you need to communicate
directly with other customers of your ISP who use the same class C or
even worse if your ISP's news or www or www-proxy machines are on the
same class C.
NOTE: your network configuration would be **much** simpler if your ISP
would give you a small subnet rather than just two random ip addresses.
Ask your ISP to do this for you.
If your ISP can't or won't, then the only way i can think of at the
moment for getting the routing (almost) correct is to set up both
machines so that two small /30 subnets of 193.135.252 are routed via
the ethernet, and everything else is routed via the default gateway
(firefranc's def gw is icemark, icemark's def gw is the ppp interface).
Even this isn't perfect because there will be two subnets which your
machines wont be able to communicate with.
Alternatively, just use private 192.168.1.x addresses for the ethernet
and set up icemark to do IP masquerdading and transparent proxying.
There are very few limitations on what can be done with masquerading
these days, so this is probably the best (least messy!) solution for
you.
craig
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-user-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: