From: john matijevic (matijevi@bellsouth.net)
Date: Fri Sep 17 2004 - 10:24:30 GMT-3
Hello Joseph,
The main issue here that hopefully learned is how the bandwidth command
on the interface affects the OSPF metric, which in turn affects the BGP
best-path algorithm, as I described earlier. You are correct in that if
the igp metric is the same, than it will fall down to the last step in
the bgp best-path selection algorithm with the router-id as I had
demonstrated earlier. Be sure to check my forum area on Lab 3 after you
complete the lab, and post there was well for any issues that you
encounter.
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
Joe Rothstein
Sent: Friday, September 17, 2004 4:19 AM
To: ccielab@groupstudy.com
Subject: Re: BGP reachablilty continued....
Hey John,
The loopbacks that i was referring to are the loopbacks on R1 and R6
that you use for BGP peering, not the ones advertised in BGP.
I did not read the requirements carefully enough (again), and
advertised these loopbacks via OSPF. It clearly states that these
loopbacks should be advertised in EIGRP. they are then redistributed
into OSPF, as E2. The author has them both redistributed into OSPF on
R1 and R6 respectively with a metric of 4000. If the metrics are equal,
then the path selection goes to 12, and the lower IP address rules,
making R4 prefer 10.1.1.1 instead of 10.6.6.6.
On to Lab 3.
Regards to all,
Joe
On Friday, Sep 17, 2004, at 08:48 Europe/Berlin, john matijevic wrote:
> 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
>>
>>
This archive was generated by hypermail 2.1.4 : Fri Oct 01 2004 - 15:00:45 GMT-3