Discussion:
adding a ppp default gw while a eth0 default gw exist
(too old to reply)
niv
2011-01-01 16:08:20 UTC
Permalink
hi,
according to http://git.ozlabs.org/?p=ppp.git;a=blob;f=pppd/sys-linux.c
line 1611 ( sifdefaultroute ) :
if ppp finds a default route it wont add its own default route.

Assuming I get a default gateway from my ISP using dhcp, and I want to
add a l2tp connection on top of it, a good way would be to leave the
eth0 default gateway and ADD a default gateway , via the l2tp server
with a higher metric.

1. Must we change the ppp source to allow this?
2. does ppp exposes these variables and allows us to create this
scenario?

Niv
James Carlson
2011-01-01 19:55:34 UTC
Permalink
Post by niv
hi,
according to http://git.ozlabs.org/?p=ppp.git;a=blob;f=pppd/sys-linux.c
if ppp finds a default route it wont add its own default route.
Correct. This is intentional -- if an administrator has set a default
route, then it's assumed that it's really a "default route:" i.e., it's
a route that can be used to reach all possible IP nodes that don't
otherwise have more specific routes.
Post by niv
Assuming I get a default gateway from my ISP using dhcp, and I want to
add a l2tp connection on top of it, a good way would be to leave the
eth0 default gateway and ADD a default gateway , via the l2tp server
with a higher metric.
I disagree on multiple counts.

First of all, metrics are typically used by routing software, not by the
kernel. (Though it's possible your kernel may make some use of them;
most do not.)

Secondly, if you set it as a higher metric, then nothing will go that
way. Everything goes by the lowest metric. How is that helpful?

Finally, you should be specific about what you want. There are two
clear choices that I can see:

1. Use "route get" to determine the proper next hop for the L2TP
server during your connection set-up script. Then delete the
existing default route and add a host route for the L2TP server
pointing to the next hop you got above. Then start PPP and
allow it to install a default route. This gives you a set-up
where you reach all nodes (other than the L2TP server) via the
L2TP tunnel. This would be appropriate for a VPN-like
situation, where you don't really want to access the wider
Internet directly.

2. Don't use "defaultroute" on pppd. Allow it to bring the PPP
connection up using L2TP. When the connection is up, use
either a routing protocol or (if you must) static routes to
configure the network routes that should go via the L2TP link.
All other traffic will hit the default route and go via the
regular Ethernet path. This would be appropriate for a case
where there's some remote site you must reach via L2TP, but
you don't want any other Internet traffic to be forced through
that site.
Post by niv
1. Must we change the ppp source to allow this?
You can change it if you want, but I think it's already doing the right
thing.
Pascal Hambourg
2011-01-02 19:35:47 UTC
Permalink
Hello,
Post by niv
if ppp finds a default route it wont add its own default route.
Assuming I get a default gateway from my ISP using dhcp, and I want to
add a l2tp connection on top of it, a good way would be to leave the
eth0 default gateway and ADD a default gateway , via the l2tp server
with a higher metric.
A good way to achieve what ?
The default route with the higher metric will be ignored unless the one
with the lower metric is removed.
Post by niv
1. Must we change the ppp source to allow this?
FYI, some distributions such as Debian provide a pppd with a patch that
adds an option "replacedefaultroute" which allows pppd to replace an
existing default route (and to restore it when the PPP connection ends).
Post by niv
2. does ppp exposes these variables and allows us to create this
scenario?
pppd exposes the interface name and peer address to the script
/etc/ppp/ip-up which is run when the IPCP negotiation succeeds, and
/etc/ppp/ip-down when the connection ends. In Debian these scripts run
other scripts in /etc/ppp/ip-up.d/ and /etc/ppp/ip-down.d/ but I don't
know if it is the upstream pppd behaviour.
James Carlson
2011-01-08 18:54:23 UTC
Permalink
Post by Pascal Hambourg
Post by niv
1. Must we change the ppp source to allow this?
FYI, some distributions such as Debian provide a pppd with a patch that
adds an option "replacedefaultroute" which allows pppd to replace an
existing default route (and to restore it when the PPP connection ends).
Yes. I've never liked that option. If you know that your existing
default route is bogus, then why on Earth are you installing it in the
first place?

And if it's not bogus, then why do you want PPP to override a good
default route?

