From: Mingzhou Nie (mnie@xxxxxxxxx)
Date: Thu Aug 29 2002 - 12:43:02 GMT-3
Khalid,
However, even as you said r2 and r6 "have to" to in same sub-as, if you
redistribute bgp 65200 into ospf, r6 will be synced.
thanks for pointing out.
Ming
--- Mingzhou Nie <mnie@yahoo.com> wrote:
> 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,
> > > > >
>
=== message truncated ===
This archive was generated by hypermail 2.1.4 : Sat Sep 07 2002 - 19:48:42 GMT-3