From: Brian McGahan (brian@cyscoexpert.com)
Date: Thu Sep 19 2002 - 13:36:22 GMT-3
Donny,
Not necessarily. Technically you could set one router's OSPF
RID to match the other router's BGP RID, and it would meet the
synchronization rule. I would not recommend this though.
Therefore as a general guideline, your statement is correct.
HTH
Brian McGahan, CCIE #8593
Director of Design and Implementation
brian@cyscoexpert.com
CyscoExpert Corporation
Internetwork Consulting & Training
http://www.cyscoexpert.com
Voice: 847.674.3392
Fax: 847.674.2625
> -----Original Message-----
> From: Donny MATEO [mailto:donny.mateo@sg.ca-indosuez.com]
> Sent: Thursday, September 19, 2002 7:32 AM
> To: Brian McGahan
> Cc: ccielab@groupstudy.com
> Subject: RE: sync problem again
>
>
> Hi Brian,
>
> in short can you say that in order for route to sync you need to make
sure
> that OSPF and BGP get the
> route from the same router ?
> Also if you define a router-id in OSPF process you better make sure
you
> define the same router ID in
> BGP process ?
>
>
> Best Regards
> Donny
>
>
>
> "Brian McGahan"
> <brian@cyscoexper To: "'hoon'"
> <urlee21@kornet.net>, <ccielab@groupstudy.com>
> t.com> cc:
> Sent by: Subject: RE: sync
problem
> again
> nobody@groupstudy
> .com
>
>
> 19-09-2002 10:56
> Please respond to
> "Brian McGahan"
>
>
>
>
>
>
> http://www.cisco.com/warp/public/459/25.shtml
>
> "Paths marked as "not synchronized" in the show ip bgp
<longer-prefixes>
> output. If BGP synchronization is enabled, which it is by default in
> Cisco IOSR Software, there must be a match for the prefix in the IP
> routing table in order for an internal (iBGP) path to be considered a
> valid path. If the matching route is learned from an OSPF neighbor,
its
> OSPF router ID must match the BGP router ID of the iBGP neighbor. Most
> users prefer to disable synchronization using the no synchronization
BGP
> subcommand."
>
> r3#sh ip ro 200.1.1.0
> Routing entry for 200.1.1.0/24
> Known via "ospf 1", distance 110, metric 74, type extern 1
> Redistributing via eigrp 1
> Advertised by eigrp 1 metric 2000 100 255 1 1500
> Last update from 100.1.23.2 on serial0, 00:15:37 ago
> Routing Descriptor Blocks:
> * 100.1.23.2, from 100.1.1.1, 00:15:37 ago, via serial0
> Route metric is 74, traffic share count is 1
>
> r3#sh ip bgp 200.1.1.0
> BGP routing table entry for 200.1.1.0/24, version 3
> Paths: (1 available, no best path)
> Not advertised to any peer
> Local
> 100.1.1.1 (metric 55) from 100.1.2.2 (100.1.2.2)
> Origin incomplete, metric 0, localpref 100, valid, internal,
not
> synchronized
> Originator: 100.1.1.1, Cluster list: 100.1.2.2
>
> What does this all mean? It means that your current setup will not
> work.
>
> The RID is shown in the "from w.x.y.z" field under OSPF, and the
> "(w.x.y.z)" field under BGP. As we see in the above example,
100.1.1.1
> != 100.1.2.2, therefore the prefix is not synchronized.
>
> Either you must
>
> 1. fully mesh your iBGP sessions
> 2. use confederation
> 3. use another IGP besides OSPF
> 4. turn synchronization off
>
>
> HTH
>
> Brian McGahan, CCIE #8593
> Director of Design and Implementation
> brian@cyscoexpert.com
>
> CyscoExpert Corporation
> Internetwork Consulting & Training
> http://www.cyscoexpert.com
> Voice: 847.674.3392
> Fax: 847.674.2625
>
>
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> Of
> > hoon
> > Sent: Wednesday, September 18, 2002 9:09 PM
> > To: ccielab@groupstudy.com
> > Subject: sync problem again
> >
> > hi, guys..
> >
> > i just have the same old sync problem issue about RR, RR-clients and
> IGP.
> > tried to find old threads about it but some had been deleted
already.
> >
> > Well, this is it;
> > i have R2 as a RR and R1, R3 as clients.
> > They are running OSPF w/ the RID 100.1.1.1, 100.1.2.2, 100.1.3.3
> > respectively which are each loopback ip addresses. ibgp neighbors
are
> > established w/ loopback ip addresses.
> > Each bgp process is configured to be sync.
> > One more loopback w/ 200.1.1.1/24 in R1 and not to be configured as
> > 'network' command but redi into bgp by redi 'connect' w/ the
route-map
> > 'match interface loopback 2'
> > Each serial is F/R and all nexthop info, serial, loopback ip address
> are
> > in IGP RT.
> >
> >
> > lo :100.1.1.1 (ospf area1)
> lo:100.1.2.2
> > (ospf area 0) lo:100.1.3.3
> > lo2: 200.1.1.1/24 -- R1 <----- serial -------> R2
> <-----
> > serial --------> R3
> > (rr-client) 100.1.12.0/24
> (rr)
> > 100.1.23.0/24 (rr-client)
> >
> >
> > R1 config.
> >
> > ospf 1
> > router-id 100.1.1.1
> > redi connect metric-type 1 route-map lo2 subnet
> >
> >
> > bgp 1
> > bgp router-id 100.1.1.1
> > redi connect route-map lo2
> > neigh 100.1.2.2 remote-as 1
> > neigh 100.1.2.2 update-source loopback0
> >
> > route-map lo2
> > match interface lo2
> >
> > R2 config
> >
> > ospf 1
> > router-id 100.1.2.2
> >
> > bgp 1
> > bgp router-id 100.1.2.2
> > neigh rrc peer-group
> > neigh rrc remote-as 1
> > neigh rrc update-source loopback0
> > neigh 100.1.1.1 peer-group rrc
> > neigh 100.1.3.3 peer-group rrc
> >
> > R3 config
> >
> > ospf 1
> > router-id 100.1.3.3
> >
> > bgp 1
> > bgp router-id 100.1.3.3
> > neigh 100.1.2.2 remote-as 1
> > neigh 100.1.2.2 update-source loopback0
> >
> > r1 rt
> >
> > C 200.1.1.0/24 is directly connected, Loopback2
> >
> > bt
> >
> > BGP routing table entry for 200.1.1.0/24, version 2
> > Paths: (1 available, best #1, table Default-IP-Routing-Table)
> > Flag: 0x208
> > Advertised to non peer-group peers:
> > 100.1.2.2
> > Local
> > 0.0.0.0 from 0.0.0.0 (100.1.1.1)
> > Origin incomplete, metric 0, localpref 100, weight 32768,
valid,
> > sourced, best
> >
> > r2 rt+bt
> >
> > O E1 200.1.1.0/24 [110/68] via 100.1.12.1, 02:17:32, Serial1.1
> >
> > r2#sh ip ro 200.1.1.0
> > Routing entry for 200.1.1.0/24
> > Known via "ospf 1", distance 110, metric 68, type extern 1
> > Last update from 100.1.12.1 on Serial1.1, 00:05:03 ago
> > Routing Descriptor Blocks:
> > * 100.1.12.1, from 100.1.1.1, 00:05:03 ago, via Serial1.1
> > Route metric is 68, traffic share count is 1
> >
> > r2#sh ip bgp 200.1.1.0
> > BGP routing table entry for 200.1.1.0/24, version 4
> > Paths: (1 available, best #1, table Default-IP-Routing-Table)
> > Advertised to peer-groups:
> > rrc
> > Local, (Received from a RR-client)
> > 100.1.1.1 (metric 49) from 100.1.1.1 (100.1.1.1)
> > Origin incomplete, metric 0, localpref 100, valid, internal,
> > synchronized, best
> >
> > r3 rt+bt
> >
> >
> > O E1 200.1.1.0/24 [110/74] via 100.1.23.2, 00:21:54, serial 0
> >
> > r3#sh ip ro 200.1.1.0
> > Routing entry for 200.1.1.0/24
> > Known via "ospf 1", distance 110, metric 74, type extern 1
> > Redistributing via eigrp 1
> > Advertised by eigrp 1 metric 2000 100 255 1 1500
> > Last update from 100.1.23.2 on serial0, 00:15:37 ago
> > Routing Descriptor Blocks:
> > * 100.1.23.2, from 100.1.1.1, 00:15:37 ago, via serial0
> > Route metric is 74, traffic share count is 1
> >
> > r3#sh ip bgp 200.1.1.0
> > BGP routing table entry for 200.1.1.0/24, version 3
> > Paths: (1 available, no best path)
> > Not advertised to any peer
> > Local
> > 100.1.1.1 (metric 55) from 100.1.2.2 (100.1.2.2)
> > Origin incomplete, metric 0, localpref 100, valid, internal,
not
> > synchronized
> > Originator: 100.1.1.1, Cluster list: 100.1.2.2
> >
> > the problem is on BT in r3 about n/w 200.1.1.0 which won't be
> synchronized
> > at all.
> > i know that ospf rid and bgp rid should match somehow.
> > and they seem to match
> > r3#sh ip ospf da | in 200.1.1.0
> > 200.1.1.0 100.1.1.1 940 0x80000006 0x429 0
> >
> > i found if R1 and R3 are full-meshed, then it would be synchronized
> and
> > also,
> > static "ip route 200.1.1.0 255.255.255.0 100.1.1.1" on r3 would sync
> it
> > too.
> >
> > but why is the route not synchronized when it's advertized by RR?
> > i don't get it.
> > anybody helps me?
> > thanks in advance.
>
>
>
>
>
> This message is for information purposes only and its content
> should not be construed as an offer, or solicitation of an offer,
> to buy or sell any banking or financial instruments or services
> and no representation or warranty is given in respect of its
> accuracy, completeness or fairness. The material is subject
> to change without notice. You should take your own independent
> tax, legal and other professional advice in respect of the content
> of this message. This message may contain confidential or
> legally privileged material and may not be copied, redistributed
> or published (in whole or in part) without our prior written consent.
> This email may have been intercepted, partially destroyed,
> arrive late, incomplete or contain viruses and no liability is
> accepted by any member of the Credit Agricole Indosuez group
> as a result. If you are not the intended recipient of this message,
> please immediately notify the sender and delete this message
> from your computer.
This archive was generated by hypermail 2.1.4 : Mon Oct 07 2002 - 07:43:57 GMT-3