Many routing engines based on Un*x have one or more alias addresses
assigned to the loopback interface, in addition to 127.0.0.1.  This is
usually done because some routing protocols, such as BGP, use TCP
sessions to exchange data.  You generally do not want that TCP session
to fail (and thus lose access to all outside world routing information)
unless ALL possible routes between the two BGP peers are down.

In other words, I want to be able to address a packet to a router's
loopback (alias) address, and I want that packet to get there if at all
possible.

On Wed, 11 Nov 1998, Luke Mewburn wrote:

> Paul Goyette writes:
> > Does the loopback interface still work?
> > 
> > In particular, is it still valid for a packet addressed to the NetBSD
> > system's loopback interface (or any of its routable alias addresses) to
> > arrive via _any_ available physical interface?
> 
> I'm yet to fully test the idea, but I believe that the patch will
> stop this behaviour. That is the point of running as a strong end
> system.
> 
> 
> > This is important for those who may be running their NetBSD system not
> > just as a "router" but also as a "routing engine".  If anyone is using
> > their NetBSD system as a BGP router, they are probably using the
> > loopback interface's address as the local address on all of their
> > peering sessions.  It is also quite common for one to use the loopback
> > interface as the OSPF Router ID and to advertise that interface as a
> > "stub host" into the OSPF routing domain.
> 
> I'm not following you here; you're saying that the loopback (127.0.0.1)
> is the local address; how does the remote end know what address to
> put in as the destination, since 127.0.0.1 is loopback on *their*
> machine.
> 
> 
> > Also, it sounds as though your changes might break some other useful
> > diagnostic tools, such as sending a ping with a particular source
> > address and being able to see the response.  This is a quite common
> > troubleshooting technique in the world of dynamic routing protocols.
> 
> I'll check this, but I don't think that this will break.
> 
> 
> > Finally, you note that setting the IPSTRONGENDSYSTEM option in the
> > config file will "hardwire" the option on.  Would it not make more sense
> > to make the option simply set the initial default value, thus enabling
> > one to turn it off later if needed?  If you're really paranoid, you can
> > always come up with another config option that disables changing the
> > sysctl variable.
> 
> I should have been clearer; setting IPSTRONGENDSYSTEM to non-zero
> changes the default to on, but sysctl can still be used to manipulate
> the setting.
> 

-----------------------------------------------------------------------------
| Paul Goyette      | PGP DSS Key fingerprint:   | E-mail addresses:        |
| Network Engineer  |   BCD7 5301 9513 58A6 0DBC |  paul@whooppee.com       |
| and kernel hacker |   91EB ADB1 A280 3B79 9221 |  paul.goyette@ascend.com |
-----------------------------------------------------------------------------