From: Edwards, Andrew M (andrew.m.edwards@boeing.com)
Date: Thu Jan 13 2005 - 15:29:22 GMT-3
Tim,
Just crank your BGP timers keepalive and hold-time up. That will keep
the link from constantly flapping. Note you want to do this on both
sides of the peers so they negotiate the correct values during the
ACTIVE period.
Not sure of the specifics of this lab, but those are my thoughts.
HTH,
andy
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/
fipr_c/ipcprt2/1cfbgp.htm#wp1002274
-----------
Adjusting BGP Timers
BGP uses certain timers to control periodic activities such as the
sending of keepalive messages and the interval after not receiving a
keepalive message after which the Cisco IOS software declares a peer
dead. By default, the keepalive timer is 60 seconds, and the hold-time
timer is 180 seconds.You can adjust these timers. When a connection is
started, BGP will negotiate the hold time with the neighbor. The smaller
of the two hold times will be chosen. The keepalive timer is then set
based on the negotiated hold time and the configured keepalive time.
To adjust BGP timers for all neighbors, use the following command in
router configuration mode:
Command Purpose
Router(config-router)# timers bgp keepalive holdtime
Adjusts BGP timers for all neighbors.
To adjust BTP keepalive and hold-time timers for a specific neighbor,
use the following command in router configuration mode:
Command Purpose
Router(config-router)# neighbor [ip-address | peer-group-name] timers
keepalive holdtime
Sets the keepalive and hold-time timers (in seconds) for the specified
peer or peer group.
------------------------------------------------------------------------
--------
Note The timers configured for a specific neighbor or peer group
override the timers configured for all BGP neighbors using the timers
bgp router configuration command.
------------------------------------------------------------------------
--------
To clear the timers for a BGP neighbor or peer group, use the no form of
the neighbor timers command.
-----Original Message-----
From: ccie2be [mailto:ccie2be@nyc.rr.com]
Sent: Thursday, January 13, 2005 10:03 AM
To: joshua lauer
Cc: Group Study
Subject: Re: IE lab 15 - BGP over isdn
Hey Josh,
I'm already using the loopbacks of R4 and R5 for the bgp peering
session.
The problem (I think) is that per R4's route table, the isdn link is the
best way
to reach R5's loopback and vice versa.
Remember also that the loopbacks of R3, R4 and R5 are advertised into
the ospf
domain and then redist into ei 100.
Once redist into ei 100, the AD is 170 since they are ei 100 external
routes.
Therefore, R4 and R5 prefer to reach each other via the isdn link.
I've tried adjusting the AD of these loopbacks such that R4 and R5
prefer
to reach each other via the f/r pvc between R4 and R3 but so far, no
cigar.
Whta's frustrating is that I'm not sure this is even the right approach.
I also thought of configuring the dialer-list such that bgp traffic is
NOT
interesting but then BGP AS 200 wouldn't be fully meshed if the pvc
between
R3 and R5 goes down or if the pvc between R3 and R4 goes down.
BTW, I also have an ospf demand-circuit configured on R4 and that's
working -
all the ospf adjacencies are established.
Hmmm, it's a dilemma.
But, I'm still open to suggestions.
Thanks, Tim
----- Original Message -----
From: "joshua lauer" <jslauer@hotmail.com>
To: "ccie2be" <ccie2be@nyc.rr.com>
Sent: Thursday, January 13, 2005 12:42 PM
Subject: Re: IE lab 15 - BGP over isdn
> according to the ospf section it appears to me demand circuit would be
> configured. as far as bgp peering, if you peer the loopbacks of R4 and
> R5 together does that keep the link down? those loopbacks are learned
> by the ospf process correct? I wouldnt peer directly over the two
> links with the interface ip's...that would definitely keep it up since
> bgp would require
a
> constant connection via port 179. At first guess, looking at the
> topology, that's what I would do. I dont offhand know of anyway to
> spoof the bgp connection. Since the ospf ISDN link is being spoofed
> already with demand circuit I would think that the loopback peering is
> the way to go. If you lost wan connection between it would cause OSPF
> to recalculate...the loopbacks would always be reachable. and your
> peering would not go down. Also, since your are peering with
> loopbacks, your isdn should never come up..
>
> jl
>
> jl
> Joshua Lauer
>
> RHCE, MCSE, CCNA, CCDA, CCDP, CCNP, CCIP, CCSP,INFOSEC, CEH
>
> ----- Original Message -----
> From: "ccie2be" <ccie2be@nyc.rr.com>
> To: "Group Study" <ccielab@groupstudy.com>
> Sent: Thursday, January 13, 2005 12:19 PM
> Subject: IE lab 15 - BGP over isdn
>
>
> > Hi guys,
> >
> > Is there a method of establishing bgp peering over isdn such that
> >
> > the bgp session doesn't make the isdn circuit flap?
> >
> > Analysis: I'm fairly sure this is because of BGP since I didn't
> > have
this
> >
> > problem prior to configuring the BGP peering between R4 and R5 but I
> > haven't figured
> >
> > out how to prove that BGP is the cause. A show dialer only shows
> > the cause as a packet
> >
> > to R5.
> >
> > I'm thinking that since R4 and R5 are ibgp peering via loopbacks,
> > one
> >
> > possible way to solve this flapping problem is to make R4 and R5
> >
> > prefer to reach each other's loopback via the eigrp link
> >
> > between R4 and R3 instead of via ospf over the isdn link. I've been
> > playing
> >
> > around with the distance command to do this but so far, no success.
> >
> > Has anyone else have this problem and figure out a way to solve it?
> >
> > Unfortunately, neither the SG or the forum offers any help on this.
> >
> > TIA, Tim
> >
> > ____________________________________________________________________
> > ___
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Wed Feb 02 2005 - 22:10:22 GMT-3