From: Jeff Farley (jfarley202@comcast.net)
Date: Mon Sep 20 2004 - 22:54:48 GMT-3
John
I not trying to prove you wrong but observe the behavior below
1. sh ip bgp show the metric to 2.2.2.2 is the same so bandwidth command
is not a issue .
r4#sh ip bgp 2.2.2.2
BGP routing table entry for 2.2.2.0/29, version 9
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
2.Watch what happens when I clear ospf and bgp sessions
r4#clear ip ospf proces
Reset ALL OSPF processes? [no]: yes
1w6d: %OSPF-5-ADJCHG: Process 30, Nbr 10.6.6.6 on Virtual-Access2 from
FULL to D
OWN, Neighbor Down: Interface down or detached
1w6d: %OSPF-5-ADJCHG: Process 30, Nbr 10.1.1.1 on Virtual-Access1 from
FULL to D
OWN, Neighbor Down: Interface down or detached
1w6d: %OSPF-5-ADJCHG: Process 30, Nbr 10.1.1.1 on BRI0 from FULL to
DOWN, Neighb
or Down: Interface down or detached
1w6d: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
1w6d: %LINK-3-UPDOWN: Interface BRI0:2, changed state to up
r4#clea
1w6d: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 1111
r4#clear
1w6d: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed
state to u
p
1w6d: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:2, changed
state to u
p
1w6d: %OSPF-5-ADJCHG: Process 30, Nbr 10.6.6.6 on Virtual-Access2 from
LOADING t
o FULL, Loading Done
r4#clear ip bgp *
r4#
1w6d: %ISDN-6-CONNECT: Interface BRI0:2 is now connected to 1111 r1
r4#
1w6d: %BGP-5-ADJCHANGE: neighbor 10.1.1.1 Down User reset
1w6d: %BGP-5-ADJCHANGE: neighbor 10.6.6.6 Down User reset
1w6d: %OSPF-5-ADJCHG: Process 30, Nbr 10.1.1.1 on Virtual-Access1 from
LOADING t
o FULL, Loading Done
1w6d: %OSPF-5-ADJCHG: Process 30, Nbr 10.1.1.1 on BRI0 from LOADING to
FULL, Loa
ding Done
3. Look at which session came up first
r4#
1w6d: %BGP-5-ADJCHANGE: neighbor 10.1.1.1 Up
r4#
1w6d: %BGP-5-ADJCHANGE: neighbor 10.6.6.6 Up
r4#sh ip bgp 2.2.2.2
BGP routing table entry for 2.2.2.0/29, version 3
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Flag: 0x208
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
4. Watch what happens when I clear r6 first then r1
r4#clear ip bgp 10.6.6.6
r4#
1w6d: %BGP-5-ADJCHANGE: neighbor 10.6.6.6 Down User reset
r4#clear ip bgp 10.1.1.1
r4#
1w6d: %BGP-5-ADJCHANGE: neighbor 10.1.1.1 Down User reset
r4#
1w6d: %BGP-5-ADJCHANGE: neighbor 10.6.6.6 Up
r4#sh ip bgp 2.2.2.2
BGP routing table entry for 2.2.2.0/29, version 13
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x208
Not advertised to any peer
61555 62555
10.6.6.6 (metric 4000) from 10.6.6.6 (10.200.200.5)
Origin IGP, localpref 100, valid, external, best
r4#
1w6d: %ISDN-6-DISCONNECT: Interface BRI0:1 disconnected from 1111 r1,
call last
ed 128 seconds
r4#
1w6d: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down
1w6d: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed
state to d
own
r4#
1w6d: %BGP-5-ADJCHANGE: neighbor 10.1.1.1 Up
5. Notice r6 is the first session up and the best path
r4#sh ip bgp 2.2.2.2
BGP routing table entry for 2.2.2.0/29, version 13
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Flag: 0x208
Not advertised to any peer
61555 62555
10.1.1.1 (metric 4000) from 10.1.1.1 (10.1.1.1)
Origin IGP, localpref 100, valid, external
61555 62555
10.6.6.6 (metric 4000) from 10.6.6.6 (10.200.200.5)
Origin IGP, localpref 100, valid, external, best
6. Look what happens when I clear 10.6.6.6
r4#clear ip bgp 10.6.6.6
1w6d: %BGP-5-ADJCHANGE: neighbor 10.6.6.6 Down User reset
r4#sh ip bgp 2.2.2.2
BGP routing table entry for 2.2.2.0/29, version 18
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x608
Advertised to peer-groups:
61555
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#
1w6d: %BGP-5-ADJCHANGE: neighbor 10.6.6.6 Up
r4#sh ip bgp 2.2.2.2
BGP routing table entry for 2.2.2.0/29, version 18
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Flag: 0x608
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
John
I checked the archives but I was not satisfied with the answer here's
what I got when I reproduced the issue.
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
john matijevic
Sent: Monday, September 20, 2004 2:33 PM
To: Jongsoo.Kim@Intelsat.com; jfarley202@comcast.net; ziutek@mac.com;
ccielab@groupstudy.com
Subject: RE: BGP reachability issues Lab 2 Cisco Press
Hello Jongsoo,
Please search the archives; the uptime has nothing to do with the issue
we discussed about earlier. The issue has already been discussed and has
already since been resolved.
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: Jongsoo.Kim@Intelsat.com [mailto:Jongsoo.Kim@Intelsat.com]
Sent: Monday, September 20, 2004 2:27 PM
To: matijevi@bellsouth.net; jfarley202@comcast.net; ziutek@mac.com;
Subject: RE: BGP reachability issues Lab 2 Cisco Press
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_note09186a0
0800
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
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