From: Jeff Lodwick (climberartist@xxxxxxxxxxx)
Date: Sun Nov 11 2001 - 17:28:37 GMT-3
Eric and group,
I am aware of BGP's path selection and at first I did configure local
preference on r1 and it worked great. I was just wanting to experiment with
BGP's path selection and that's why I used MED's to see if r1 would use the
MED's since the AS paths are the same and it did show the MED's in the BGP
table for the routes I specified but didn't use it to select the best path.
In all the configurations of BGP I've seen local preference is used for IBGP
and MED's are used for EBGP but I've never read anywhere that you can't use
MED's to manipulate IBGP routes or for the sake of arguement that you can't
use Local Preference to influence or manipulate EBGP routes. From what
Halabi says and a lot of other books I've read say there are 9 steps to
"BGP" path selection. Local preference is 3rd and MED's are 6th right after
AS path and origin. That is the whole reason I'm experimenting with this to
get a better understanding of BGP's path selection process. If anybody has
any insight on this or if I'm wrong please someone let me know.
Thanks,
Jeff
>From: "EA Louie" <elouie@yahoo.com>
>Reply-To: "EA Louie" <elouie@yahoo.com>
>To: "Jeff Lodwick" <climberartist@hotmail.com>, <lalal@163.com>
>CC: <ccielab@groupstudy.com>
>Subject: Re: BGP path selection question
>Date: Sun, 11 Nov 2001 08:41:43 -0800
>
>Whoa... are you aware that local preference takes precedence over MED's
>(metrics) within an iBGP AS? If I remember correctly (IIRC for all you
>acronymophobiacs), MED is an eBGP influencer. If you want to influence
>routing within an iBGP domain, won't you use Local Preference attribute? I
>think it's neat that you're trying it with iBGP, but my understanding is
>that metrics only work in eBGP sessions...
>
>someone correct me if I'm wrong (please)
>
>-e-
>
>----- Original Message -----
>From: "Jeff Lodwick" <climberartist@hotmail.com>
>To: <lalal@163.com>
>Cc: <ccielab@groupstudy.com>
>Sent: Sunday, November 11, 2001 7:41 AM
>Subject: Re: BGP path selection question
>
>
> > That was something that I wasn't sure about. In the past I've only used
> > MED's for EBGP connections but in this scenario I wanted to try it with
>IBGP
> > connections to test out BGP's path selection. When I look in the BGP
>table
> > it shows the MED's on the routes I specified so that's why I figured it
>was
> > working but it seems like there is something else that is affecting
>these
> > routes. Below shows the routes in r1. I did a sh ip bgp before the
>routes
> > from r2 were withdrawn to show they are installed in the bgp table with
>the
> > correct metrics then removed and routes to r5 are installed with the
>correct
> > metrics but the route to 10.1.1.0 still shows with the next hop to r5
>even
> > though it's metric/med is higher then r2. Any ideas?
> >
> > r1#debug ip bgp update
> > BGP updates debugging is on
> > r1#clear ip bgp *
> > r1#
> > 04:20:24: %BGP-5-ADJCHANGE: neighbor 2.2.2.2 Down User reset
> > 04:20:24: %BGP-5-ADJCHANGE: neighbor 5.5.5.5 Down User reset
> > 04:20:53: %BGP-5-ADJCHANGE: neighbor 2.2.2.2 Up
> > 04:20:53: BGP(0): 2.2.2.2 computing updates, afi 0, neighbor version 0,
> > table version 1, starting at 0.0.0.0
> > 04:20:53: BGP(0): 2.2.2.2 update run completed, afi 0, ran for 0ms,
>neighbor
> > version 0, start version 1, throttled to 1
> > 04:20:53: BGP: 2.2.2.2 initial update completed
> > 04:20:53: BGP(0): 2.2.2.2 rcvd UPDATE w/ attr: nexthop 2.2.2.2, origin
>i,
> > localpref 100, path 300 400 400
> > 04:20:53: BGP(0): 2.2.2.2 rcvd 10.1.1.0/24
> > 04:20:53: BGP(0): 2.2.2.2 rcvd 10.2.2.0/24
> > 04:20:53: BGP(0): 2.2.2.2 rcvd UPDATE w/ attr: nexthop 2.2.2.2, origin
>?,
> > localpref 100, path 300 400 400
> > 04:20:53: BGP(0): 2.2.2.2 rcvd 137.5.0.0/24
> > 04:20:53: BGP(0): 2.2.2.2 rcvd 137.20.103.0/24
> > 04:20:53: BGP(0): Revise route installing 10.1.1.0/24 -> 2.2.2.2 to main
>IP
> > table
> > 04:20:53: BGP(0): Revise route installing 10.2.2.0/24 -> 2.2.2.2 to main
>IP
> > table
> > 04:20:53: BGP(0): Revise route installing 137.5.0.0/24 -> 2.2.2.2 to
>main
>IP
> > table
> > 04:20:53: BGP(0): Revise route installing 137.20.103.0/24 -> 2.2.2.2 to
>main
> > IP tablesh ip bgp
> > 04:20:58: BGP(0): 2.2.2.2 computing updates, afi 0, neighbor version 1,
> > table version 5, starting at 0.0.0.0
> > 04:20:58: BGP(0): 2.2.2.2 update run completed, afi 0, ran for 0ms,
>neighbor
> > version 1, start version 5, throttled to 5
> > BGP table version is 5, local router ID is 137.20.1.33
> > 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
> > *>i10.1.1.0/24 2.2.2.2 10 100 0 300 400 400
>i
> > *>i10.2.2.0/24 2.2.2.2 20 100 0 300 400 400
>i
> > *>i137.5.0.0/24 2.2.2.2 20 100 0 300 400 400
>?
> > *>i137.20.103.0/24 2.2.2.2 20 100 0 300 400 400
>?
> > r1#
> > 04:21:09: %BGP-5-ADJCHANGE: neighbor 5.5.5.5 Up
> > 04:21:09: BGP(0): 5.5.5.5 computing updates, afi 0, neighbor version 0,
> > table version 5, starting at 0.0.0.0
> > 04:21:09: BGP(0): 5.5.5.5 NEXT_HOP part 1 net 10.1.1.0/24, next 2.2.2.2
> > 04:21:09: BGP(0): 5.5.5.5 send UPDATE (format) 10.1.1.0/24, next
>2.2.2.2,
> > metric 10, path 300 400 400
> > 04:21:09: BGP(0): 5.5.5.5 NEXT_HOP part 1 net 10.2.2.0/24, next 2.2.2.2
> > 04:21:09: BGP(0): 5.5.5.5 send UPDATE (format) 10.2.2.0/24, next
>2.2.2.2,
> > metric 20, path 300 400 400
> > 04:21:09: BGP(0): 5.5.5.5 NEXT_HOP part 1 net 137.5.0.0/24, next 2.2.2.2
> > 04:21:09: BGP(0): 5.5.5.5 send UPDATE (format) 137.5.0.0/24, next
>2.2.2.2,
> > metric 20, path 300 400 400
> > 04:21:09: BGP(0): 5.5.5.5 NEXT_HOP part 1 net 137.20.103.0/24, next
>2.2.2.2
> > 04:21:09: BGP(0): 5.5.5.5 send UPDATE (format) 137.20.103.0/24, next
> > 2.2.2.2, metric 20, path 300 400 400
> > 04:21:09: BGP(0): 5.5.5.5 4 updates enqueued (average=67, maximum=67)
> > 04:21:09: BGP(0): 5.5.5.5 update run completed, afi 0, ran for 4ms,
>neighbor
> > version 0, start version 5, throttled to 5
> > 04:21:09: BGP: 5.5.5.5 initial update completed
> > 04:21:09: BGP(0): 5.5.5.5 rcvd UPDATE w/ attr: nexthop 5.5.5.5, origin
>i,
> > localpref 100, path (65000) 600 400
> > 04:21:09: BGP(0): 5.5.5.5 rcvd 10.1.1.0/24
> > 04:21:09: BGP(0): 5.5.5.5 rcvd 10.2.2.0/24
> > 04:21:09: BGP(0): 5.5.5.5 rcvd UPDATE w/ attr: nexthop 5.5.5.5, origin
>?,
> > localpref 100, path (65000) 600 400
> > 04:21:09: BGP(0): 5.5.5.5 rcvd 137.5.0.0/24
> > 04:21:09: BGP(0): 5.5.5.5 rcvd 137.20.103.0/24
> > 04:21:09: BGP(0): Revise route installing 10.1.1.0/24 -> 5.5.5.5 to main
>IP
> > table
> > 04:21:09: BGP(0): Revise route installing 10.2.2.0/24 -> 5.5.5.5 to main
>IP
> > table
> > 04:21:09: BGP(0): Revise route installing 137.5.0.0/24 -> 5.5.5.5 to
>main
>IP
> > table
> > 04:21:09: BGP(0): Revise route installing 137.20.103.0/24 -> 5.5.5.5 to
>main
> > IP table
> > 04:21:09: BGP(0): 2.2.2.2 computing updates, afi 0, neighbor version 5,
> > table version 9, starting at 0.0.0.0
> > 04:21:09: BGP(0): 2.2.2.2 NEXT_HOP part 1 net 10.1.1.0/24, next 5.5.5.5
> > 04:21:09: BGP(0): 2.2.2.2 send UPDATE (format) 10.1.1.0/24, next
>5.5.5.5,
> > metric 20, path (65000) 600 400
> > 04:21:09: BGP(0): 2.2.2.2 NEXT_HOP part 1 net 10.2.2.0/24, next 5.5.5.5
> > 04:21:09: BGP(0): 2.2.2.2 send UPDATE (format) 10.2.2.0/24, next
>5.5.5.5,
> > metric 10, path (65000) 600 400
> > 04:21:09: BGP(0): 2.2.2.2 NEXT_HOP part 1 net 137.5.0.0/24, next 5.5.5.5
> > 04:21:09: BGP(0): 2.2.2.2 send UPDATE (format) 137.5.0.0/24, next
>5.5.5.5,
> > metric 20, path (65000) 600 400
> > 04:21:09: BGP(0): 2.2.2.2 NEXT_HOP part 1 net 137.20.103.0/24, next
>5.5.5.5
> > 04:21:09: BGP(0): 2.2.2.2 send UPDATE (prepend, chgflags: 0x208)
> > 137.20.103.0/24, next 5.5.5.5, metric 20, path (65000) 600 400
> > 04:21:09: BGP(0): 2.2.2.2 3 updates enqueued (average=66, maximum=69)
> > 04:21:09: BGP(0): 2.2.2.2 update run completed, afi 0, ran for 4ms,
>neighbor
> > version 5, start version 9, throttled to 9
> > 04:21:10: BGP(0): 2.2.2.2 rcv UPDATE about 10.1.1.0/24 -- withdrawn
> > 04:21:10: BGP(0): 2.2.2.2 rcv UPDATE about 10.2.2.0/24 -- withdrawn
> > 04:21:10: BGP(0): 2.2.2.2 rcv UPDATE about 137.5.0.0/24 -- withdrawn
> > 04:21:10: BGP(0): 2.2.2.2 rcv UPDATE about 137.20.103.0/24 -- withdrawn
> > 04:21:39: BGP(0): 5.5.5.5 computing updates, afi 0, neighbor version 5,
> > table version 9, starting at 0.0.0.0
> > 04:21:39: BGP(0): 5.5.5.5 send unreachable 10.1.1.0/24
> > 04:21:39: BGP(0): 5.5.5.5 send UPDATE 10.1.1.0/24 -- unreachable
> > 04:21:39: BGP(0): 5.5.5.5 send UPDATE 10.2.2.0/24 -- unreachable
> > 04:21:39: BGP(0): 5.5.5.5 send UPDATE 137.5.0.0/24 -- unreachable
> > 04:21:39: BGP(0): 5.5.5.5 send UPDATE 137.20.103.0/24 -- unreachable
> > 04:21:39: BGP(0): 5.5.5.5 1 updates enqueued (average=39, maximum=39)
> > 04:21:39: BGP(0): 5.5.5.5 update run completed, afi 0, ran for 0ms,
>neighbor
> > version 5, start version 9, throttled to 9
> > r1#sh ip bgp
> > BGP table version is 9, local router ID is 137.20.1.33
> > 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
> > *> 10.1.1.0/24 5.5.5.5 20 100 0 (65000) 600
>400
> > i
> > *> 10.2.2.0/24 5.5.5.5 10 100 0 (65000) 600
>400
> > i
> > *> 137.5.0.0/24 5.5.5.5 20 100 0 (65000) 600
>400
> > ?
> > *> 137.20.103.0/24 5.5.5.5 20 100 0 (65000) 600
>400
> > ?
> >
> > Thanks in advance,
> > Jeff
> >
> >
> > >From: "lalal" <lalal@163.com>
> > >To: "Jeff Lodwick" <climberartist@hotmail.com>
> > >Subject: Re: BGP path selection question
> > >Date: Sun, 11 Nov 2001 16:50:35 +0800 (CST)
> > >
> > >i think MED is used in eBGP connection.iBGP just pass it through the
>as,and
> > >so is confederation.
> > >
> > > > Hi group,
> > > > I added a post with the subject "Weird BGP problem/question on BGP
>path
> > > > selection" that ended up being too long after I replied a couple
>times
> > >to
> > > > Eric on the list because of all the configs and debug I included.
>If
> > >you
> > > > would like the configs they are in the post with the subject "Weird
>BGP
> > > > problem/question on BGP path selection" or I can send them again if
> > >someone
> > > > needs them. My problem in a nutshell is with how BGP's path
>selection
> > >is
> > > > working on this lab setup I have. I have 6 routers that all are
>running
> > > > OSPF and no virtual-link problems so that I have simple routes to
>all
> > > > subnets. The only interfaces that aren't in OSPF are 2 loopback
> > >interfaces
> > > > off r4 (10.1.1.0 and 10.2.2.0) which I have redistributed into BGP
> > > > redistribute connected) and advertised through BGP. I have
>communities
> > > > sending med's to r4 so that
> > > > r4 selects certain routes to get to 2 different subnets off r1 and
>it
>is
> > > > working great. R1, r2 and r5 are all in AS 100 with 2 different
> > > > confederation AS's (65000 on r5 and 65001 on r1 and r2). R1 has a
> > >neighbor
> > > > to r2 and r5. R2 has a neighbor to r3 in AS 300 and r5 has
> > > > a neighbor to r6 in AS 600. R3 and r6 both have a neighbor to r4 in
>AS
> > >400.
> > > > With this setup r1 picked the route through r2 as shown in the bgp
>table
> > > > showing 2 AS's through r2 (300 400) and 3 AS's through r5 (65000 600
> > >400) I
> > > > also checked it with a traceroute to verify that was happening. To
>make
> > >it
> > > > so that the AS path was the same I set an
> > > > AS-path prepend on r4 pointing to r3 so that r1 sees both r2 and r5
>with
> > >3
> > > > AS's to pass through and should use the next determination in BGP's
>path
> > > > selection (origin then MED then closest IGP neighbor then BGP router
> > >ID).
> > > > The origin's are both incomplete since they are both redistributed
>into
> > >BGP
> > > > so the next path selection should be the MED. To test this I put a
> > > > route-map on r1 setting metrics to incoming routes from r2 and r5.
>I
> > >set it
> > > > up so that the subnet of 10.1.1.0 has a metric of 10 when coming
>from
>r2
> > >and
> > > > any other routes coming from r2 are set with a metric of 20. I did
>the
> > >same
> > > > thing on r5 with the subnet of 10.2.2.0 having a metric of 10 and
>all
> > >other
> > > > routes a metric of 20. With this setup all of the routes on r1
>learned
> > > > through BGP go through r2 then are withdrawn and then all routes
>learned
> > > > through BGP go through r5. I took off the second statement off of
>both
> > > > route
> > > > maps setting the metric of all other routes to 20 and it works fine.
> > >Routes
> > > > to 10.1.1.1 go through r2 and routes to 10.2.2.2 go through r5 but
>right
> > > > when I add those route maps back specifying all other traffic to a
> > >metric of
> > > > 20 the same thing happens; all of the routes on r1 learned through
>BGP
> > >go
> > > > through r2 then are withdrawn and then all routes learned through
>BGP
>go
> > > > through r5.
> > > >
> > > > Thanks in advance,
> > > > Jeff CCIE bound in 17 days
> > > >
This archive was generated by hypermail 2.1.4 : Fri Jun 21 2002 - 06:45:12 GMT-3