From: Mingzhou Nie (mnie@xxxxxxxxx)
Date: Thu Aug 29 2002 - 12:35:19 GMT-3
You are right, Khalid. If r2 and r6 are in same sub-as, then r6 gets
routes thru IBGP, and then sync problem arises. But the whole idea of
having each router at its own sub-as is to overcome sync problem. Why
would you want r2 and r6 on the same as? In other words, why would you
want r6 receives routes thru IBGP?
If requirement says you can only have two sub-as at most, I would put
r1 and r2 in 65100, and r6 at 65200, and it will still work.
Ming
--- Khalid Siddiq <khalid@sys.net.pk> wrote:
> Mingzhou,
> it will not work if R2 and R6 are in AS 65200, that is if R2 has IBGP
> peering with R6.
> can someone clarify that.
> regards,
> khalid
>
> -----Original Message-----
> From: Mingzhou Nie [mailto:mnie@yahoo.com]
> Sent: Wednesday, August 28, 2002 5:22 AM
> To: Nick Shah; Volkov, Dmitry (Toronto - BCE); ccielab@groupstudy.com
> Subject: Re: Again BGP sync/rid problem
>
>
> Damn, why didn't I think deeper into confed :) Nick's right.
>
> It works!!!
>
> r1
> router bgp 65100
> bgp router-id 133.7.1.1
> bgp log-neighbor-changes
> bgp confederation identifier 2010
> bgp confederation peers 65200
> neighbor 133.7.12.2 remote-as 65200
> neighbor 133.7.12.2 ebgp-multihop 3
> neighbor 133.7.12.2 next-hop-self
> neighbor 133.7.66.2 remote-as 2001
>
> r141#b
> BGP table version is 5, local router ID is 133.7.1.1
> 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
> *> 160.100.100.0/24 133.7.66.2 0 0 2001 i
> *> 160.100.128.0/24 133.7.66.2 0 0 2001 i
> *> 160.100.129.0/24 133.7.66.2 0 0 2001 i
> *> 160.100.130.0/24 133.7.66.2 0 0 2001 i
> r141#
>
>
> r2
> !
> router bgp 65200
> bgp router-id 133.7.2.2
> bgp log-neighbor-changes
> bgp confederation identifier 2010
> bgp confederation peers 65100 65300
> neighbor 133.7.11.1 remote-as 65100
> neighbor 133.7.11.1 ebgp-multihop 3
> neighbor 133.7.13.2 remote-as 65300
> neighbor 133.7.13.2 ebgp-multihop 3
> !
> r142#b
> BGP table version is 5, local router ID is 133.7.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
> *> 160.100.100.0/24 133.7.11.1 0 100 0 (65100)
> 2001 i
> *> 160.100.128.0/24 133.7.11.1 0 100 0 (65100)
> 2001 i
> *> 160.100.129.0/24 133.7.11.1 0 100 0 (65100)
> 2001 i
> *> 160.100.130.0/24 133.7.11.1 0 100 0 (65100)
> 2001 i
> r142#
>
>
> r6
> router bgp 65300
> bgp router-id 133.7.6.6
> bgp log-neighbor-changes
> bgp confederation identifier 2010
> bgp confederation peers 65200
> neighbor 133.7.12.2 remote-as 65200
> neighbor 133.7.12.2 ebgp-multihop 3
> !
>
> r146#b
> BGP table version is 13, local router ID is 133.7.6.6
> 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
> *> 160.100.100.0/24 133.7.11.1 0 100 0 (65200
> 65100) 2001 i
> *> 160.100.128.0/24 133.7.11.1 0 100 0 (65200
> 65100) 2001 i
> *> 160.100.129.0/24 133.7.11.1 0 100 0 (65200
> 65100) 2001 i
> *> 160.100.130.0/24 133.7.11.1 0 100 0 (65200
> 65100) 2001 i
> r146#
>
>
> --- Nick Shah <nshah@connect.com.au> wrote:
> > Dmitry
> >
> > The only sure shot way to avoid the 'ugliness' of manipulating the
> > BGP &
> > OSPF RID's is to get away and not use the Route reflectors at all.
> >
> > Instead, use Confeds, you will not have synch issues then. That way
> > you can
> > have the best of both the worlds and you can easily satisfy the
> > condition of
> > not having to full mesh them, by making only one 'confed AS'
> neighbor
> > with
> > the other 2 confed AS (dont create the peership between the 2
> confed
> > AS's,
> > just like you would do in RRc's)
> >
> >
> > rgds
> > Nick
> > ----- Original Message -----
> > From: "Mingzhou Nie" <mnie@yahoo.com>
> > To: "Volkov, Dmitry (Toronto - BCE)" <dmitry_volkov@ca.ml.com>;
> > <ccielab@groupstudy.com>
> > Sent: Wednesday, August 28, 2002 8:58 AM
> > Subject: RE: Again BGP sync/rid problem
> >
> >
> > > Dmitry,
> > >
> > > Here are the things that I tried when working on this kind of
> > scenario.
> > >
> > > - change ospf to bgp redistribution from r1 to r2
> > >
> > > this won't work because you can only redistribute EBGP into igrp
> > >
> > > - turn off sync on r6
> > >
> > > this will work, but may not be allowed.
> > >
> > > - change bgp route-id on r2 the same as ospf route-id on r1, then
> > you
> > > have to either update r1's bgp id or r2's ospf id, or it will
> break
> > > either ospf or bgp. However, now r2, the RR gets bgp routes from
> r1
> > > with different ospf and bgp id(because on r1, their id are
> > different
> > > now), so you have to turn off sync on RR
> > >
> > > this will work too, but you have to turn off sync on RR, plus
> > route-id
> > > on r1 and r1 are really ugly
> > >
> > > - if both r2 and r6 are not allowed "no sync", and "r1 and r6 can
> > only
> > > have one neibough"(basically you have to use RR), then there's no
> > way
> > > to make it work
> > >
> > > maybe other people have more thoughts?
> > >
> > > ming
> > > --- "Volkov, Dmitry (Toronto - BCE)" <dmitry_volkov@ca.ml.com>
> > wrote:
> > > > Hello group,
> > > >
> > > > Nobody answered yet !!!
> > > > Is this absolutely no real life case ???
> > > >
> > > > Shortly again :) - When we redistr BGP into OSPF, OSPF creates
> > LSA 5
> > > > flooded
> > > > anywhere (with except stubs)
> > > > These LSAs have ADV Router (in ospf DB) with RID of redistr
> > router.
> > > > When Route reflector gets BGP route from redistr router - OSPF
> > RID
> > > > and BGP
> > > > RID of route learned via OSPF and via BGP are equal. So route
> is
> > > > "synchronized, best"
> > > > When BGP route is reflected from RR to internal peers - OSPF
> RID
> > of
> > > > Originator of route is still the same ("from RID of redist
> > router" -
> > > > LSA 5
> > > > are not changed), but route learned via BGP shows "from RID of
> > RR",
> > > > despite
> > > > that Originator of route is still the same and because, I
> guess,
> > OSPF
> > > > RID
> > > > doesn't match BGP RID where route learned from - route "not
> > > > synchronized"
>
=== message truncated ===
This archive was generated by hypermail 2.1.4 : Sat Sep 07 2002 - 19:48:41 GMT-3