I suspect that in about 99 and 44/100ths percent of the cases, the use
of "replacedefaultroute" is merely papering over an existing
configuration defect. And that's poor administrative and software
design practice, in my opinion.
Post by Pascal Hambourg
Post by niv
2. does ppp exposes these variables and allows us to create this
scenario?
pppd exposes the interface name and peer address to the script
/etc/ppp/ip-up which is run when the IPCP negotiation succeeds, and
/etc/ppp/ip-down when the connection ends. In Debian these scripts run
other scripts in /etc/ppp/ip-up.d/ and /etc/ppp/ip-down.d/ but I don't
know if it is the upstream pppd behaviour.
It's not. I'm not sure how I feel about those extensions. They're
architecturally nice in that they decouple independent applications that
need up/down notification. But, on the other hand, what are you doing
here that you can't do (or shouldn't be doing) in an application that
listens to a routing socket or otherwise does something more PPP-agnostic?
Moe Trin
2011-01-09 20:39:08 UTC
Permalink
On Sat, 08 Jan 2011, in the Usenet newsgroup comp.protocols.ppp, in article
Post by James Carlson
I suspect that in about 99 and 44/100ths percent
Ivory Snow? Do they still use that advertising slogan? ;-)
Post by James Carlson
of the cases, the use of "replacedefaultroute" is merely papering
over an existing configuration defect. And that's poor administrative
and software design practice, in my opinion.
It's also a lack of understanding of networking concepts. Thanks to the
mis-use of the term 'Gateway' in a ``popular'' operating system, many
inexperienced people have no idea what a gateway does or the difference
between a 'gateway' and a 'default gateway' and assume there must be a
gateway defined on every interface - including the loopback if they are
aware of it.
Post by James Carlson
Post by Pascal Hambourg
pppd exposes the interface name and peer address to the script
/etc/ppp/ip-up which is run when the IPCP negotiation succeeds, and
/etc/ppp/ip-down when the connection ends. In Debian these scripts run
other scripts in /etc/ppp/ip-up.d/ and /etc/ppp/ip-down.d/ but I don't
know if it is the upstream pppd behavior.
It's not. I'm not sure how I feel about those extensions. They're
architecturally nice in that they decouple independent applications that
need up/down notification.
As Linux (and other *nix clone/look-alike) operating systems often use
a package manager for software maintenance, the idea allows replacement
of the package (which includes the $FOO-up and $FOO-down scripts) without
loosing the local changes/additions. As Pascal mentions, Debian Linux
and derivatives use /etc/ppp/ip-up to run all executable scripts found
in /etc/ppp/ip-up.d/ (etc.). Red Hat Linux and derivatives use ip-up to
run '/etc/ppp/ip-up.local'.
Post by James Carlson
But, on the other hand, what are you doing here that you can't do (or
shouldn't be doing) in an application that listens to a routing socket
or otherwise does something more PPP-agnostic?
Depends on the skill level of the person setting up pppd, or the
``helper'' tools that may be used as a wrapper. When I was dependent
on dialin, ip-up was used to replace /etc/resolv.conf with one listing
the nameservers appropriate to "this" (of four) ISP, set the specific
firewall rules, check a mail and time server, and similar tasks. I
suppose I could have continually looked for the existence of a ppp
route, but that seems extremely wasteful of CPU cycles as I only need
to make changes or start/stop stuff when the link goes up/down.

Old guy
Pascal Hambourg
2011-01-09 23:47:21 UTC
Permalink
Post by James Carlson
Post by Pascal Hambourg
FYI, some distributions such as Debian provide a pppd with a patch that
adds an option "replacedefaultroute" which allows pppd to replace an
existing default route (and to restore it when the PPP connection ends).
Yes. I've never liked that option. If you know that your existing
default route is bogus, then why on Earth are you installing it in the
first place?
And if it's not bogus, then why do you want PPP to override a good
default route?
I'll quote what I replied to Moe in another newsgroup :
The PPP link may become the preferred default route when established.
This is not specific to PPP and may apply to any dynamic link. For
example think of a VPN setup where you want all the traffic to go
through the VPN, and still need a preexisting default route to connect
to the VPN server.
(PPP may be used for VPNs, e.g. PPTP or PPP over SSH)
Post by James Carlson
Post by Pascal Hambourg
pppd exposes the interface name and peer address to the script
/etc/ppp/ip-up which is run when the IPCP negotiation succeeds, and
/etc/ppp/ip-down when the connection ends. In Debian these scripts run
other scripts in /etc/ppp/ip-up.d/ and /etc/ppp/ip-down.d/ but I don't
know if it is the upstream pppd behaviour.
It's not. I'm not sure how I feel about those extensions. They're
architecturally nice in that they decouple independent applications that
need up/down notification. But, on the other hand, what are you doing
here that you can't do (or shouldn't be doing) in an application that
listens to a routing socket or otherwise does something more PPP-agnostic?
As Moe pointed out, it depends on the skill of the user. I am unable to
write a program that listens to a routing socket (I do not even know
what a routing socket is) but I can write a shell script that performs
all the actions I need. And I wish that all network connection types
would provide such facility.
James Carlson
2011-01-12 20:22:45 UTC
Permalink
Post by Pascal Hambourg
Post by James Carlson
Post by Pascal Hambourg
FYI, some distributions such as Debian provide a pppd with a patch that
adds an option "replacedefaultroute" which allows pppd to replace an
existing default route (and to restore it when the PPP connection ends).
Yes. I've never liked that option. If you know that your existing
default route is bogus, then why on Earth are you installing it in the
first place?
And if it's not bogus, then why do you want PPP to override a good
default route?
The PPP link may become the preferred default route when established.
This is not specific to PPP and may apply to any dynamic link. For
example think of a VPN setup where you want all the traffic to go
through the VPN, and still need a preexisting default route to connect
to the VPN server.
(PPP may be used for VPNs, e.g. PPTP or PPP over SSH)
In that case, you're doing something really non-trivial. Not only do
you want to establish PPP as the preferred way in and out of the box,
but (presumably) you want to restore the Ethernet interface to its
normal operation after you tear down PPP. Otherwise, the one-way
behavior of PPP would be toxic.

