From: john matijevic (matijevi@bellsouth.net)
Date: Thu Sep 16 2004 - 00:09:11 GMT-3
Hello Joseph,
I can recall doing this lab and I did recall getting the same bgp table
as the author with the bandwidth commands set. I will have to re-lab
this up and see if I can reproduce. Also, with the command you specify:
"I have taken the next-hop-unchanged off of R6 (which by the way does
not show up in the sh run, IOS 12.2(15)T14)"
I don't see this specific version listed under the new feature
documentation.
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft
/122t/index.htm
Are you sure this version is correct: IOS 12.2(15)T14)?
If not could you tell us the exact version.
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
Joseph Rothstein
Sent: Wednesday, September 15, 2004 7:51 PM
To: ccielab@groupstudy.com
Subject: Re: BGP reachablilty continued....
Good morning (at least that's what it is in Munich 2am),
This is from R4 as solved (changing the next-hop behavior on R6):
R4#sh ip bgp 2.2.2.0
BGP routing table entry for 2.2.2.0/29, version 2
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Advertised to peer-groups:
PEER
61555 62555
10.90.90.1 (metric 4000) from 10.6.6.6 (10.6.6.6)
Origin IGP, localpref 100, valid, external
61555 62555
10.1.1.1 (metric 391) from 10.1.1.1 (10.1.1.1)
Origin IGP, localpref 100, valid, external, best
10.90.90.1 is learned through redistribution from EIGRP on R1. So the
path from R6 to 10.90.90.1 is still through R4.
I have taken the next-hop-unchanged off of R6 (which by the way does not
show up in the sh run, IOS 12.2(15)T14), and cleared the peering, and
this is what I get:
R1#sh ip ro 10.90.90.1
Routing entry for 10.90.90.0/28
Known via "connected", distance 0, metric 0 (connected, via interface)
Redistributing via eigrp 30, ospf 30
Advertised by ospf 30
Routing Descriptor Blocks:
* directly connected, via Serial0/1
Route metric is 0, traffic share count is 1
R1#sipb 2.2.2.0
BGP routing table entry for 2.2.2.0/29, version 2
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
10.4.4.4 10.6.6.6 10.8.8.8
62555
10.90.90.1 from 10.90.90.1 (2.2.2.2)
Origin IGP, metric 0, localpref 100, valid, external, best
R4#sh ip ro 10.90.90.1
Routing entry for 10.90.90.0/28
Known via "ospf 30", distance 110, metric 4000
Tag 3333, type extern 2, forward metric 390
Last update from 10.100.100.1 on Virtual-Access1, 00:17:30 ago
Routing Descriptor Blocks:
* 10.100.100.1, from 10.1.1.1, 00:17:30 ago, via Virtual-Access1
Route metric is 4000, traffic share count is 1
R4#sh ip bgp 2.2.2.0
BGP routing table entry for 2.2.2.0/29, version 2
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Advertised to peer-groups:
PEER
61555 62555
10.1.1.1 (metric 391) from 10.1.1.1 (10.1.1.1)
Origin IGP, localpref 100, valid, external
61555 62555
10.6.6.6 (metric 196) from 10.6.6.6 (10.6.6.6)
Origin IGP, localpref 100, valid, external, best
Correct selection, according to lowest IGP metric, Criteria 10, best
path selection list
R6#sh ip ro 10.90.90.1
Routing entry for 10.90.90.0/28
Known via "ospf 30", distance 110, metric 4000
Tag 3333, type extern 2, forward metric 585
Redistributing via eigrp 20
Advertised by eigrp 20 route-map EGRIP_30_TAG
Last update from 10.100.101.1 on Virtual-Access1, 00:17:41 ago
Routing Descriptor Blocks:
* 10.100.101.1, from 10.1.1.1, 00:17:41 ago, via Virtual-Access1
Route metric is 4000, traffic share count is 1
R6#sipb 2.2.2.0
BGP routing table entry for 2.2.2.0/29, version 2
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
10.4.4.4 10.5.5.5 10.8.8.8
62555
10.90.90.1 (metric 4000) from 10.1.1.1 (10.1.1.1)
Origin IGP, metric 0, localpref 100, valid, internal, best
I have of course been paying with the bandwidth, seeing how this effects
the BGP path selection, and it appears to be workign the way it should.
For example if I make the bandwidth on the two paths from R4 to R1 and
R4 to R6 equal, then R4 will prefer the lower +BGP ID, 10.1.1.1 (R1).
But this still does not solve the problem of a BGP loop, because in this
case, the loop is for the 8.8.8.0 netowrk. R4 prefers R1 to this
network, and R1 prefers R4 to this network. But this problem is
apprarently addressed in the following tasks in this section, although
the author does not touch on the reason why. I still am at a loss as to
how the author comes up with his BGP table on pg. 117 unless he did not
change the bandwidth of the links as per the requirement on page 77.
Regards to all,
Joe
This archive was generated by hypermail 2.1.4 : Fri Oct 01 2004 - 15:00:44 GMT-3