From: Edwards, Andrew M (andrew.m.edwards@boeing.com)
Date: Thu Jan 13 2005 - 20:05:15 GMT-3
Having no personal knowledge of the rest of the lab and its requirements
my thoughts are this:
1. Using a backup interface would ensure that BGP or any other traffic
would not bring up the link unless the interface were truly in a
down/down state. E.G. The interface status is standby until the
primary link is down/down.
- Unless specifically told not to use it, this would be one viable
option.
2. You could also prohibit BGP traffic from being interesting on the
link.
Dialer-list 1 protocol ip list 100
Access-list 100 deny tcp any eq 179 any
Access-list 100 deny tcp any any eq 179
Access-list 100 permit ip any any
Int bri0/0
Dialer-group 1
But again, I don't have this lab scenario so I don't know the rest of
the lab restrictions to give a definitive answer.
Andy
-----Original Message-----
From: ccie2be [mailto:ccie2be@nyc.rr.com]
Sent: Thursday, January 13, 2005 11:04 AM
To: Edwards, Andrew M; joshua lauer
Cc: Group Study
Subject: Re: IE lab 15 - BGP over isdn
Hey Andy,
Thanks for thinking about this and sharing your thoughts.
I had thought of doing something along those lines, but
I ruled that out since the isdn link would still flap although less
often.
But, after seeing your note, I went back to re-read the pertinent
requirements
and maybe I need to re-think what needs to be done.
Here's the actual requirement word for word:
6.5 The isdn link between R4 and R5 will be used primarily as a backup
in the case that
R4 loses its connection to the Frame Relay cloud. Ensure that the isdn
link does not come up
due to R4 trying to initiate a BGP session to R5.
After re-reading this requirement, it clearly doesn't say anything about
the link not flapping, but on the other
hand, it does seem to contradict itself.
If the link is primarily for backup and
if R4 loses it's connection to the F/R cloud,
shouldn't R4 initiate a connection to R5?
Note the following about R4's config:
ei 100 f/r int --> R4 bri0/0 ospf
R4 is also mutually redist ei 100 into ospf and ospf into ei 100.
Q? If R4's f/r connection goes down, doesn't ospf see that as a
topology
change (the ei routes redist into ospf are gone) and thus, because of
the
ospf demand-circuit cause R4 to bring up the isdn link?
Q2? If I prevent R4 from initiating a BGP session with R5 (eg. using an
acl) doesn't
that also stop any BGP session from forming regardless of who initiates
it?
Regardless of what the solution turns out to be, this has certainly been
an interesting
problem.
Thanks again. Tim
----- Original Message -----
From: "Edwards, Andrew M" <andrew.m.edwards@boeing.com>
To: "ccie2be" <ccie2be@nyc.rr.com>; "joshua lauer" <jslauer@hotmail.com>
Cc: "Group Study" <ccielab@groupstudy.com>
Sent: Thursday, January 13, 2005 1:29 PM
Subject: RE: IE lab 15 - BGP over isdn
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