[quagga-dev 775] Re: ripd status

Greg Troxel gdt at ir.bbn.com
Thu Jan 15 16:04:52 GMT 2004


  You're saying that 'alias' is just an ifconfig notation, but I doubt 
  that: assume a multihomed interface with 10.0.0.1/24, 10.0.1.1/24 
  (alias) and 10.0.2.1/24 (alias); what happens when you issue 'ifconfig 
  ifname 10.0.3.1/24'? According to your explanation, 10.0.3.1/24 would 
  replace 10.0.0.1/24 as the primary (non-alias) address, while keeping 
  the other two intact. However, if you claim that alias is just a user 
  syntactic sugar, how does ifconfig actually remove the old address and 
  install the new one such that it is the *first* in the list of IPv4 
  addresses? 

No, I've read the code.   It really is in sbin/ifconfig.c.

I did the experiment you described, and got this:

        inet 10.0.1.1 netmask 0xffffff00 broadcast 10.0.1.255
        inet alias 10.0.2.1 netmask 0xffffff00 broadcast 10.0.2.255
        inet alias 10.0.3.1 netmask 0xffffff00 broadcast 10.0.3.255

So it deleted the first one and then added one.
The new one showed up at the end.

This is arguably odd behavior.
But, either you do manual remove and add with 'alias', or you just
have one.

  If I accept your saying that 'alias' has no meaning other 
  than "not first", then how can ifconfig set an address to be "first" 
  (meaning, non-alias)?

Well, it could use some mythical add-first ioctl, or remove all and
readd, or something.  Right now it doesn't.

  > This is a broken setup; the 10.0.2.0/29 block is for vhosts and there
  > is no reason to expect to find say .4 on the same ethernet; the point
  > of the scheme is to distribute all of those addresses to their
  > servers.
  > Really this address should be configured as a /32, and I think best
  > practices call for it to be on lo0 too.  (This way only packets that
  > are routed to the box are answered, and we are very sure that it will
  > not be used for a source address of a new sendto()/connect().

  I'm afraid I didn't quite understand the moral of this example -- ?

With the (real) setup I described, attempts to connect to 10.0.2.4/29
may fail, since that address isn't necessarily on a host on that LAN,
since the setup is to assign the /29 to virtual use, assign individual
addressses (e.g. www.ir.bbn.com) to specific hosts, and then inject
/32 routes to the 'real' hosts for each virtual address.
So it should be set up not to assume that the other virtual addrs are
reachable directly, because they might not be.

  Or the other way round: in IPv4, it is legacy to have a single address, 
  and so legacy-derived schemes use all kind of tricks (like aliases)... ;->

Sure.  The natural thing would be to drop the 'alias' flag and the
delete-on-new-addr behavior of ifconfig.

  On the other hand, a simple extension to Linux's ioctl/netlink can imply 
  different fallback policy for a deleted primary address, like promoting 
  the first (FIFO order) secondary in the chain.

Sounds fine, but there's always the 'does the kernel need to do this,
or can ifconfig' debate (that isn't useful to have).

  Didn't ever check, however I believe it does (otherwise can't tell how 
  source address ambiguity problem is resolved).

BSD resolves it without flags.  Look at the route that got us here,
find a matching prefix, and take the first one.  Arguably this is less
flexible/configurable, but it basically works.

actually v6 source selection is much more complicated, since if you
have an interface with only link-local addrs (eg. gif in some cases,
ppp), locally-originated packets going over the ppp interface need to
get a global addr from someplace, and an addr (from another interface)
is chosen.




More information about the Quagga-dev mailing list