From: Joseph Rothstein (ziutek@mac.com)
Date: Thu Sep 16 2004 - 01:47:43 GMT-3
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/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
>
>_______________________________________________________________________
>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:44 GMT-3