From: Howard C. Berkowitz (hcb@gettcomm.com)
Date: Tue Feb 01 2005 - 22:41:01 GMT-3
At 4:42 PM -0800 2/1/05, niko wrote:
>I have also read that when OSPF is the IGP, it is recommended that the OSPF
>& BGP RID do match:
That was a requirement of RFC 1403, BGP-OSPF interaction. I don't
remember the number of the RFC that changed its status to "historic"
-- which means obsolete.
>****************************************************************************
>*
>If OSPF is the IGP of BGP, and SYNC is enabled - the RID must be the same:
Hopefully, no one is asking you to use SYNC, a completely obsolete
technique. IIRC, it's now off by default on newer releases.
Now, if I manually set router-IDs (and I usually do), I set them to
the same value because that simply feels more straightforward.
Is there a reason ever not to? I've been trying to think of an
example, which I'd have to test. I thought of a case and then
rejected it: multiple OSPF processes with the same router ID, all
redistributed into OSPF. Until I thought it through, I wondered if
some BGP check might choke at two routes with the same router ID from
different sources -- and then realized that can't happen, since
redistribution is disambiguated by only touching installed routes.
>----------------------------------------------------------------------------
>----
>router ospf 1
> router-id 2.2.2.2
>
>router bgp 24
> bgp router-id 2.2.2.2
>----------------------------------------------------------------------------
>----
>* If manually change RID, do it for BOTH OSPF & BGP.
>* If not, the Router will select the HIGHEST Loopback IP or Interface IP
>address for both Routing Processes.
>****************************************************************************
>*******
>Nikolai
>
>----- Original Message -----
>From: "James Matrisciano" <jmatrisciano@kenttech.com>
>To: "Bajo" <bajoalex@gmail.com>; "Jonathan ZD" <Nuvo25@hotmail.com>
>Cc: "CCIE - GS" <ccielab@groupstudy.com>
>Sent: Tuesday, February 01, 2005 1:04 PM
>Subject: RE: BGP Router-ID
>
>
>Main "gotchya" on the BGP-ID is to make sure that if you are running
>sync on and the route is learned from a different router-id in the IGP
>that you have a matching router-id in your bgp advertisements,
>otherwise, the learning router will not advertise this route as the
>router-id does not match up right.
>
>jm
>
>
>-----Original Message-----
>From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
>Bajo
>Sent: Tuesday, February 01, 2005 3:49 PM
>To: Jonathan ZD
>Cc: CCIE - GS
>Subject: Re: BGP Router-ID
>
>Jonathan it will be valid only if
>
>a) either the address is a loopback interface or
>b) a physical interface address.
>
>The interface does NOT need to be running BGP.
>
>Take a look at Jeff Doyle's Routing TCP/IP Vll, page 154.
>
>
>On Tue, 1 Feb 2005 12:03:22 -0800, Jonathan ZD <Nuvo25@hotmail.com>
>wrote:
>> Is it neccessary that BGP Router-ID has to be reachable by its
>BGP-peers. For
>> example, if the following configuration valid?
>>
>> Rtr 01
>>
>> router bgp 100
>> bgp router-id 1.1.1.1
>> nei 192.168.21.2 remot 100
>>
>> ---------
>>
>> Rtr 02
>>
>> router bgp 100
>> bgp router-id 2.2.2.2
>> nei 192.168.21.1 remot 100
>>
>> *** The router-id (1.1.1.1 and 2.2.2.2), in this case, is not
>reachable by IGP
>> between both routers.
>>
>> ----------
>>
>> Thanks
>>
>>
>_______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>>
>
>
>--
>Regards,
>
>Bajo
>
>_______________________________________________________________________
>Subscription information may be found at:
>http://www.groupstudy.com/list/CCIELab.html
>
>_______________________________________________________________________
>Subscription information may be found at:
>http://www.groupstudy.com/list/CCIELab.html
>
>_______________________________________________________________________
>Subscription information may be found at:
>http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Thu Mar 03 2005 - 08:51:16 GMT-3