From: john matijevic (matijevi@bellsouth.net)
Date: Fri Sep 17 2004 - 03:48:23 GMT-3
Hello Joseph,
The lab doesn't want you to advertise these loopbacks in igp, only
create them and advertise them via bgp.
I have successfully reproduced the issue:
R4#sh ip bgp
BGP table version is 3, local router ID is 10.4.4.4
Status codes: s suppressed, d damped, h history, * valid, > best, i -
internal
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
This is like book answer key but I did not put the bandwidth under the
virtual-Template interfaces.
R4#sh ip bgp
BGP table version is 3, local router ID is 10.4.4.4
Status codes: s suppressed, d damped, h history, * valid, > best, i -
internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
* 2.2.2.0/29 10.1.1.1 0 61555 62555
i
*> 10.6.6.6 0 61555 62555
i
Now I put the bandwidth under the virtual-template interfaces.
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
R4#
after changing cost on virtual-template 1 to 600 higher than the
virtual-template2
So it appears that based on the bgp selection algorithm:
10. Prefer the route that can be reached through the closest IGP
neighbor (the lowest IGP metric).
The router will prefer the shortest internal path within the autonomous
system to reach the destination (the shortest path to the BGP next hop).
It appears that ospf is calculating a metric with the bandwidth command
that is internal to the process itself and cant be viewed. But we do
know that ospf uses auto-cost reference-bandwidth/bandwidth = cost.
Because when changing the bandwidth command, when you do a sh ip ospf
interface, the cost still remains the same. It is only when I changed
the cost manually on the interface that I saw the change with ospf
metric. However, both affect the bgp best-path selection algorithm.
Hopefully this has cleared up some confusion regarding the matter.
And the author probably didnt put the bandwidth command earlier so that
led to some confusion. Even though there maybe some errors with the
book, the book is of the highest quality, I certainly learn a lot with
this book!!!. Also keep the discussions on my forum area also with the
issues.
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: Thursday, September 16, 2004 12:48 AM
To: ccielab@groupstudy.com
Subject: RE: BGP reachablilty continued....
Hey John, et al,
See the info on the version below.
After reviewing the scenario requirements, I see now that both R1 and
R6's loopbacks should have been advertised in to OSPF from EIGRP. This
makes the fact that there is different bandwidth on the two links a moot
point.
Thanks for all you in put.
Joe
R4#sh vers
Cisco Internetwork Operating System Software
IOS (tm) C2600 Software (C2600-J1S3-M), Version 12.2(15)T14, RELEASE
SOFTWARE (fc4)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2004 by cisco Systems, Inc.
Compiled Sat 28-Aug-04 06:47 by cmong
Image text-base: 0x80008098, data-base: 0x819608A4
ROM: System Bootstrap, Version 12.2(10r)1, RELEASE SOFTWARE (fc1)
ROM: C2600 Software (C2600-J1S3-M), Version 12.2(15)T14, RELEASE
SOFTWARE (fc4)
R4 uptime is 2 hours, 13 minutes
System returned to ROM by reload
System image file is "flash:c2600-j1s3-mz.122-15.T14.bin"
cisco 2620 (MPC860) processor (revision 0x102) with 53248K/12288K bytes
of memory.
Processor board ID JAB041401RA (1739052506)
M860 processor: part number 0, mask 49
Bridging software.
X.25 software, Version 3.0.0.
TN3270 Emulation software.
Basic Rate ISDN software, Version 1.1.
1 FastEthernet/IEEE 802.3 interface(s)
1 Serial network interface(s)
1 ISDN Basic Rate interface(s)
2 Voice FXS interface(s)
32K bytes of non-volatile configuration memory.
16384K bytes of processor board System flash (Read/Write)
Configuration register is 0x2102
On Thursday, September 16, 2004, at 05:09AM, john matijevic
<matijevi@bellsouth.net> wrote:
>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/122newf
t
>/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
>
>_______________________________________________________________________
>Subscription information may be found at:
>http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
---- Joseph Rothstein Ridlerstr. 32 80339 Munich Germany ziutek@mac.com http://www.geocities.com/jozek444 http://www.rothstein.no-ip.org/ http://waywardgenuses.blogspot.com/ http://ziutek.journalspace.com/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:45 GMT-3