I suggest writing a wrapper script or even a separate application for
that. I don't think pppd is supposed to be a routing policy daemon. It
just implements PPP negotiation and interface configuration.
Post by Pascal Hambourg
Post by James Carlson
It's not. I'm not sure how I feel about those extensions. They're
architecturally nice in that they decouple independent applications that
need up/down notification. But, on the other hand, what are you doing
here that you can't do (or shouldn't be doing) in an application that
listens to a routing socket or otherwise does something more PPP-agnostic?
As Moe pointed out, it depends on the skill of the user. I am unable to
write a program that listens to a routing socket (I do not even know
what a routing socket is) but I can write a shell script that performs
all the actions I need. And I wish that all network connection types
would provide such facility.
So ... when you plug in an Ethernet cable, and the link light goes on,
you want a script to run, right?

Some OSes will do that. Notably OpenSolaris, where the NWAM project
delivered a daemon that listens on a routing socket and will trigger all
sorts of activity on link status changes.

I understand why the up/down scripts are being used. You needn't
explain that to me. I still think they're architecturally suspicious,
and point to a lack of infrastructure rather than something "special"
about PPP.
Anssi Saari
2011-01-13 10:02:26 UTC
Permalink
Post by James Carlson
Post by Pascal Hambourg
(PPP may be used for VPNs, e.g. PPTP or PPP over SSH)
In that case, you're doing something really non-trivial. Not only do
you want to establish PPP as the preferred way in and out of the box,
but (presumably) you want to restore the Ethernet interface to its
normal operation after you tear down PPP. Otherwise, the one-way
behavior of PPP would be toxic.
I think a PPTP VPN is a non-trivial, everyday thing. Personally I use
one a lot. Another use for the replacedefaultroute is to get online at
home via 3G if my ADSL goes down. Thankfully that has been pretty rare
recently.

I think having replacedefaultroute is a convenient solution, but for
sure routing can be easily handled with scripts too. In fact I have
setup exactly that for an openvpn pipe.
Pascal Hambourg
2011-01-15 10:40:02 UTC
Permalink
Post by James Carlson
Post by Pascal Hambourg
Post by James Carlson
And if it's not bogus, then why do you want PPP to override a good
default route?
The PPP link may become the preferred default route when established.
This is not specific to PPP and may apply to any dynamic link. For
example think of a VPN setup where you want all the traffic to go
through the VPN, and still need a preexisting default route to connect
to the VPN server.
(PPP may be used for VPNs, e.g. PPTP or PPP over SSH)
In that case, you're doing something really non-trivial. Not only do
you want to establish PPP as the preferred way in and out of the box,
but (presumably) you want to restore the Ethernet interface to its
normal operation after you tear down PPP. Otherwise, the one-way
behavior of PPP would be toxic.
I don't consider it is non-trivial. AFAIK it is quite common in
temporary VPN setups. The pptp-linux PPTP client adds a host route to
the server address when it is not directly reachable ; this shows that
it is expected that the existing default route may be altered.
Post by James Carlson
I suggest writing a wrapper script or even a separate application for
that. I don't think pppd is supposed to be a routing policy daemon. It
just implements PPP negotiation and interface configuration.
IMO, programs such as pppd and DHCP clients should only implement the
protocol negotiation, and pass the negotiated parameters to a
customizable (is that english ? my dictionary does not have it) script
that performs the actual network configuration.
Post by James Carlson
Post by Pascal Hambourg
As Moe pointed out, it depends on the skill of the user. I am unable to
write a program that listens to a routing socket (I do not even know
what a routing socket is) but I can write a shell script that performs
all the actions I need. And I wish that all network connection types
would provide such facility.
So ... when you plug in an Ethernet cable, and the link light goes on,
you want a script to run, right?
Yes, I'd appreciate that.
Post by James Carlson
I understand why the up/down scripts are being used. You needn't
explain that to me. I still think they're architecturally suspicious,
and point to a lack of infrastructure rather than something "special"
about PPP.
Sure, there is nothing specific to PPP.

Loading...