From: Jason Sinclair (sinclairj@xxxxxxxxxxxxxxx)
Date: Thu Nov 01 2001 - 21:10:25 GMT-3
All,,
Also be careful of the trap "make sure route X does not appear in routing
table of routerY, not even via show ip bgp". In this situation if you have
soft-reconfig inbound rules may prevent it from being in the main routing
table, however it may be in the bgp table.
Just a thought.
Regards,
Jason Sinclair
Network Support Manager
POWERTEL Limited
Level 11, 55 Clarence Street, SYDNEY
Phone: 61-2-8264-3820
Fax: 61-2-9279-2604
Mobile: 0416 105 858
jasons@powertel.net.au
-----Original Message-----
From: Brian Hescock [mailto:bhescock@cisco.com]
Sent: Friday, 2 November 2001 08:37
To: McCallum, Robert
Cc: 'Ron Royston'; charlesny2000@yahoo.com;
ccielab@groupstudy.com
Subject: Re: When do you need to "clear ip bgp *"
Soft reconfig out is on by default (at least in later code
it is) but you have to configure soft reconfig in. The drawback to it is it
takes up a *significant* amount of memory because you're duplicating all of
your bgp prefixes prior to filtering, etc. It's applicable when you don't
have access
to the bgp peer, such as an ISP or, if you do have access to
that router but don't want to have to telnet to it and do a clear soft out
for that neighbor, forcing the routes back to the peer. This is something
that's needed when adding / modifying route-map, distribute-lists, etc.
Brian
"McCallum, Robert" wrote:
> 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:00 GMT-3