From: Nick Shah (nshah@xxxxxxxxxxxxxx)
Date: Thu Jun 06 2002 - 06:26:15 GMT-3
Steven,
what other probs (apart from manipulating router ids) can we come across in
a scenario like this. pl. explain.
ps. This is one hell of a scenario, and network admins. will maul us if we
do something like this in a prod netw :)
rgds
Nick
-----Original Message-----
From: steven.j.nelson@bt.com <steven.j.nelson@bt.com>
To: nshah@connect.com.au <nshah@connect.com.au>; p_chopin@yahoo.com
<p_chopin@yahoo.com>; Eddy.Fong@hp.com <Eddy.Fong@hp.com>
Cc: ccielab@groupstudy.com <ccielab@groupstudy.com>
Date: Thursday, 6 June 2002 7:07
Subject: RE: (Solved)
>Nick,
>
>Yep, correct
>
>There are some problems that appear when using this with route reflectors,
>you may want to look into that.
>
>Thanks
>
>Steve
>
>-----Original Message-----
>From: Nick Shah [mailto:nshah@connect.com.au]
>Sent: 06 June 2002 10:17
>To: Nelson,SJ,Steven,IVNH33 C; p_chopin; Eddy.Fong
>Cc: ccielab
>Subject: Re: (Solved)
>
>
>Paul,
>
>I have managed to get this one working.... I am posting the relevant
configs
>as under
>
>R1 # doesnt have anything running except RIP...
>
>
> 3.0.0.0/32 is subnetted, 1 subnets
>C 3.3.3.3 is directly connected, Loopback0
>C 200.100.100.0/24 is directly connected, Serial0
> 199.199.2.0/30 is subnetted, 1 subnets
>C 199.199.2.4 is directly connected, Serial1
> 199.199.1.0/30 is subnetted, 1 subnets
>C 199.199.1.0 is directly connected, Ethernet0
>
>R2 #
>
>
>
>router ospf 1
>router-id 5.5.5.5 (keep this router id in mind, check below)
> redistribute rip metric 20 subnets (redistributing RIP routes from R1)
> network 199.199.1.1 0.0.0.0 area 0
> network 199.199.2.1 0.0.0.0 area 0
> network 199.199.3.1 0.0.0.0 area 0
>!
>router rip
> network 199.199.1.0
>!
>router bgp 2
> bgp router-id 9.9.9.9 (note this will is purposely different from the OSPF
>router id)
> neighbor 199.199.1.2 remote-as 1
> neighbor 199.199.3.2 remote-as 3
> no auto-summary
>
>
>R3 #
>
>router ospf 1
>router-id 4.4.4.4
> log-adjacency-changes
> network 199.199.3.2 0.0.0.0 area 0
>!
>router bgp 3
> bgp router-id 5.5.5.5 (note that this router id is same as ospf router id
>on R2)
> bgp cluster-id 67372036
> bgp log-neighbor-changes
> neighbor 199.199.2.2 remote-as 3
> neighbor 199.199.3.1 remote-as 2
>
>
>R4 #
>
>R4#sh ip bg
>BGP table version is 2, local router ID is 2.2.2.2
>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
>*>i200.100.100.0 199.199.3.1 100 0 2 1 i
>RouterB#sh ip bgp 200.100.100.0
>BGP routing table entry for 200.100.100.0/24, version 2
>Paths: (1 available, best #1, table Default-IP-Routing-Table)
> Advertised to non peer-group peers:
> 199.199.4.2
> 2 1, (Received from a RR-client)
> 199.199.3.1 (metric 75) from 199.199.3.2 (5.5.5.5)
> Origin IGP, localpref 100, valid, internal, synchronized, best
>R4#
>
>Now, I will also try to lab it up with Confeds and acheive the same result,
>then without using OSPF (as steve suggested, using EIGRP or RIP)
>
>rgds
>Nick
>-----Original Message-----
>From: steven.j.nelson@bt.com <steven.j.nelson@bt.com>
>To: p_chopin@yahoo.com <p_chopin@yahoo.com>; Eddy.Fong@hp.com
><Eddy.Fong@hp.com>
>Cc: ccielab@groupstudy.com <ccielab@groupstudy.com>
>Date: Thursday, 6 June 2002 5:56
>Subject: RE:
>
>
>>Guys
>>
>>Eddy is right, the problem is that the igp route from R2 is via ibgp and
>the
>>igp route is from R3 so BGP says these routes are from different sources
>and
>>therefore are "untrustworthy" so hence not synchronised.
>>
>>Confeds will work fine but you need to learn this one with and without
>them.
>>maybe use an igp that does not depend on RIDs such as eigrp etc etc.
>>
>>Have a play with it and know it back to front you'll need it.
>>
>>HTH
>>
>>Steve
>>
>>-----Original Message-----
>>From: Paul [mailto:p_chopin@yahoo.com]
>>Sent: 06 June 2002 06:24
>>To: Fong, Eddy
>>Cc: ccielab@groupstudy.com
>>Subject: RE:
>>
>>
>>Is there any remedy except confederations?
>>Paul
>>--- "Fong, Eddy" <Eddy.Fong@hp.com> wrote:
>>> I think we have come across this issue before.
>>> Anyway, it's because the IGP route 200.100.100.0/24
>>> is from R2. But the iBGP route is from R3. When you
>>> have OSPF as IGP and want to syn with BGP, the route
>>> originator R-Ids have to be the same. Otherwaise
>>> it's not synchronized and, hence, not advertise to
>>> R5.
>>>
>>>
>>> -----Original Message-----
>>> From: Paul [mailto:p_chopin@yahoo.com]
>>> Sent: Thursday, June 06, 2002 10:59 AM
>>> To: ccielab@groupstudy.com
>>> Subject:
>>>
>>>
>>> Hi group,
>>> I just run into another interesting little problem.
>>> I have R1-R2---R3
>>> | |
>>> \ /
>>> R4---R5
>>> R1 is running RiP. R2,R3,R4,R5 are running ospf. R2
>>> is
>>> redistributing rip into ospf domain.R1 is inserting
>>> route 200.100.100.0/24 to BGP through network
>>> statement and Redistributing this route into Rip as
>>> well. R1 is in AS1 , R2 in AS3, and R5,R4,R5 in As
>>> 3.EBGP sessions R1-R2, R2-R3. IBGP sesions R3-R4,
>>> R4-R5. R4 is route reflector.Synch is enable on all
>>> the routers.Question is why on R4 BGP table says,
>>> that
>>> route 200.100.100.0/24 is not synchronized even it's
>>> known through ospf and is not being pushed to R5.
>>> All routers have hard coded identical routers id in
>>> ospf and BGP.
>>> I've been struggling almost a week with this one.I
>>> searched and read white papers on CCO - I still
>>> don't
>>> understand.I'm missing really something important.
>>> Can you help?
>>> Paul
>>>
>>>
>>>
>>>
>>>
This archive was generated by hypermail 2.1.4 : Tue Jul 02 2002 - 08:12:26 GMT-3