From: Joseph Rothstein (ziutek@mac.com)
Date: Wed Sep 15 2004 - 20:51:18 GMT-3
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