bind9-users Digest V5 #155

Sten Carlsen ccc2716 at vip.cybercity.dk
Tue Jun 15 23:42:29 UTC 2004


Jean Tourrilhes wrote:
>On Tue, Jun 15, 2004 at 09:46:41AM +0200, Sten Carlsen wrote:
>  
>
>>Jean Tourrilhes wrote:
>>
>>Yes for mobile and even portable (battery operated) devices all 
>>interfaces not needed will be not just down, they will be "power off". 
>>This leaves the question of switching sequence: current if goes down 
>>(off line) before next is started. Or opposite? I believe in the first. 
>>    
>>
>
>	With my proposal, it does not matter. The key is too keep
>configuration associated with interfaces through the "include"
>directive.
>  
>
I slightly disagree; the key is to use the includes in the right 
sequence or priority. One thing I did not catch in your proposal was how 
to select the proper include file at this moment (probably I was not 
paying attention).

>  
>
>>A user will always(?) use the cheapest way to connect and only when that 
>>fails switch to the next option (if any).
>>    
>>
>
>	Not always. I can see more complex policies than that (that's
>what I'm currently researching). You may want to take into account
>your bandwidth need as well, and QoS constraints ;-)
>  
>
Yes, I did not write that, it would have been too long. Perfectly true. 
Also operator preferences may interfere.

>  
>
>>If this is true, clean up is 
>>much easier and only the code for each if going up or down needs to be 
>>involved. This is pretty much current situation, where this gets messy 
>>is when you also have fixed (static) setups involved, and when DHCP or 
>>PPP will not provide the needed details.
>>    
>>
>
>	But even with static config, the judicious use of the
>"include" directive with scripts can help tremendously.
>
>  
>
>>Fresh from the system (behind a NAT. All details given by DHCP):
>>
>>silver:/etc>cat resolv.conf
>>domain s-carlsen.dk
>>nameserver 192.168.14.254
>>    
>>
>
>	What's interesting is how the content of this file evolves as
>you connect to multiple networks.
>  
>
Bringing up PPP does not change that file. Bringing WLAN down while PPP 
is up does change it to reflect two different nameservers and no domain. 
Wlan back up, changes it back to the one listed above.
In short: it works like a dream.

For your reference the routing table with both wlan and PPP up is shown 
below:

Routing tables

Internet:

Destination        Gateway            Flags    Refs      Use  Netif Expire

default            christina.s-carlse UGSc        6        0    en1

10.6.6.6           213083225201.sonof UH          0        0   ppp0

localhost          localhost          UH         10    31236    lo0

169.254            link#5             UCS         0        0    en1

192.168.14         link#5             UCS         2        0    en1

silver.s-carlsen.d localhost          UHS         0        0    lo0

christina.s-carlse 0:2:96:1:3e:98     UHLW        4       74    en1   1018

192.168.14.255     ff:ff:ff:ff:ff:ff  UHLWb       0        3    en1


>  
>
>>All the resolver/* stuff is for "Rendevouz" = multicast DNS , even that 
>>works together with windows on a separate isolated network.
>>    
>>
>
>	Fortunately, we are not dealing (yet) with multicast DNS ;-)
>  
>
You probably will have to, or you could use UPNP. Some sort of service 
discovery will be needed to utilise such devices. Specially the very 
mobile ones.

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!" 





More information about the bind-users mailing list