From: EA Louie (elouie@xxxxxxxxx)
Date: Mon Jan 07 2002 - 05:13:02 GMT-3
Tony - yes I did. Notes in-line
----- Original Message -----
From: "Tony Hanks" <jhconsulting2001@yahoo.com>
To: "EA Louie" <elouie@yahoo.com>
Cc: "Groupstudy" <ccielab@groupstudy.com>
Sent: Monday, January 07, 2002 1:54 AM
Subject: RE: BGP and IGP redistribution - ccbootcamp8
> EA,
>
> dude, did you ever get this resolved? I used R1 as the Route-reflector
and
> have tried redistributing BGP into OSPF first on R1, then on R6. I think
> the routes BGP validated as best was like 2 to 3 routes when
redistribution
> took place on R1. It looked fine when it's configured on R6, and hence
AS1
> (R8) gets the routes that it needs from OSPF...
>
It looks fine until you check the routes on R2. If you compare the RT and
BGP tables there, you discover that the BGP routes are not making it into
the routing table UNTIL you do one of two things:
1) no sync on R2 (which is allowed at the end of Part A of the exercise),
or
2) make the BGP RID on R1 the same as the OSPF RID on R5 (artifact of an old
RFC requiring BGP RIDs to be in sync with OSPF RIDs - in the past few weeks,
you've probably seen Peter Van Oene gripe about us trying to 'solve' that
problem)
> Also, what about the BGP route that originates from AS3 (R7)? I can't get
> the 172.168.70.0/24 route in the R6's BGP table to show as validated.
> Hence, AS1 (R8) can never get that route. In the answers, R8's routing
> table doesn't include this route, while the question (task 2, item 19)
> states that R7 & R8 should receive both the 172.168.70.0/24 &
> 172.168.80.0/24 routes. Can you tell me what you did and whether you got
> the 172.168.70.0 route over to R8? Thanks in advance!
I do get 172.168.80.0 on R7 in the IP RT and BGP table, and 172.168.70.0 in
the BGP table on R8: I don't know if it's right, but it worked...I *think*
there was a next-hop issue with R7's routes going to R8 that I *think* I had
to fix on R6. Hard to remember - it was more than a week ago ;-)
R8#sh ip bgp
BGP table version is 7904, local router ID is 172.168.80.1
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
*> 0.0.0.0 137.20.86.2 0 2 i
*> 137.20.10.0/24 137.20.86.2 27 0 2 ?
*> 137.20.20.0/24 137.20.86.2 80 0 2 ?
*> 137.20.25.0/24 137.20.86.2 7 0 2 ?
*> 137.20.33.17/32 137.20.86.2 71 0 2 ?
*> 137.20.33.33/32 137.20.86.2 71 0 2 ?
*> 137.20.48.0/20 137.20.86.2 0 0 2 ?
*> 137.20.64.0/20 137.20.86.2 0 0 2 ?
*> 137.20.81.0/24 0.0.0.0 0 32768 i
*> 137.20.82.0/24 0.0.0.0 0 32768 i
*> 137.20.100.32/27 137.20.86.2 6 0 2 ?
*> 137.20.100.33/32 137.20.86.2 70 0 2 ?
*> 137.20.100.34/32 137.20.86.2 134 0 2 ?
*> 137.20.100.35/32 137.20.86.2 198 0 2 ?
*> 137.20.240.0/20 137.20.86.2 7 0 2 ?
*> 160.10.10.0/24 137.20.86.2 0 2 3 i
*> 161.10.10.0/24 137.20.86.2 0 2 3 i
*> 170.10.10.0/24 137.20.86.2 0 2 3 i
Network Next Hop Metric LocPrf Weight Path
*> 172.168.70.0/24 137.20.86.2 0 2 3 i
*> 172.168.80.0/24 0.0.0.0 0 32768 i
*> 200.200.100.0 137.20.86.2 71 0 2 ?
*> 200.200.200.0 137.20.86.2 8 0 2 ?
R8#sh ip bgp 172.168.70.0
BGP routing table entry for 172.168.70.0/24, version 7904
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Not advertised to any peer
2 3
137.20.86.2 from 137.20.86.2 (137.20.60.1)
Origin IGP, localpref 100, valid, external, best
R8#
>
> Tony Hanks
> MCSE+I, CCNP
> Network Infrastructure Engineer
> J & H Consulting Inc.
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
> EA Louie
> Sent: Thursday, December 27, 2001 10:18 AM
> To: ccielab@groupstudy.com
> Subject: Re: BGP and IGP redistribution - ccbootcamp8
>
>
> Here are the conditions:
> route reflection where the router reflector is not synced, but the 2
clients
> are synced
>
> when IGP->BGP redist is peformed at the route reflector, the two clients
get
> the bgp routes, but any routes that are not directly connected show up as
> not sync'ed, and therefore not advertised to eBGP peers.
>
> when IBP->BGP redist is performed at one of the two clients, that client
and
> the route reflector propagate BGP routes.
>
> when I change the BGP RID on the route reflector (which is not synced) to
> match RID from an intermediate (non-BGP) OSPF router and redistribute from
a
> router that is synced, the problem disappears. :-) You can add that to
> your list of fixes.
>
> -e-
>
> ----- Original Message -----
> From: "Stephen C. Feldberg" <scfeldberg@hotmail.com>
> To: "EA Louie" <elouie@yahoo.com>; <ccielab@groupstudy.com>
> Sent: Wednesday, December 26, 2001 6:52 AM
> Subject: Re: BGP and IGP redistribution - ccbootcamp8
>
>
> > Any route reflection configured in the transit AS? Rember that OSPF and
> BGP
> > have issues when sync is left enabled and the OSPF route needs to be
> > propagated between route reflector clients. The "fix" is to move the
> > redistribution point, or implement another IGP.
> >
> > Steve
> > ----- Original Message -----
> > From: "EA Louie" <elouie@yahoo.com>
> > To: <ccielab@groupstudy.com>
> > Sent: Tuesday, December 25, 2001 3:54 PM
> > Subject: BGP and IGP redistribution - ccbootcamp8
> >
> >
> > > Findings from ccbootcamp 8 that I wanted to share with you and get
some
> > > opinions about.
> > >
> > > The scenario has 3 BGP AS'es with one acting as a transit AS. The
rules
> > > called for synchronization on 3 of the BGP routers.
> > >
> > > I found that redistributing OSPF into BGP on a router that is not
> > synchronized
> > > did not allow the BGP routes to be sync'ed at a downstream iBGP
> neighbor,
> > > which prevented those routes from being propagated to the next eBGP
> > neighbor.
> > > The exact error message was found in deb ip bgp updates, which said
"No
> > valid
> > > path for a.b.c.d", and also from 'show ip bgp a.b.c.d' which would
> > indicate
> > > the route was not sync'ed. Can anyone explain to me why, when the bgp
> > routes
> > > are in the ip routing table, I'd get these messages, which essentially
> > prevent
> > > an iBGP to advertise routes to a eBGP neighbor? It looks like it has
> > > something to do with bgp next-hop addresses being the same in the IP
RT
> > and
> > > the BGP table, but I can't be sure, and wouldn't know how to make them
> the
> > > same even if I were sure.
> > >
> > > Now, if there's another way to solve this problem, I'd love to hear
> about
> > it,
> > > but all I did to solve it was move the OSPF --> BGP redistribution
point
> > to R6
> > > (for those familiar with this lab). I had originally done this at R1
(a
> > route
> > > reflector), where 'no sync' was allowed.
> > >
> > > I also found that redistributing the eBGP routes into OSPF (or other
> IGP)
> > at
> > > the iBGP entry points is a good practice, and only requires a small
> > > access-list and route-map to accomplish.
> > >
> > > -e-
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:56:18 GMT-3