Conference netcad::hub_mgnt

Other than giving the device an IP address, there's no way to turn off bootp.

Bootp requests are sent at the following intervals:  1 second after 
initialization, 2 seconds later, 4 seconds later ...8, 16, 32, and then
every 64 seconds until an IP address is loaded.  I find it hard to believe
that this yields 50% utilization.  It does sound like a problem though.
Wish I had a solution for you.
						-Shawn

    Yes, he says he was exagerating with 50% untilization. However, they
    are very concerned. They say that for every bootp request, they have
    over 100 servers that each send out a response. They are starting to
    set IP addresses in every module, maybe they'll be done around
    Christmas? They also tell me this will burn up three of their subnets
    worth of addresses. What are the implications of setting every module
    to the same address?
    
    Thanks for your reply,
    Darrell

I wasn't brave enough to suggest that they set every one of the devices to
the same IP address.  I think it will be okay, so long as the address is
never used.  I can imagine trouble if another node ARPs for the shared address.

If your customer tries this approach, please let us know how it works.

I'll see that this problem gets attention.

							-Shawn

p.s.  This really isn't important, but I'm curious.  I thought bootp
      servers, on receipt of a bootp request, consulted their bootp table
      (file) to see if they know about the IP/MAC address association
      of the requester.  So based on my understanding the bootp servers
      won't respond unless the MAC address of the device has been manually
      entered in the bootp table.  Can you tell me why 100 servers are
      responding to the request?
                      

Darrell,

I've spoken with others about this.  We agree that giving each device the
same IP address should work.  Let me describe some of the other "solutions"
we discussed.  In no particular order....

1)  Make the bootp request stop after a while.

    The problem with this is that it breaks things for users who
    really use bootp.  Imagine a case where the power goes down in a
    building.  The network devices come back up, but the server does
    not.  The devices stops sending bootp requests.  When the server 
    finally does come back, there's no one to serve anymore.  The user 
    would have to go reset each device in order to get it to start 
    sending bootp requests again.  Bummer.

2)  Decrease the frequency of the bootp requests.  

    The current frequency is 1 second after initialization, 2 seconds 
    later, 4 seconds later...8, 16, 32, and then every 64 seconds until 
    an IP address is loaded.  (This wasn't our invention.  The bootp
    RFC recomends this.)

    We could change this to 1, 2, 4, 6, 32, 64, 128, 256.  This doesn't 
    really solve the problem, it just make it less noticeable.  It also
    makes it slower to really get an IP address.

3)  Add a console command to enable/disable bootp.

    If your customers expects to take "'til Christmas" to set a bogus
    IP address on each device using the console this "solution" might
    enable them to be done by Christmas Eve.

    Visiting the console of each device could take a while.

    Still, this sounds slightly cleaner than telling a customer to go
    to the console and give each device the same IP address.  (Turns out
    to be slightly less practical though.  Users can use bootp to give
    all the devices the same IP address.)
                        
