From: Jeff Lodwick (climberartist@xxxxxxxxxxx)
Date: Sun Nov 11 2001 - 21:10:45 GMT-3
Cool thanks Bill I think I found my answer in that pdf. The 6th step in
BGP's path selection for the MEDs is only compared if "the first
(neighboring) AS is the same in the two paths; any confederation sub-ASs are
ignored. In other words, MEDs are compared only if the first AS in the
AS_SEQUENCE is the same for multiple paths. Any preceding
AS_CONFED_SEQUENCE is ignored." From what I gathered from that I have that
problem since r3 is neighboring with AS 300 and r5 is neighboring with AS
600 which are not the same neighboring AS's. Please somebody correct me if
I interpreted this wrong. Good luck with your test Bill. Let me know how
it goes.
Thanks,
Jeff
>From: "Bill Parenteau" <twparenteau@mailbag.com>
>To: "'Jeff Lodwick'" <climberartist@hotmail.com>
>Subject: RE: BGP path selection question
>Date: Sun, 11 Nov 2001 17:27:01 -0600
>
>Jeff,
> I'm not sure if this will help or if it's in the Halabi book, but I
>found a Bestpath list on CCO. One problem I had was if the IGP RID and
>the BGP RID are different, the router will not install the routes.
>BTW, I took the Caslow class with you. I've got my exam this Wednesday
>in Halifax.
>
>Bill Parenteau
>
>-----Original Message-----
>From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
>Jeff Lodwick
>Sent: Sunday, November 11, 2001 2:29 PM
>To: elouie@yahoo.com
>Cc: ccielab@groupstudy.com
>Subject: Re: BGP path selection question
>
>
>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