From: Daniel C. Young (ccie7999@xxxxxxxxx)
Date: Tue Nov 06 2001 - 04:10:31 GMT-3
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 : Fri Jun 21 2002 - 06:45:05 GMT-3