From: Jongsoo.Kim@Intelsat.com
Date: Mon Sep 20 2004 - 15:27:09 GMT-3
It indicates clearly bgp uptime will be tie breaker When both paths are
external, which is the case in this lab ( R1 and R6 announce the 2.2.2.2/28
to R4 via EBGP). So as Jeff mentioned, if we reset BGP session between R6
and R4, then R4 will choose R1 so loop will be gone as well. I think this
tie breaking is only cisco thing nothing to do with BGP standard
From
http://www.cisco.com/en/US/tech/tk365/tk80/technologies_tech_note09186a00800
94431.shtml
Step 10
When both paths are external, prefer the path that was received first (the
oldest one). This step minimizes route-flap, since a newer path will not
displace an older one, even if it would be the preferred route based on the
next decision criteria (Steps 11, 12, and 13).
Skip this step if any of the following is true:
The bgp best path compare-routerid command is enabled.
Note: This command was introduced in Cisco IOS(r) Software Releases
12.0.11S, 12.0.11SC, 12.0.11S3, 12.1.3, 12.1.3AA, 12.1.3.T, and 12.1.3.E.
The router ID is the same for multiple paths, since the routes were received
from the same router.
There is no current best path. An example of losing the current best path
occurs when the neighbor offering the path goes down.
-----Original Message-----
From: john matijevic [mailto:matijevi@bellsouth.net]
Sent: Monday, 20 September, 2004 11:18 AM
To: 'Jeff Farley'; 'Joseph Rothstein'; ccielab@groupstudy.com
Subject: RE: BGP reachability issues Lab 2 Cisco Press
Hello Jeff,
This issue has nothing to do with the BGP uptime, I have already
discussed this but the issue has to do with the igp metric, in this case
it was the bandwidth that was being modified on the lab. Please see
archives for resolution.
Sincerely,
John Matijevic, CCIE #13254, MCSE, CNE, CCEA
CEO
IgorTek Inc.
151 Crandon Blvd. #402
Key Biscayne, FL 33149
Hablo Espanol
305-321-6232
http://home.bellsouth.net/p/PWP-CCIE
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Jeff Farley
Sent: Monday, September 20, 2004 7:00 AM
To: 'Joseph Rothstein'; ccielab@groupstudy.com
Subject: RE: BGP reachability issues Lab 2 Cisco Press
Joseph
I also seen this issue, the problem is in the BGP decision process if
you look at 1 thru 9 all are the same except router id which should make
r1 win the tie. But between 8 & 9 there is also another tie breaker in
later code which is bgp uptime. I found clearing the bgp session to r6
from r4 corrected this problem
r4#sh ip bgp 2.2.2.2
BGP routing table entry for 2.2.2.0/29, version 27
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Advertised to peer-groups:
61555
61555 62555
10.6.6.6 (metric 4000) from 10.6.6.6 (10.200.200.5)
Origin IGP, localpref 100, valid, external
61555 62555
10.1.1.1 (metric 4000) from 10.1.1.1 (10.1.1.1)
Origin IGP, localpref 100, valid, external, best
r4#sh ip bgp sum
BGP router identifier 10.4.4.4, local AS number 60555
BGP table version is 29, main routing table version 29
5 network entries using 485 bytes of memory
9 path entries using 324 bytes of memory
7 BGP path attribute entries using 420 bytes of memory
4 BGP AS-PATH entries using 96 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 1325 total bytes of memory
BGP activity 10/5 prefixes, 23/14 paths, scan interval 60 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down
State/PfxRcd
10.1.1.1 4 61555 12770 12763 29 0 0 6d05h
4
10.6.6.6 4 61555 12253 12268 29 0 0 1d05h
4
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Joseph Rothstein
Sent: Tuesday, September 14, 2004 11:19 PM
To: ccielab@groupstudy.com
Subject: BGP reachability issues Lab 2 Cisco Press
Greetings to all.
Has anyone else had reachability issues with the BGP part of Lab 2 int
eh new Cisco Press book? I ahve a strange situation on R4 which prevents
pinging the loopback 2.2.2.2 on R2:
R4#sipb
BGP table version is 5, local router ID is 10.4.4.4
Status codes: s suppressed, d damped, h history, * valid, > best, i -
internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 2.2.2.0/29 10.6.6.6 0 61555 62555
i
* 10.1.1.1 0 61555 62555
i
*> 4.4.4.0/24 0.0.0.0 0 32768 i
*> 5.5.5.0/27 10.6.6.6 0 61555 64555
i
* 10.1.1.1 0 61555 64555
i
*> 8.8.8.0/28 10.6.6.6 0 61555 63555
i
* 10.1.1.1 0 61555 63555
i
This basically causes packets to bounce back and forth between R6 and R4
since R6's BGP table uses 10.90.90.1 as it's next hop for 2.2.2.2, which
goes through R4. So once the packet gets to R4 on its way to 10.90.90.1,
it just goes right back to R6.
This seems like a pretty big problem, although the text does not state
that IP addresses under BGP have to be reachable.
Did anyone else run into this little problem?
Joe
There is more to life than increasing its speed. - Mahatma Ghandi
This archive was generated by hypermail 2.1.4 : Fri Oct 01 2004 - 15:00:46 GMT-3