Re: bgp peering+RR

From: Gary Duncanson (gary.duncanson@googlemail.com)
Date: Sat Oct 13 2007 - 10:01:28 ART


Hi Shiran

Obviously there is some problem of interpretation of your specific question
going on here! What exactly are you asking for confirmation of?

'.The question here is if the link between r1 and r4 is broken and r1
>> > > recieves an ebgp updates from outside..will it fwd it to R4??'

From my interpretation of that question, I reckon that R4 will receive R1's
ebgp update providing the peering between R1 and R4 is still up.

  ----- Original Message -----
  From: shiran guez
  To: Gary Duncanson
  Cc: ccielab@groupstudy.com ; Joseph Saad
  Sent: Saturday, October 13, 2007 1:42 PM
  Subject: Re: bgp peering+RR

  yes and that is the case here! if you look into the first note there was no
special indication regarding what is going on in the IGP, so if all routers
advertise there local interfaces and IGP is working properly then unless R4
lost all its interfaces to the IGP he will be still peering with R1 and R3

  On 10/13/07, Gary Duncanson <gary.duncanson@googlemail.com> wrote:
    Shiran,

    The peering between R1 and R4 will stay up even if the link between R1 and
R4 is down providing there is reachability to R4's loopback via another path
i.e R3 and R4.

    In this event R4 should still receive the eBGP learned route from R1.
      ----- Original Message -----
      From: shiran guez
      To: Gary Duncanson
      Cc: Joseph Saad ; ccielab@groupstudy.com
      Sent: Saturday, October 13, 2007 12:43 PM
      Subject: Re: bgp peering+RR

      If I didn't test it myself then I would drought my self now,

      But I did test it my self and even tough R4 is loosing the physical
connection to R1 it is still peering with him as they are peering via
loopback

      I have set EIGRP as the IGP and Advertised in each router all the
interface

      R1 R3 and R4 are peering via lo0 so even if the direct interface is down
peering between R1 to R4 is down only in case that R4 or R1 are down
completely as long as the IGP is ok.

      In normal scenario with no any out of the ordinary manipulation as long
as the IGP is ok unless R4 is down in all interface it will never loose
peering.

      On 10/13/07, Gary Duncanson <gary.duncanson@googlemail.com > wrote:
        I have to agree with Joseph so far. The R1 - R4 reachability seems to
be the
        clincher in the argument. Assuming iBGP peering between R1 and R4
remains up
        due to IGP I would expect R4 (AS 100) to have the ebgp update received
by
        R1(AS 100). If down it looks like the route reflector rules in this
scenario
        won't save the situation and R4 gets no iBGP route.

        Or perhaps I'm missing something?

        Gary
        ----- Original Message -----
        From: "Joseph Saad" < joseph.samir.saad@gmail.com>
        To: "shiran guez" < shiranp3@gmail.com>; "Cisco certification"
        <ccielab@groupstudy.com>
        Sent: Saturday, October 13, 2007 9:49 AM
        Subject: Re: bgp peering+RR

> R1
> / \
> / \
> r3-----r4
> / \ / \
> / \ / \
> r2 r5 r2
>
> I still disagree, R4 couldn't be possibly learning the route from
R2.
>
> The statement of "if R2 is learning it, it will pass to the entire
domain
> including R1" is flawed because R2 is not a ROUTE-REFLECTOR. It's
merely a
> CLIENT to both R3 and R4 as per the original post .... "I am
planning to
> make r2 and r5 as rr-clients for r3 and r4" ...
>
> so iBGP learnt route on R2 reflected from R3 can't be possibly be
> reflected
> to other neighbors as this breaks the full mesh rule and R2 is not a
> route-reflector.
>
> Let's review the assumptions: R3, R4 are Route reflectors. Both of
R2 and
> R5
> are each a route-reflector of client of both R3 and R4.
>
> We may need a 3rd opinion on the topic.
>
> I am afraid that one of us is missing something, but I don't know
who.
>
> Cheers,
> Joseph.
>
> On 10/12/07, shiran guez < shiranp3@gmail.com > wrote:
>>
>> Please notice to the initial note both R3 and R4 are RR Server for
R2 and
>> R5!
>> and for that meter both R3 and R4 learned the same from R1 and they
>> reflect to R2 and R5.
>> also if R2 is learning it will pass to the entire domain including
R1.
>>
>>
>>
>> On 10/11/07, Joseph Saad < joseph.samir.saad@gmail.com > wrote:
>> >
>> > whether R1 and R4 Loopbacks still reachable by R4 and R1
respectively.
>> > Independent of Route reflection, if reachability is maintained
via
>> > other
>> >
>> > means (e.g. via R3) the R1 eBGP-learnt routes will be advertised
to R4
>> > via
>> > the direct iBGP peering between R1 and R4. in Summary, the iBGP
peering
>> > is
>> > not broken in the first place.
>> >
>> > If not, then you need to consider the Route-reflection rules.
>> >
>> > Jeff Dolye Page 137: RFC 1966 defines three rules that the RR
uses to
>> > determine who the route is advertised to, depending on how the
route
>> > was
>> > learned:
>> > l If the route was learned from a non-client IBGP peer, it is
reflected
>> > to
>> > clients only.
>> > l If the route was learned from a client, it is reflected to all
>> > nonclients
>> > and clients, except for the originating client.
>> > l If the route was learned from an EBGP peer, it is reflected to
all
>> > clients
>> > and nonclients.
>> >
>> > with R3 as the route-reflector, it has learnt the route via a
>> > non-client
>> > iBGP peer (from R1), hence it will be reflected to clients only
(R2 &
>> > R5).
>> > Which means R4 shouldn't receive it.
>> >
>> > Hope this helps.
>> >
>> > Joseph.
>> >
>> > On 10/10/07, slevin kremera < slevin.kremera@gmail.com> wrote:
>> > >
>> > > R1
>> > > / \
>> > > / \
>> > > r3-----r4
>> > > / \ / \
>> > > / \ / \
>> > > r2 r5 r2
>> > >
>> > >
>> > > here all the routers are in as100. r1-r3-r4 are full meshed
and
>> > peering
>> > > wit
>> > > lo0. r2 and r5 are peering with r3 and r4..I am planning to
make r2
>> > and r5
>> > >
>> > > as rr-clients for r3 and r4
>> > >
>> > > .The question here is if the link between r1 and r4 is broken
and r1
>> > > recieves an ebgp updates from outside..will it fwd it to R4??
>> > >
>> > >
>> >



This archive was generated by hypermail 2.1.4 : Fri Nov 16 2007 - 13:11:14 ART