From: jonatale@xxxxxxxxxxxxx
Date: Thu Dec 20 2001 - 04:08:18 GMT-3
what about the new BGP option for ~= request update??? Cisco had it on by def.
at (12.0.6???) (my GATED did not like it), had to get a back door command to
turn it off..
Daniel C. Young wrote:
> Ditto on the memory requirement. On weak routers like the 2500 with low
> memory, you can crash the router, which consumes even more precious time.
>
> In theory, you should never need to do a hard reset on a peer connection.
> Outbound policy modifications can be reflected via an outbound soft reset,
> and an inbound policy modification can be implemented via an inbound soft
> reset. Experience tells me that this works about 80% of the time. The
> remaining 20% require a hard reset, particularly with the tasks that the
> CCIE lab tries you to do. Also, older codes tend to responde more poorly to
> the soft reset commands.
>
> In general, new network advertisement related commands need no resetting.
> Commands that affect policy such as route-maps, communities and other
> filters require at least soft resets. Hard resets are needed usually for
> non-filtering policy changes.
>
> If you really want to figure out which works best with which method, test
> them out yourself.
>
> Hope that helps,
> Daniel
>
> ----- Original Message -----
> From: "McCallum, Robert" <Robert.McCallum@let-it-be-thus.com>
> To: "'Ron Royston'" <ccie6824@hotmail.com>; <charlesny2000@yahoo.com>;
> <ccielab@groupstudy.com>
> Sent: Friday, November 02, 2001 6:04 AM
> Subject: RE: When do you need to "clear ip bgp *"
>
> > As of I think 12.1 soft-reconfiguration is on by default. This means that
> you should "never" have to do a clear ip bgp *. Also, with this command
> enabled it allows you to do things like show ip ospf neigh 150.10.1.1
> received-routes and advertised-routes. Very useful in the lab. I would
> always
> > use this as doing clear ip bgp * wastes far too much time, something which
> we have very little of.
> >
> > HTH
> >
> > -----Original Message-----
> > From: Ron Royston [mailto:ccie6824@hotmail.com]
> > Sent: 01 November 2001 20:40
> > To: charlesny2000@yahoo.com; ccielab@groupstudy.com
> > Subject: Re: When do you need to "clear ip bgp *"
> >
> >
> > You could use the soft-reconfiguration option to implement all of the BGP
> > policies and options that you listed, but I don't believe that this
> > soft-reconfiguration option is going to be any faster than clear ip bgp *.
> > I'd stick with the clear ip bgp *. When you issue the command, go to
> > something else for a minute. Try and keep things as simple and intuitive
> as
> > possible, in my opinion.
> >
> > <><><><><><><><><><><><><>
> > Ron Royston
> > Avnet Enterprise Solutions
> > http://www.nsd.avnet.com/
> >
> >
> >
> > >From: Charles Huang <charlesny2000@yahoo.com>
> > >Reply-To: Charles Huang <charlesny2000@yahoo.com>
> > >To: ccielab@groupstudy.com
> > >Subject: When do you need to "clear ip bgp *"
> > >Date: Thu, 1 Nov 2001 12:22:39 -0800 (PST)
> > >
> > >Hi,
> > >
> > >It takes at least 30 seconds to bring back a BGP peer
> > >and we don't have much time in the real lab to keep on
> > >bouncing the peers when ever we change a command.
> > >Does anyone know which of the following commands
> > >require to bounce the BGP peer in order to take affect
> > >of the new commands entered ? with
> > >"soft-reconfiguration inbound" statement which of the
> > >following commands still require to bounce the peers ?
> > >
> > >
> > >aggregate-address
> > >auto-summary
> > >bgp always-compare-med
> > >bgp bestpath as-path ignore
> > >bgp bestpath compare-routerid
> > >bgp bestpath med confed
> > >bgp bestpath med missing-as-worst
> > >bgp client-to-client reflection
> > >bgp cluster-id
> > >bgp dampening
> > >bgp default local-preference
> > >bgp deterministic med
> > >bgp fast-external-fallover
> > >bgp router-id
> > >default-information originate
> > >default-metric
> > >neighbor advertisement-interval
> > >neighbor advertise-map non-exist-map
> > >neighbor default-originate
> > >neighbor distribute-list
> > >neighbor filter-list
> > >neighbor maximum-prefix
> > >neighbor next-hop-self
> > >neighbor password
> > >neighbor prefix-list
> > >neighbor remote-as
> > >neighbor remove-private-as
> > >neighbor route-map
> > >neighbor route-reflector-client
> > >neighbor send-community
> > >neighbor timers
> > >neighbor update-source
> > >neighbor version
> > >neighbor weight
> > >network
> > >network backdoor
> > >network weight
> > >
> > >
> > >Thanks for any help!!!
> > >
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:32:45 GMT-3