pppd not setting netmask

pppd not setting netmask

[Ross Vandegrift]

Hello everyone,

	I'm using pppd with vtun to create dynamic VPNs to connect
remote networks.  I had everything almost working, but noticed a bad
problem with routing and traced it back to netmasks.

	I'm creating ppp tunnels with non-routeable networks to conserve
our IP space.  The first tunnel is using 10.100.100.0/30, with .1 being
the router at the office, and .2 being the remote router.

	My options file has "netmask 255.255.255.252" in it, but when
pppd comes up, ifconfig shows that ppp0 still has 255.255.255.255 for a
netmask.  How can I convince ppp0 to have the proper netmask?  The logs
don't have any error messages mentioning a problem setting the netmask
or anything.  Adding "debug" doesn't give me any extra information.

	This is bad because the connected route that gets installed is
for the opposite end of the tunnel (ie, 10.100.100.1/32) and not the
route for the 10.100.100.0/30.  This confuses OSPF quite a bit (see my
quagga-users thread with all the gorey OSPF details and routes:
http://lists.quagga.net/pipermail/quagga-users/2004-January/001382.html)
-- 
Ross Vandegrift
ross@willow.seitz.com

A Pope has a Water Cannon.                               It is a Water Cannon.
He fires Holy-Water from it.                        It is a Holy-Water Cannon.
He Blesses it.                                 It is a Holy Holy-Water Cannon.
He Blesses the Hell out of it.          It is a Wholly Holy Holy-Water Cannon.
He has it pierced.                It is a Holey Wholly Holy Holy-Water Cannon.
He makes it official.       It is a Canon Holey Wholly Holy Holy-Water Cannon.
Batman and Robin arrive.                                       He shoots them.

Re: pppd not setting netmask

[Paul Mackerras]

Ross Vandegrift writes:

> 	This is bad because the connected route that gets installed is
> for the opposite end of the tunnel (ie, 10.100.100.1/32) and not the
> route for the 10.100.100.0/30.  This confuses OSPF quite a bit (see my
> quagga-users thread with all the gorey OSPF details and routes:
> http://lists.quagga.net/pipermail/quagga-users/2004-January/001382.html)

The netmask has no meaning on a point-to-point interface.  If other
software isn't looking at the IFF_POINTOPOINT bit in the interface
flags, then I suggest you fix that other software.

Paul.

Re: pppd not setting netmask

[Ross Vandegrift]

> Ross Vandegrift writes:
> 
> > 	This is bad because the connected route that gets installed is
> > for the opposite end of the tunnel (ie, 10.100.100.1/32) and not the
> > route for the 10.100.100.0/30.  This confuses OSPF quite a bit (see my
> > quagga-users thread with all the gorey OSPF details and routes:
> > http://lists.quagga.net/pipermail/quagga-users/2004-January/001382.html)
> 
> The netmask has no meaning on a point-to-point interface.  If other
> software isn't looking at the IFF_POINTOPOINT bit in the interface
> flags, then I suggest you fix that other software.

Is this a technical issue, or a policy decision?  According to a recent
HOWTO (http://sweb.cz/Frantisek.Rysanek/sync/dscc4+HDLC-Mini-HOWTO.html),
the generic HDLC layer allows a netmask to be set on pointopoint
interfaces (see the very first instance of 'ifconfig').  I don't have
any HDLC hardware to actually test this with, though.

If it's a technical issue, are there things I can do to help?  My
employer probably wouldn't mind me spending some time on this to have
our tunnels work the way we assumed they would.

If it's a policy decision, am I opening an ugly can of worms by trying
to setup a network topology like this?

-- 
Ross Vandegrift
ross@willow.seitz.com

A Pope has a Water Cannon.                               It is a Water Cannon.
He fires Holy-Water from it.                        It is a Holy-Water Cannon.
He Blesses it.                                 It is a Holy Holy-Water Cannon.
He Blesses the Hell out of it.          It is a Wholly Holy Holy-Water Cannon.
He has it pierced.                It is a Holey Wholly Holy Holy-Water Cannon.
He makes it official.       It is a Canon Holey Wholly Holy Holy-Water Cannon.
Batman and Robin arrive.                                       He shoots them.

Re: pppd not setting netmask

[Bill Unruh]

On Mon, 2 Feb 2004, Ross Vandegrift wrote:

> > Ross Vandegrift writes:
> > 
> > > 	This is bad because the connected route that gets installed is
> > > for the opposite end of the tunnel (ie, 10.100.100.1/32) and not the
> > > route for the 10.100.100.0/30.  This confuses OSPF quite a bit (see my
> > > quagga-users thread with all the gorey OSPF details and routes:
> > > http://lists.quagga.net/pipermail/quagga-users/2004-January/001382.html)
> > 
> > The netmask has no meaning on a point-to-point interface.  If other
> > software isn't looking at the IFF_POINTOPOINT bit in the interface
> > flags, then I suggest you fix that other software.
> 
> Is this a technical issue, or a policy decision?  According to a recent
> HOWTO (http://sweb.cz/Frantisek.Rysanek/sync/dscc4+HDLC-Mini-HOWTO.html),
> the generic HDLC layer allows a netmask to be set on pointopoint
> interfaces (see the very first instance of 'ifconfig').  I don't have
> any HDLC hardware to actually test this with, though.

netmask makes no sense on a point to point device. It is point to
point-- one machine to one machine. This does not mean that you cannot
route other connections via that point to point link. You can route
anything you want, using the standard routing procedures in your OS.
Ie, even if the netmask were set it would not make any sense-- there is
only one machine at the other end of the link and everything has to go
through it. 

Why in the world would you want to insert routing code into ppp-- liable
to be buggy, inconsistant, etc-- when your ordinary routing code in the
system is perfectly capable of handling it. 


> 
> If it's a technical issue, are there things I can do to help?  My
> employer probably wouldn't mind me spending some time on this to have
> our tunnels work the way we assumed they would.

Just set up explicit routing of the other stuff you want to go through
the link.

> 
> If it's a policy decision, am I opening an ugly can of worms by trying
> to setup a network topology like this?
> 

Re: pppd not setting netmask

[Ross Vandegrift]

On Mon, Feb 02, 2004 at 01:55:37PM -0800, Bill Unruh wrote:
> Why in the world would you want to insert routing code into ppp-- liable
> to be buggy, inconsistant, etc-- when your ordinary routing code in the
> system is perfectly capable of handling it.

Well, it's not that I want anything inserted into ppp - I'm just trying
to understand why things are different on Linux.  I'm confused because this
is how it's often done on Cisco and I can't see why it's wrong:

           1.1.1.1/24   2.2.2.1/30   2.2.2.2/30    3.3.3.1/24
{NETA} <--ethernet--> RTR1 <---via PTP T1---> RTR2 <--ethernet--> {NETB}

The interfaces on RTR1 and RTR2 that are directly connected are
configured to be the only IPs on a /30 network.

The situation on GNU/Linux with pppd is aparantly different.  I'm not
trying to say we should change it if it's right - it's very possible
that I need to be thinking about networks differently.

> > If it's a technical issue, are there things I can do to help?  My
> > employer probably wouldn't mind me spending some time on this to have
> > our tunnels work the way we assumed they would.
> 
> Just set up explicit routing of the other stuff you want to go through
> the link.

I'm trying to avoid setting up explicit routes in a dynamic network.
Fail-over routing is much easier if all routes are dynamically handled
via ospf.  Perhaps if I give a quick explanation of the problem I'll
make more sense:

The way things are done now, is that the connected route for ppp0 is set
to the *other* end of the tunnel.  If RTR1 and RTR2 above are instead
configured using pppd, RTR1 won't know how to route to its own ppp0 interface
until it receives an OSPF route from the other end.  Then, on RTR1, you end
up with this really weird routing table:

C>* 2.2.2.2/32 is directly connected, ppp0
O>* 2.2.2.1/32 [110/20] via 10.100.100.2, ppp0, 6d20h09m

So now RTR1 thinks it needs to route through RTR to get to it's own PPP
interface.

The reason I thought this was a problem in pppd is because the manpage
documents a "netmask" statement that sounds like it does exactly what I
want!

(In reality, something, somewhere steps in and overrides the routing
table with some sanity - packets to 2.2.2.1 don't actually traverse the
ppp connection.  I have no idea how this happens without a route.)

Thanks,

Ross Vandegrift

Re: pppd not setting netmask

[Paul Mackerras]

Ross Vandegrift writes:

> Is this a technical issue, or a policy decision?  According to a recent
> HOWTO (http://sweb.cz/Frantisek.Rysanek/sync/dscc4+HDLC-Mini-HOWTO.html),
> the generic HDLC layer allows a netmask to be set on pointopoint
> interfaces (see the very first instance of 'ifconfig').  I don't have
> any HDLC hardware to actually test this with, though.

It's a technical issue.  The decisions about which interface to use to
send a given IP packet are made based on the routing table rather than
the interface local address (except that if the packet is addressed to
the local address of any interface, it's effectively sent via
loopback).  When an interface is brought up, an entry is put into the
routing table.  The netmask is used at that time for non
point-to-point interfaces, and becomes the netmask for the route.  For
a point-to-point interface, the route that gets added is a host route,
and so the netmask is irrelevant (you can set whatever netmask you
like, it doesn't change anything).

> If it's a technical issue, are there things I can do to help?  My
> employer probably wouldn't mind me spending some time on this to have
> our tunnels work the way we assumed they would.

It's probably as simple as a couple of 'ip route' commands in your
ip-up script.  What are you trying to achieve?

Paul.

Re: pppd not setting netmask

[Paul Mackerras]

Ross Vandegrift writes:

> The way things are done now, is that the connected route for ppp0 is set
> to the *other* end of the tunnel.  If RTR1 and RTR2 above are instead
> configured using pppd, RTR1 won't know how to route to its own ppp0 interface
> until it receives an OSPF route from the other end.  Then, on RTR1, you end
> up with this really weird routing table:
> 
> C>* 2.2.2.2/32 is directly connected, ppp0
> O>* 2.2.2.1/32 [110/20] via 10.100.100.2, ppp0, 6d20h09m
> 
> So now RTR1 thinks it needs to route through RTR to get to it's own PPP
> interface.

That looks like a bug in the OSPF daemon - it should realize that no
routing is needed to get the local address of any interface.  But it
shouldn't matter anyway since no-one will be using that address as the
endpoint of any connections, I would expect.

In fact, from the kernel's point of view, there is really no need to
have addresses on either end of the ppp link, because routes can
specify a device instead of a gateway address.  This is different from
the BSD IP implementation, where the routing table was used to
translate a destination address into a gateway address, and then there
was a step to find an interface which could handle the gateway
address.  On Linux, a route can specify an interface directly.
Thus, apart from the fact that pppd gets upset if it can't work out IP
addresses for both ends of the link, you could in principle just add
a route like this on RTR1:

route add -net 3.3.3.1 netmask 255.255.255.0 dev ppp0

and like this on RTR2:

route add -net 1.1.1.1 netmask 255.255.255.0 dev ppp0

and it should work.

However, as I said, pppd still really wants to work out IP addresses
for both ends of the link.

Paul.