Subject: Re: multiple ppp links
To: Christian Kuhtz <firstname.lastname@example.org>
From: Paul Goyette <email@example.com>
Date: 01/24/1997 06:10:01
On Thu, 23 Jan 1997, Christian Kuhtz wrote:
> What you are talking about requires source routing, and is impossible per se.
Well, in _my_ business (Internetworking Consulting), "source routing"
means that the source (originator) of the packets specifies the route that
the packets should take on the way to the destination. And although I'm
not aware of any implementations that actually _use_ it, there is a source
routing option field in the IP packet header (can be strict or loose
But, what is really being asked for here is _policy-based_ routing, where
some policy dictates who gets to use which network resources. This is
definitely not implemented in NetBSD, and is only available (AFAIK) in
high end routing products (like Cisco...), and only in recent versions.
> However, another option would be to use a proxy server arrangement on the
> other end of the second ppp link. Point your internal hosts at that proxy
> server, and traffic is routed to the proxy server address and then from there
> on to the destination, depending on what the routes at the end of the 2nd link
> look like.
> Traffic originating from your ppp hub (the one with the two ppp links) would
> be routed to whatever the routing table says for a particular destination.
Which isn't what was being asked for...
> Nonetheless, this requires that the service you are using can a) be proxied
> and b) proxy software is available on the internal network, which may or may
> not rule this out as a solution for your problem.
> However, I would recommend finding another solution for your network design.
> Whichever way you turn this, it is pretty sick. Even if you can do source
> routing, I would strongly advise against it. It is bad design(TM).
Hmm. There's an awful lot of mission-critical SNA networks running out
there, with source-routing. Might be a bad design but it sure works!
> If you want to take this off-line, I will gladly see if we can come up with
> something that fits your needs better, since this goes beyond the scope of
> current-users, IMHO.