From: MADMAN (dave@interprise.com)
Date: Thu Jan 16 2003 - 12:04:06 GMT-3
I'm reasonably sure the mask makes a differance. If you have
actually redistributed BGP into you IGP you should be able to leave
sync enabled though I always simply disable sync as it is not practical
to say the least.
I don't have a good answer for what your seeing short of relicating
the scenerio or logging into your network:)
Dave
cebuano wrote:
> Dave,
> If you look at the explanation on this page
> http://www.cisco.com/univercd/cc/td/doc/cisintwk/ics/icsbgp4.htm#xtocid2
> 043950
> It says, " Turning off synchronization on Router A will cause Router A
> to advertise network 203.250.15.0. This step is required because Router
> A will not synchronize with OSPF BECAUSE OF MASK DIFFERENCES. For the
> same reason, synchronization should also be turned off on Router B so
> that it can advertise network 203.250.13.0."
> So I changed the link between RtrB and RtrF to 203.250.15.0/24 to match
> that between RtrA nad RtrF of 203.250.14.0/24. I then turn
> synchronization ON.
> Again, this prevents both RtrA and B from advertising iBGP-learned
> routes to their eBGP peers.
>
> So two things...
> 1) The subnet mask difference has NOTHING to do with synchronization
> (unless this was true in older IOS releases).
> 2) I thought that it's okay to leave synchronization on since in this
> scenario the eBGP routes are being redistributed into OSPF thus RtrF in
> between RtrA&B have IGP knowledge of these eBGP routes.
> What am I missing?
>
> Elmer
>
>
> -----Original Message-----
> From: MADMAN [mailto:dave@interprise.com]
> Sent: Thursday, January 16, 2003 6:52 AM
> To: cebuano
> Cc: ccielab@groupstudy.com
> Subject: Re: BGP Synchronization Rule - changed in 12.0??
>
>
> Check out this URL:
>
> http://www.cisco.com/en/US/customer/tech/tk648/tk365/technologies_tech_n
> ote09186a0080094431.shtml
>
> Also as of 12.2.8, If I recall correctly, it may be 8T,
> synchronization is disabled by default finally!!
>
> Dave
>
> cebuano wrote:
>
>>After reading the Practical Design pages, I missed this very important
>>paragraph...
>>
>
> http://www.cisco.com/univercd/cc/td/doc/cisintwk/ics/icsbgp4.htm#xtocid2
>
>>043950
>>
>>Turning off synchronization on Router A will cause Router A to
>
> advertise
>
>>network 203.250.15.0. This step is required because Router A will not
>>synchronize with OSPF because of mask differences. For the same
>
> reason,
>
>>synchronization should also be turned off on Router B so that it can
>>advertise network 203.250.13.0.
>>
>>So, does anyone have a link that I can look up as to why the different
>>Masks will cause problems with Synchronization?
>>
>>TIA.
>>Elmer
>>
>>-----Original Message-----
>>From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
>
> Of
>
>>Joe Chang
>>Sent: Wednesday, January 15, 2003 5:53 PM
>>To: ccielab@groupstudy.com
>>Subject: Re: BGP Synchronization Rule - changed in 12.0??
>>
>>Cebuano wrote:
>>
>>
>>>My question is this.if synchronization is turned ON (default).even if
>>>the BGP routes are learned via OSPF.BGP does not install them in its
>>>routing table. Is this how synchronization affects iBGP peer
>>>advertisements?
>>
>>
>>I think in this case the rule of synchronization still holds because
>
> the
>
>>BGP
>>routes A is advertising have been successfully installed in the BGP
>>table of
>>B. The routing table (which is a separate entity from the BGP table,
>
> of
>
>>course) does not install the BGP routes because of the lower AD of
>
> OSPF
>
>>(which you have already discovered in your second example). In other
>>words,
>>what you observed is not a failure of synchronization because a
>>successful
>>update of the BGP table does not necessarily mean the routing table
>
> must
>
>>also reflect that update. In your first example router B should be
>
> able
>
>>to
>>advertise its IBGP routes to the external AS.
>>.
>>.
-- David Madland CCIE# 2016 Sr. Network Engineer Qwest Communications 612-664-3367"You don't make the poor richer by making the rich poorer." --Winston Churchill .
This archive was generated by hypermail 2.1.4 : Sat Feb 01 2003 - 07:33:51 GMT-3