OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: Anton Smirnov (asmirnovCISCO.COM)
Date: Sat Jun 01 2002 - 16:43:53 CDT

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

       Mitchel,
       there must be several conditions met for platform to benefit from DR
    offload:
    - <Router> (in broad sense of the word) must have many interfaces, dozens if
    not hundreds
    - These interfaces must be OSPF broadcast/NBMA (because there is no DR on
    ptp links)
    - On each interface more than one neighbor should be present. This rule is
    because otherwise interfaces should be converted - manually or somehow
    automatically - to ptp. Thus dozens of apparently needless Net LSAs will be
    eliminated from LSDB, having other benefits (less flooding and simpler SPF
    in the area)
    - Set of routers on each interface should be different. If same routers are
    neighboring thru dozens of transit interfaces then one must think about
    reasonable network design, right?

       I can't think of any widely accepted industry solution matching all these
    requirements. Access solutions tend to have ptp links, whatever L2 method is
    employed. Layer 3 switches come closest to matching all these conditions but
    it is because last rule usually neglected. On L3 switches all interfaces (or
    vlans) where end clients are connected may and should be configured as stub
    networks, not transit.
       Then I just do not see a case where DR offload may be beneficial. That
    was my point.

       Of course, there always exist freaks who for very specific reasons want
    to do something unusual. But these freaks can manually play with OSPF
    priorities on interfaces of routers.

    Anton

    ----- Original Message -----
    From: "Erblichs" <erblichsEARTHLINK.NET>
    To: <OSPFDISCUSS.MICROSOFT.COM>
    Sent: Saturday, June 01, 2002 9:52 PM
    Subject: Re: [OSPF] Dynamic Priority setting for DR election

    > Anton,
    >
    > This was a request to investigate this functionality.
    >
    > My assumption is that if the router architecture supports
    > MANY DR capable interfaces, then they would like to
    > have different routers willing to over-ride other
    > configured priority values..
    >
    > So, they don't have to set a fixed priority value per
    > interface and not be sure that the router will be the
    > DR. They don't have to set the highest value. After
    > the router is elected DR. They only have to execute
    > a CLI to determine what is the current priority that
    > the router selected per interface.
    >
    > Simply, this is a administration issue.
    >
    > And, if I understand your resource statement correctly,
    > then I would have to disagree. A one item example..
    > After a DR is elected,
    > this router would then have to sychronize its database
    > with all DRothers.. The time to do this is mostly dependent
    > on the number of capable simultaneous adj formations
    > without overload..
    > And of course, their is a overload draft that
    > suggests to limit this simultaneous adjs to a known
    > acceptable value. This value is dependent on the
    > capabilities of the router..
    >
    > Mitchell Erblich
    > PS: And if anyone was wondering, the hello interval
    > and the ROUTERDEADINTERVAL could also be read from
    > recieved hellos. Again, this could lead to less required
    > configuration to establish 2-ways.
    > ========================
    >
    >
    >
    >
    > Anton Smirnov wrote:
    > >
    > > Mitchell,
    > > I don't think DR's responsibilities have big impact on resources of
    > > <router>, especially if any technique to optimize flooding over parallel
    > > links has been implemented. Thus dynamic priority change looks like
    bringing
    > > problems rather than solving them...
    > >
    > > Anton
    > >
    > > ----- Original Message -----
    > > From: "Manral, Vishwas" <VishwasMNETPLANE.COM>
    > > To: <OSPFDISCUSS.MICROSOFT.COM>
    > > Sent: Saturday, June 01, 2002 2:25 PM
    > > Subject: Re: [OSPF] Dynamic Priority setting for DR election
    > >
    > > > Hi Mitchell,
    > > >
    > > > I do not know your exact intent and what you want to achieve here, but
    > > this
    > > > method would not be backward compatible with the existing methods. For
    a
    > > > method to be useful, its extremely important it is able to
    interoperate
    > > with
    > > > existing methods.
    > > >
    > > > I dont know of anything like this having been proposed in any draft in
    the
    > > > recent past.
    > > >
    > > > However I guess there are some implementations in ISIS which flip up
    the
    > > > priority of the DIS(DR) so as to prevent frequent changes of the
    DIS(as
    > > has
    > > > been pointed out earlier in the list). I do not know of any dynamic
    > > > selection of priority though.
    > > >
    > > > Thanks,
    > > > Vishwas
    > > >
    > > >
    > > > -----Original Message-----
    > > > From: Erblichs [mailto:erblichsEARTHLINK.NET]
    > > > Sent: Saturday, June 01, 2002 4:31 AM
    > > > To: OSPFDISCUSS.MICROSOFT.COM
    > > > Subject: Dynamic Priority setting for DR election
    > > >
    > > >
    > > > Hi Group,
    > > >
    > > > Has anyone heard of a router's priority selection based
    > > > based on incoming values of the hello packet's priority
    > > > field?
    > > >
    > > > Would their be an experimental draft during the past
    > > > years that explictly or implicitly state this type
    > > > of feature?
    > > >
    > > > Basicly
    > > >
    > > > 0) Assuming that a DR and BDR were not already
    > > > elected.
    > > >
    > > > 1) delaying hello xmits during bootup for
    > > > a period not to exceed or equal waittime,
    > > >
    > > > 2) Identifing a max of the priorities per
    > > > DR capable interface,
    > > >
    > > > 3) Then transmitting hello packets with a higher
    > > > priority than the calculated max and dynamically
    > > > setting that value..
    > > >
    > > > This would make it the DR, unless another
    > > > router's priority was set to the max..
    > > >
    > > > Yes, I believe this would be a non-standard functionality,
    > > > and should require the formal setting of a CLI command
    > > > to enable this type of feature.
    > > >
    > > > And yes, their could be issues with two or more
    > > > routers configured this way.
    > > >
    > > > Mitchell Erblich
    > > >
    >