4)  Add a console command to enable/disable bootp and ship the products
    with bootp disabled.

    This would solve your customer's problem, but irk the other <?>% of
    customers who would now have to visit the console of each device to
    enable bootp.  (This would be especially frustration because with 
    bootp, as currently implemented, customers *never* have to do any 
    setup at the console.  That's one of the advantage of bootp.)

I'm sure there are other "solutions" I haven't shot down here.

Anyone have a real solution?

							-Shawn

    
    Shawn,
    
    	With regards to #4 in .4, perhaps ship with bootp enabled as is now. 
        Then when someone gets into a situation where broadcast storms are 
        being created, they will have a way out by trimming back the devices 
        which are participating. As they visit each device's console and do 
        the bootp disable, life gets better. Also the current functionality 
        is maintained for the existing base which relies on it. Perhaps
        over time, HUBwatch could control this feature. This doesn't solve
        today's problem but may help down the road.
    
    Bob
    
    

    Thankyou for all the time you have spent on this. We appreciate it very
    much. Regarding the P.S. in .3; I was told that all the servers are
    responding to the bootp because they are all sending ICMP packets (some
    kind of error packet?). We are a little nervous about setting the same
    IP address in every module so we are using a different address for
    each. Of all the proposed solutions, the customer likes the idea of
    being able to disable bootp via hubwatch. Is there any chance that
    might be done in the future via a firmware change?
    
    We just noticed one of the gigaswitches is also sending bootp requests.
    I hope it is the gigaswitch as a whole and not each of the fddi line
    cards.
    
    Thanks again for all your concern,
    Darrell

    
    I'm interested in hearing from the field on this - does anyone know of
    any customer that is actually using a bootp server to provide addresses
    to DEChub products _instead_ of setting the address permanently from
    the console?
    
    When the address is learned via bootp, it is not saved in nvram, so it
    must be learned on each power-up (leading the the dilemma Shawn pointed
    out a couple of notes ago); addresses set from the console are saved.
    
    One more alternative Shawn did not mention is to suppress the bootp
    request for any hub-mounted device if it learns that the Hub has an IP
    address (this would not preclude using the console to set an address
    for the module).  There is already an internal MIB for this, but it
    isn't yet implemented by the MAM.  This would not do anything for
    standalone devices; if they were not given an address they would
    continue to request them, but then if they're standalone I would think
    that most net managers would want them to have one so they'd be
    managable.
    

RE: Disabaling bootp via HubWatch.

I take it your customer has given the Management Agent Module (MAM) an IP
address and manages the line-cards using the MAM's IP address and SNMP
community <mam-community>-<slot number>?

If this is the case, then yes, adding enable/disable switches in the MAM's 
private MIB, and HubWatch control of these new switches would be a solution.
(I say "switches", plural, because I suspect we'd have to add a switch per
slot to keep this flexible.)  As Scott says in .7 though, this type of 
solution doesn't affect standalone line-cards.

We'll have to talk about when/how/if we solve this problem.

						-Shawn

 >     We just noticed one of the gigaswitches is also sending bootp
 >   requests. I hope it is the gigaswitch as a whole and not each of the fddi
 >   line cards.
    
    You are in luck here.  The Gigaswitch only has one IP address (on the
    SCP card) for the entire box.
    
    Regards,
    
    Bob

    
    
    	There should be some way of enabling/disabling bootp requests.  I
    think .7 is on the right track.  Take advantage of the strengths of the
    hub, ease of management.
    
    Scott

This issue has resurfaced in note 1533.

I need to understand why a bootp server would send an ICMP message in 
response to an unsatisfied bootp request.  What type of ICMP error message 
is sent?  Do most/all bootp servers send these ICMP error messages?

re .7

This alternative would prevent bootp from working when the module is
installed in a hub which has and IP address.  Wouldn't some users still
want to use bootp for the module when installed in the hub?  This seems
like another case where we solve a problem for some and create a problem
for others.

(Actually it's worse than I describe because it could take a while for
the MAM to tell the line-card that the MAM has an IP address.  During that
time the line card may get 1 or 2 bootp requests out.  The might lead
to bootp working intermittently.)

Also, there has been no response to Scott's question to the field about
any customers actually using bootp for hub modules.   Any input?

						-Shawn

>I need to understand why a bootp server would send an ICMP message in 
>response to an unsatisfied bootp request.  What type of ICMP error message 
>is sent?  Do most/all bootp servers send these ICMP error messages?
    
    Shawn, I know of one implementation that used to accept BootP's on
    its own subnet (because they are broadcast), figure out that it can't
    do much with it because it doesn't have the BootP port open,
    and respond with an ICMP port unreachable message.  This implementation
    was non-compliant with RFC-1122, which says that an ICMP response should
    never be sent in response to a broadcast request.  I believe the bug
    has since been fixed.. however I used to see 3 responses to every
    BootP request in the lab a while back! (I think it was an old ULTRIX
    version, but not sure.)
    
>Also, there has been no response to Scott's question to the field about
>any customers actually using bootp for hub modules.   Any input?
    
    I believe CERN uses this as their method of IP address administration,
    from a telecon I attended with them a while back.
    
    Anil

Note 1533.4 contains current plans for disabling bootp on DEChub900 products.