RE: BGP and IGP redistribution - ccbootcamp8

From: Chua, Parry (Parry.Chua@xxxxxxxxxx)
Date: Wed Dec 26 2001 - 01:09:05 GMT-3


   
Hi,

We are not in sync...
First of all, you should check the route that has problem, eg 1.1.1.0
Next, you check the RID of 1.1.1.0 from OSPF by show IP OSPF DATABASE.
Next, you check the RID of 1.1.1.0 from BGP by show IP BGP 1.1.1.0

Parry Chua
-----Original Message-----
From: EA Louie [mailto:elouie@yahoo.com]
Sent: Wednesday, December 26, 2001 12:03 PM
To: Chua, Parry
Cc: ccielab@groupstudy.com
Subject: Re: BGP and IGP redistribution - ccbootcamp8

the unsynced router:
R2#sh ip ospf
 Routing Process "ospf 1" with ID 200.200.100.1

R2#sh ip bgp
BGP table version is 15607, local router ID is 200.200.100.1

the next upstream iBGP neighbor:
R1#sh ip ospf
 Routing Process "ospf 1" with ID 200.200.200.1

R1#sh ip bgp
BGP table version is 13029, local router ID is 200.200.200.1

next theory?

----- Original Message -----
From: "Chua, Parry" <Parry.Chua@compaq.com>
To: "EA Louie" <elouie@yahoo.com>; <ccielab@groupstudy.com>
Sent: Tuesday, December 25, 2001 5:56 PM
Subject: RE: BGP and IGP redistribution - ccbootcamp8

On one of the Tech notes from Cisco on BGP best path selection
algorithm, Path marked as " not synchronized", it state that if matching
route is learn from OSPF neighbor, it OSPF RID must match the BGP RID.

Do a show IP OSPF DATABASE and SHOW IP BGP a.b.c.d and compare the RID.

Parry Chua

-----Original Message-----
From: EA Louie [mailto:elouie@yahoo.com]
Sent: Wednesday, December 26, 2001 4:55 AM
To: ccielab@groupstudy.com
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:32:47 GMT-3