Professional Web Applications Themes

What provides default router via DHCP? - Linux / Unix Administration

I've got an ADSL modem/router/firewall which is *not* configured as a DHCP server, although it can be. I'm choosing to not configure it as such, despite this might seem logical, since I want to learn a bit more about DHCP. I have a Sun, on the same subnet running Solaris 10 which *is* configured as a DHCP server. When I set up the DHCP server, I configured it to use the "router discovery method", but I don't anything about this "router discovery method". I put a DHCP client on the network (another Sun, this time running Solaris 9). When this ...

  1. #1

    Default What provides default router via DHCP?

    I've got an ADSL modem/router/firewall which is *not* configured as a
    DHCP server, although it can be. I'm choosing to not configure it as
    such, despite this might seem logical, since I want to learn a bit more
    about DHCP.

    I have a Sun, on the same subnet running Solaris 10 which *is*
    configured as a DHCP server. When I set up the DHCP server, I configured
    it to use the "router discovery method", but I don't anything about this
    "router discovery method".

    I put a DHCP client on the network (another Sun, this time running
    Solaris 9). When this client boots it gets

    a) hostname
    b) domain name
    c) IP address
    d) Addresses of the DNS servers.

    but the DHCP client does *not* pick up the address of the router, as
    netstat shows.

    % netstat -rn

    Routing Table: IPv4
    Destination Gateway Flags Ref Use Interface
    -------------------- -------------------- ----- ----- ------ ---------
    192.168.0.0 192.168.0.209 U 1 4 le0
    224.0.0.0 192.168.0.209 U 1 0 le0
    127.0.0.1 127.0.0.1 UH 1 44 lo0

    Hence the client can't connect to the internet.

    Where is the default route supposed to be obtained from? Is the DHCP
    server (the Sun) supposed to send it to the DHCP clients, or are the
    clients supposed to get it directly from the router?

    --
    Dave K

    http://www.southminster-branch-line.org.uk/

    Please note my email address changes periodically to avoid spam.
    It is always of the form: Hitting reply will work
    for a couple of months only. Later set it manually. The month is
    always written in 3 letters (e.g. Jan, not January etc)
    Dave Guest

  2. #2

    Default Re: What provides default router via DHCP?

    In article <67.96.135>, Dave wrote: 

    I know nothing of "router discovery method", but I thought it had something to
    do a router-to-router protocol, not servers...

    In any case, I use ISCD dhcpd on Linux with the following line in the
    dhcpd.conf:

    option routers 192.168.0.1; # changed to protect the innocent!

    Typically, the DHCP client will get router info from the DHCP server...

    Kevin


    --
    Unix Guy Consulting, LLC
    Unix and Linux Automation, Shell, Perl and CGI scripting
    http://www.unix-guy.com
    Kevin Guest

  3. #3

    Default Re: What provides default router via DHCP?

    Dave wrote: 

    Do you mean rdisc/in.rdisc? It was a program that would listen for
    RIP broadcasts and install the router doing the broadcasts as a
    default router. If more than one router broadcast RIP, more than
    one route got installed. Very simple-minded, but also pretty effective
    for a host.

    As RIP becomes less and less popular, it gets to be a less and
    less effective method. I haven't read the man page for rdisc for
    several years so it may well listen for RIPv2, OSPF or whatever in
    current versions. Listening for any routing protocol and deciding
    that the machine transmitting it is a router is a very simple method.
    Just right for a host, disasterously simple for a router.

    Doug Guest

  4. #4

    Default Re: What provides default router via DHCP?

    Kevin Collins wrote:
     

    I've been led to believe that the router, not the DHCP server is
    responsible for announcing the router to the client.

    http://groups.google.co.uk/group/comp.unix.solaris/browse_thread/thread/c741bde467a15735/4d3f923bdb400112?lnk=st&q=DHCP+client+does+not+get +a+default+route&rnum=1&hl=en#4d3f923bdb400112

    Someone else said that was true too. It would appear my router does not
    do this. No doubt it will if I was to turn on its DHCP server, but I
    don't wish to do that. It seems that with my particular router (am
    Intertex IX66 home-office ADSL modem/firewall/router) this will not happen.



    --
    Dave K

    http://www.southminster-branch-line.org.uk/

    Please note my email address changes periodically to avoid spam.
    It is always of the form: Hitting reply will work
    for a couple of months only. Later set it manually. The month is
    always written in 3 letters (e.g. Jan, not January etc)
    Dave Guest

  5. #5

    Default Re: What provides default router via DHCP?

    In article <67.96.135>,
    Dave
    <or
    g.uk> wrote:
     
    >
    > I've been led to believe that the router, not the DHCP server is
    > responsible for announcing the router to the client.[/ref]

    Although there's a Router Discovery Protocol that can be used for this,
    it's not the usual way it's done. Normally the default gateway is
    provided by the DHCP server.

    --
    Barry Margolin, mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***
    Barry Guest

  6. #6

    Default Re: What provides default router via DHCP?

    Barry Margolin wrote: 
    >>
    >>I've been led to believe that the router, not the DHCP server is
    >>responsible for announcing the router to the client.[/ref]
    >
    >
    > Although there's a Router Discovery Protocol that can be used for this,
    > it's not the usual way it's done. Normally the default gateway is
    > provided by the DHCP server.
    >[/ref]

    I'm pretty new to DHCP, having just set the server up a night or so ago.
    On Solaris there is a GUI for this (I normally avoid GUI's, but Sun
    reccomened you use it unless you know what you are doing). That GUI has
    two options

    a) The DHCP sever providing the router address, in which case you have
    to enter it.

    b) The default method, which is this Router Discovery Protocol.

    Not knowing what I was doing I took the default, but soon realised the
    address of the router was being communicated to the client. I then went
    back in, changed from the Router Discovery Protocol to a hard-code of
    the routers address and it all worked OK.

    I was just more interested in why the behavior was as it is. The
    "problem" is solved, but I'd like to understand it more.

    --
    Dave K

    http://www.southminster-branch-line.org.uk/

    Please note my email address changes periodically to avoid spam.
    It is always of the form: Hitting reply will work
    for a couple of months only. Later set it manually. The month is
    always written in 3 letters (e.g. Jan, not January etc)
    Dave Guest

  7. #7

    Default Re: What provides default router via DHCP?

    "Doug Freyburger" <com> writes: 
    >
    > Do you mean rdisc/in.rdisc? It was a program that would listen for
    > RIP broadcasts and install the router doing the broadcasts as a
    > default router.[/ref]

    That's inaccurate.

    Rdisc ("router discovery") is an ICMP based protocol. It has nothing
    whatsoever to do with RIP. See RFC 1256.

    It's also an unnecessary protocol, because, as you rightly note, the
    same thing can be done better using RIP.
     

    In old Solaris releases, we had a separate in.rdisc and in.routed. At
    boot time, we'd run in.rdisc once to check to see if there were Router
    Discovery servers out there on the network. If so, we'd run in.rdisc
    alone. If not, we'd run in.routed.

    As of Solaris 9 Update 1, in.routed supports both ICMP router
    discovery and RIP-2. We just run that, and there's no clumsy boot
    time switch needed.

    (Unfortunately, if you run DHCP as a client on Solaris and the DHCP
    server supplies a default router address, the system automatically
    disables in.routed, on the "assumption" that the DHCP server knows
    best. Why exactly a DHCP server would know more about routing than a
    RIP router is a subject for another time.)

    --
    James Carlson, KISS Network <com>
    Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
    James Guest

  8. #8

    Default Re: What provides default router via DHCP?

    Begin <com>
    On 2006-01-02, James Carlson <com> wrote: 

    Provided you run RIP (or RIPv2 or OSPF or whatever) and want your hosts
    to speak it, or at least listen to it, too. I'd not be too happy to do
    that. I'd also note that IPv6 has a similar router discovery mechanism.

     

    Not about routing, per-se. If you run the dhcp client you are presumably
    running a dynamic host box which presumably needs a default router, not
    a routing daemon. This is mostly inferrence from what you say above,
    and not a comment on the wisdom of the policy.

    Somewhere upthread it was mentioned that the solaris recommended default
    was to use rdisc and forego dhcp default router distribution. I am not
    aware of many shops doing this so I'm not too clear on the why of the
    recommendation.


    I personally would setup a dhcpd and use that, and not run routing
    protocols in network leaves at all. I haven't found a need to run rdisc,
    spoiled as I am with dhcpd. I do prefer to keep the number of services
    I need to run the network down a bit, so if I can drop rdisc or routed
    because dhcpd can distribute default routes too, I tend to prefer that.
    If I needed to provide for default router fail-over I'd probably look
    into doing it through ARP tricks and between-router synchronisation, as
    multiple-default router support is in solaris but not much else that I
    am aware of.


    --
    j p d (at) d s b (dot) t u d e l f t (dot) n l .
    This message was originally posted on Usenet in plain text.
    Any other representation, additions, or changes do not have my
    consent and may be a violation of international copyright law.
    jpd Guest

  9. #9

    Default Re: What provides default router via DHCP?

    jpd <not.spam.it.invalid> writes: 
    >
    > Provided you run RIP (or RIPv2 or OSPF or whatever) and want your hosts
    > to speak it, or at least listen to it, too. I'd not be too happy to do
    > that. I'd also note that IPv6 has a similar router discovery mechanism.[/ref]

    I think that you might have misunderstood what I was saying.

    Router discovery injects an unauthenticated default route into the
    listening nodes. In fact, that's all it can do, as it carries no
    information about authentication or destination networks or netmasks
    or the like.

    RIP can do *PRECISELY* the same thing. If you choose, you can have
    your router emulate router discovery by sending a single RIP
    advertisement containing a single default route. That's equivalent.

    This accomplishes the same thing as router discovery using an existing
    protocol and without substantial changes. Thus I claim that router
    discovery was not strictly necessary. (The narrow case where it might
    be "necessary" is where you're running RIP as your IGP *without*
    authentication and you also want to distribute a default route to some
    clients on the same network. The obvious workarounds are [a] let all
    your clients listen to the regular RIP advertisements, [b] use
    authentication for the real RIP-2 traffic and send out unauthenticated
    default routes for the "dumb" nodes, or [c] use something other than
    RIP for the IGP.)

    The fact that IPv6 has a similar mechanism built into NDP (and a very
    _strange_ entanglement between Neighbor Advertisement flags and router
    identity) doesn't change this.
     
    >
    > Not about routing, per-se. If you run the dhcp client you are presumably
    > running a dynamic host box which presumably needs a default router, not
    > a routing daemon. This is mostly inferrence from what you say above,
    > and not a comment on the wisdom of the policy.[/ref]

    That's not what I was saying.

    The strange architectural assumptions of DHCP are that there are one
    or more egress routers on the local network that are equivalent for
    all IP destinations ("default routers"), and that somehow the DHCP
    server has reliable knowledge of which egress router(s) the client
    ought to be using even on distant client networks.

    I don't see (and have never seen) why any of that ought to be true,
    irrespective of what DHCP clients may or may not need to do.
     

    Making sure your DHCP server configuration data are in sync with your
    network routing deployment can be an annoyance. Every time you change
    the routing topology, you'll have to remember to update the DHCP
    servers. It's much harder still to do this if you have any DHCP/BOOTP
    proxies or forwarders in the network.
     

    .... and I prefer to use protocols for the purpose for which they were
    designed. As a routing protocol, DHCP leaves a _great_ deal to be
    desired.

    Yes, DHCP masquerades as a routing protocol. You might not think
    you're running a "routing protocol" on your network, but you actually
    are. A "routing protocol" is nothing more than a means to learn about
    routes -- and the DHCP Router Option token does just that. Its
    failings as a routing protocol include:

    - No aging or regular update mechanism. If one of the routers dies,
    falls over, is reconfigured, or just stops forwarding, there's no
    way for any client to know, except that contact with the world
    will be lost. If new routers are added, existing clients won't
    know until their leases expire and they renew.

    - Severely limited handling of multiple egresses. The routers
    specified by DHCP (and by router discovery) must all be equivalent
    and must all reach all destinations. Otherwise, you end up with a
    sea of redirects -- which is itself also a routing protocol, and a
    _much_ worse one than either DHCP or RIP at that.

    - No security. All modern routing protocols (including RIP-2) can
    carry at least some minimal authentication data, such as MD5
    hashes. DHCP and router discovery do not.

    I don't believe that a strict count of the number of protocols one is
    using is necessarily a useful metric. I think that functionality is
    sometimes a bit more important.

    --
    James Carlson, KISS Network <com>
    Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
    James Guest

  10. #10

    Default Re: What provides default router via DHCP?

    On 2006-01-03, James Carlson <com> wrote:

    As a network geek by trade, I felt maybe I could add some $0.02 cents that's
    hopefully helpful...
     

    I'll respectfully disagree. A routing protocol is a bunch more than a means to
    learn about routes - it's actually a means (depending on routing protocol) to
    -calculate- and determine "next-hop" information for network prefixes
    (ogous to subnets mostly). The presence of a default route via RIP "back
    in the day" I remember from large enterprises I worked with was a convenience
    we provided to the UNIX infrastructure, where we had the two available default
    routers both provide a default route, and whichever the host picked up first,
    it used. Not great for load-balancing, but it did work. Fail-over time wasn't
    a great help and I never trusted any UNIX OS really to purge a RIP-derived
    default route and install a new one auto-magically.

    I think the shortcomings of DHCP as you mention them are really rooted in
    something older - back in the times when routers and hosts were the same
    product, literally - like when NSF-Net ran IBM RS/6000's with RIP and that
    formed a significant part of the then-Internet backbone. When routers "split
    off" as separate products and became titans of IT like Cisco & Juniper, the
    RFC's made it clear what a router had to do but nothing of how a host, once a
    router, should or should not do. A host is a router too, albeit for itself.
    So, things like default routing dangle in between, waiting to be fixed by the
    promises of IPv6.
     
    > specified by DHCP (and by router discovery) must all be equivalent
    > and must all reach all destinations. Otherwise, you end up with a
    > sea of redirects -- which is itself also a routing protocol, and a
    > _much_ worse one than either DHCP or RIP at that.[/ref]

    Network geeks think this tastes bad too. :) ICMP re-directs, IMHO, in modern
    networks, should just be turned off for security reasons unless there's a
    really valid case for the function, like if you have a router with multiple IP
    networks on a single physical interface and you want redirection (rare today).
     
    > carry at least some minimal authentication data, such as MD5
    > hashes. DHCP and router discovery do not.[/ref]

    This is my biggest gripe with DHCP too. And as for so many standards? It's a
    gift of the Internet, Jon Postel (rest his soul) and many others that the
    protocol is open enough that so many things can be invented without the
    approval of only one vendor. I'll deal happily with creative solutions instead
    of the vendor-sanctioned alternative only each time.

    -DMFH

    ----
    __| |_ __ / _| |_ ____ __
    dmfh / _` | ' \| _| ' \ _ / _\ \ /
    \__,_|_|_|_|_| |_||_| (_) \__/_\_\
    ----
    DMFH Guest

  11. #11

    Default Re: What provides default router via DHCP?

    DMFH <dmfh.cx.spamn0t> writes: 

    A network geek as opposed to what? Me?
     

    Ignoring route summarization, policy, and various other bits.

    We just said the same thing.

    The "calculation" you mention is in essence optional in defining the
    role of routing. A routing protocol is a mechanism that allows
    systems connected to the network to learn what routes are in use.
    That process *may* involve calculation or other arranging of the data
    (less in some D-V protocols, more in LS protocols), but that's really
    of no matter when viewed from the outside. The point is that the
    systems exchange information that results in routes being determined.
    How that exactly happens is mostly a matter for those of us who do, in
    fact, work on them, and not those who need to rely on them.
     

    Not quite true.

    You can have zero, one, two, or many default routes advertised via
    RIP. RIP doesn't actually care how many there are.

    The fact that 'some' implementations or administrators don't deal with
    this well isn't the fault of the protocol.
     

    .... and that's the problem. There are some amazingly awful
    *implementations* of RIP out there in the world, some in places that
    you wouldn't (or maybe shouldn't) expect -- in terms of functionality
    and performance.

    Be that as it may, I contend that it's just wrong to pretend as though
    DHCP isn't being used as a routing protocol, just as ICMP Redirect is
    a routing protocol. It performs the same functions. The notable
    difference is that these solutions are awful in terms of performance,
    scalability, and administrative overhead, and can't actually be fixed
    at all because (unlike RIP and other routing protocols) the faults
    aren't due to implementation errors.
     

    It's that bit, implying a return to the split universe, with which I
    disagree.

    I do not subscribe to the "host" versus "router" means of splitting up
    the world. To me, they're all IP nodes.

    In this particular case, putting DHCP functionality somewhere _other_
    than your routers allows you to do some useful things:

    - Have different administrative authorities responsible for general
    routing between subnets and address assignment within subnets.
    This is common, and it'd be nice to say that administrative
    segregation within routers works, but, well, it doesn't.

    - Integrate your DHCP system with something other than just address
    assignment, such as network booting and host configuration
    management.

    - Deal with physical networks that may have multiple subnets,
    multiple egress routers, and routers that don't necessarily "know"
    about all of the other networks in use (e.g., private networks).

    There are potentially others, but the bottom line is that I don't
    agree that all DHCP functions should be fobbed off on routers. That's
    a deployment decision that's up to network administrators. I'd
    happily support someone who wanted to do that in his network, but
    saying that it's the desired way to do things (and that the router
    vendors pushed us off the right path) seems a bit too narrow to me.
     
    > > specified by DHCP (and by router discovery) must all be equivalent
    > > and must all reach all destinations. Otherwise, you end up with a
    > > sea of redirects -- which is itself also a routing protocol, and a
    > > _much_ worse one than either DHCP or RIP at that.[/ref]
    >
    > Network geeks think this tastes bad too. :) ICMP re-directs, IMHO, in modern
    > networks, should just be turned off for security reasons unless there's a
    > really valid case for the function, like if you have a router with multiple IP
    > networks on a single physical interface and you want redirection (rare today).[/ref]

    No, redirections are just plain broken. If you run a proper routing
    protocol, you don't need them at all, and (by 1812) you're supposed to
    ignore them.

    I don't agree that there's a valid reason for them on modern networks,
    except what looks to me like a not-entirely-rational fear of all
    things labeled "routing."

    The dark humor in the situation for me (a network routing geek) is
    that DHCP/BOOTP, redirects, and other protocols (e.g., bootparams on
    Sun machines) are used as ersatz routing protocols ... but badly. So
    those people who think they're "avoiding" the "trouble" of routing
    actually aren't, and are in fact stepping into the worst possible
    situation with protocols that don't fit the bill.

    Oh, well.
     
    > > carry at least some minimal authentication data, such as MD5
    > > hashes. DHCP and router discovery do not.[/ref]
    >
    > This is my biggest gripe with DHCP too. And as for so many standards? It's a
    > gift of the Internet, Jon Postel (rest his soul) and many others that the
    > protocol is open enough that so many things can be invented without the
    > approval of only one vendor. I'll deal happily with creative solutions instead
    > of the vendor-sanctioned alternative only each time.[/ref]

    I'm not sure how to read that.

    --
    James Carlson, KISS Network <com>
    Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
    James Guest

Similar Threads

  1. Replies: 2
    Last Post: February 17th, 04:09 PM
  2. Replies: 6
    Last Post: November 4th, 07:16 PM
  3. Mac Friendly Router (DHCP) & firewall?
    By DaveC in forum Mac Networking
    Replies: 37
    Last Post: November 3rd, 09:37 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139