From: EA Louie (elouie@xxxxxxxxx)
Date: Sun Nov 11 2001 - 13:41:43 GMT-3
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