Re: [j-nsp] RR cluster

[Pavel Lunin]

> I would strongly advise against the previous suggestion of not running
> iBGP between the routers.  While the topology in particular may
> function without it, the next person to come along and work on the
> network may not expect it to be configured
Hmm... really depends. I can easily recall scenarios, where an iBGP
between RRs would increase chances of service outage.

Say, RRs are offline and don't pass traffic at all. They just don't (or
rather, even must not) have any "their own" routes to attract traffic.
The lack of inter-RR exchange is just an additional security (and
simplicity) measure. No session means no routing-policy, no leakage of
something (e. g. due to software bugs).

Imagine you use RRs to inject initially static routes into the network
(flowspec, blackhole, whatever). There is no reason to share this
between RRs, instead, you want both reflectors to redistribute it
independently.  If your forget to configure these statics on both RRs
(very common mistake), than, having an iBGP between them, you will still
see two copies of the route in the network despite you have configured
it only once. Thus you won't suspect that an RR failure will lead to a
withdrawal of these routes. So I personally would recommend to filter
such updates between RRs even when you have reasons for a session
between them.
> inconsistent with standards and best practices and may, thorough a
> seemingly unrelated change in topology, break things horribly. 
BTW, I don't really believe there exists a common standard or
best-practice prescribing to do this.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] RR cluster

[Brandon Ross]

On Thu, 7 Feb 2013, Huan Pham wrote:


Lets go back to Ali question, and what he wants:


I want them to send updates to each other and to the RR-Clients.


He will need to have unique RR IDs.

Pls tell me if this is not the case. Thanks.


If you take that statement very literally, then you are correct.

However, if what he really wants is for all of his routers to have a 
coherent view of the routing table, then it will work either way.  I 
interpret that this is really the question on the table, and if it's not, 
it's the question he should be asking.


I would strongly advise against the previous suggestion of not running 
iBGP between the routers.  While the topology in particular may function 
without it, the next person to come along and work on the network may not 
expect it to be configured inconsistent with standards and best practices 
and may, thorough a seemingly unrelated change in topology, break things 
horribly.


--
Brandon Ross  Yahoo & AIM:  BrandonNRoss
+1-404-635-6667ICQ:  2269442
Schedule a meeting:  https://doodle.com/brossSkype:  brandonross
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] RR cluster

[Ali Sumsam]

They are my border routers. having eBGP with upstream providers, and
gateway for the whole network. I want them to be backup of each other. If I
make one of them RR, and that one dies, my iBGP network is gone.

All the devices in the network, whether P or PE should peer with these two
Routers and not with anyone else.

Regards,
*Ali Sumsam CCIE*
*Network Engineer - Level 3*
eintellego Pty Ltd
a...@eintellego.net ; www.eintellego.net

Phone: 1300 753 383 ; Fax: (+612) 8572 9954

Cell +61 (0)410 603 531

facebook.com/eintellego
PO Box 7726, Baulkham Hills, NSW 1755 Australia

The Experts Who The Experts Call
Juniper - Cisco – Brocade - IBM


On Wed, Feb 6, 2013 at 2:13 PM, Caillin Bathern wrote:

> Are these dedicated RR's or are they combined RR/PE devices?
>
> -Original Message-
> From: juniper-nsp-boun...@puck.nether.net
> [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Doug Hanks
> Sent: Wednesday, 6 February 2013 2:02 PM
> To: Ali Sumsam; 
> Subject: Re: [j-nsp] RR cluster
>
> vanilla ibgp between the RRs would work
>
>
> On 2/5/13 6:36 PM, "Ali Sumsam"  wrote:
>
> >Hi All,
> >I want to configure two RRs in my network.
> >What should be the relation between two of them?
> >I want them to send updates to each other and to the RR-Clients.
> >
> >Regards,
> >*Ali Sumsam CCIE*
> >*Network Engineer - Level 3*
> >eintellego Pty Ltd
> >a...@eintellego.net ; www.eintellego.net
> >
> >Phone: 1300 753 383 ; Fax: (+612) 8572 9954
> >
> >Cell +61 (0)410 603 531
> >
> >facebook.com/eintellego
> >PO Box 7726, Baulkham Hills, NSW 1755 Australia
> >
> >The Experts Who The Experts Call
> >Juniper - Cisco - Brocade - IBM
> >___
> >juniper-nsp mailing list juniper-nsp@puck.nether.net
> >https://puck.nether.net/mailman/listinfo/juniper-nsp
> >
>
>
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> --
> Message  protected by MailGuard: e-mail anti-virus, anti-spam and
> content filtering.http://www.mailguard.com.au/mg
>
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] RR cluster

[Huan Pham]

Hi Shane, and all

I wish to withdraw the "best practice" advice, as it is a debatable topic.

Lets go back to Ali question, and what he wants:

>>> I want them to send updates to each other and to the RR-Clients.


He will need to have unique RR IDs.

Pls tell me if this is not the case. Thanks.

Huan

On 07/02/2013, at 2:38 AM, Shane Amante  wrote:

> I want them to send updates to each other and to the RR-Clients.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] RR cluster

[Shane Amante]

On Feb 6, 2013, at 1:17 AM, Huan Pham  wrote:
> Aggree with Doug with one condition: RRs do not share cluster ID.
> 
> If the two RRs have the same Cluster ID, then one RR does not accept routes 
> advertised by the other RR which it receives from its clients. It however 
> DOES accept routes generated by the other RR itself.
> 
> As a best practice, keep the Cluster ID unique to maximise the redundancy. 
> Although clients may receive redundant routing updates, no routing loop 
> occurs, nor there is a loop of routing updates. 

You may wish to be careful offering this advice or, at the very least, 
encourage others to test this in a Lab environment before choosing one 
direction vs. the other.  Specifically, the downside with the recommendation 
above is a [potential] amplification of BGP UPDATEs from RRs down to 
RR-clients.  More specifically, what we have observed is that a widely-used 
vendor[1] views any difference in the _contents_ of the CLUSTER_LIST -- not the 
length of the CLUSTER_LIST -- as cause to transmit a new BGP UPDATE.  This is 
also compounded by BGP MRAI being set at 0 -- in other words, there's very 
little (read: no) statistical probability that a RR will coalesce the change 
into a single UPDATE message that is sent to RR-clients.  Where this is most 
readily apparent is in a topology similar to the following:

  +- RR1 --- RR3 -+
  |   |  \ /  |   |
PE-1  |   x   |  PE-2
  |   |  / \  |   |
  +- RR2 --- RR4 -+

The above diagram depicts iBGP sessions between devices.  At a minimum, when 
PE-1 generates an UPDATE and sends it to RR1 and RR2.  With Unique Cluster IDs, 
they will each send their own UPDATE to RR3 & RR4.  Keep in mind, that there is 
a slight timing difference on when the UPDATEs are xmit'ed and recv'd by RR3, 
and RR4, due to a variety of factors not least of which is propagation delay, 
CPU processing time, etc. on the PEs and RRs.  The end result is that, for 
example, RR3 views the two CLUSTER_LISTs as different, runs path selection each 
time *and* floods and UPDATE for each run to PE-2.  (The same behavior is 
observed on RR4).  So, the end result is PE-2 receives 4x the UPDATEs, instead 
of just 2x.

See slides 30 - 32 of here for more info: 


In fairness, it's somewhat hard to fault the vendor for the aforementioned 
behavior.  After all, BGP is a distributed database and synchronization 
protocol and in a conservative implementation you'd want to lean to the side of 
ensuring any changes are synchronized throughout the whole network.  The 
downside is that you pay an increased tax in terms of flooding and processing 
many more BGP messages throughout the domain, which starts to get concerned 
when upper tiers of a RR hierarchy contain millions of paths.  

-shane

[1] Note, we did not observe this on JUNOS; but, we also did not *test* JUNOS 
for this behavior either, which is why I'm offering some caution.


> Huan
> 
> 
> On 06/02/2013, at 2:02 PM, Doug Hanks  wrote:
> 
>> vanilla ibgp between the RRs would work
>> 
>> 
>> On 2/5/13 6:36 PM, "Ali Sumsam"  wrote:
>> 
>>> Hi All,
>>> I want to configure two RRs in my network.
>>> What should be the relation between two of them?
>>> I want them to send updates to each other and to the RR-Clients.
>>> 
>>> Regards,
>>> *Ali Sumsam CCIE*
>>> *Network Engineer - Level 3*
>>> eintellego Pty Ltd
>>> a...@eintellego.net ; www.eintellego.net
>>> 
>>> Phone: 1300 753 383 ; Fax: (+612) 8572 9954
>>> 
>>> Cell +61 (0)410 603 531
>>> 
>>> facebook.com/eintellego
>>> PO Box 7726, Baulkham Hills, NSW 1755 Australia
>>> 
>>> The Experts Who The Experts Call
>>> Juniper - Cisco ­ Brocade - IBM
>>> ___
>>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>> 
>> 
>> 
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp



___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] RR cluster

[Pavel Lunin]

While the aforementioned approach (unique IDs and vanilla iBGP in
between) seems a reasonable baseline, the best way in practice depends
on factors like what sort of network the the RRs serve, how much state
they need to hold, whether they are on-line (do carry transit traffic)
or off-line (are just pieces of standalone control-plane).

Good discussion on same/unique cluster-ID can be found in the "JUNOS
Enterprise Routing" book. Some additional ideas regarding scaling RRs
for large-scale mBGP/VPN installations are in the "MPLS Enabled
Applications".

As cluster-ID debate easily turns into a holy-war, I ask to forgive me
this bit of fuel to the fire. But having been watching several networks
with the same ID approach in place for years, I must tell it's fairly
OK, especially if the RRs are topologically close or you don't expect
the network to scale beyond a single pair of RRs. The less amount of RIB
state on RRs is not only less burden to the hardware, but also a bit of
troubleshooting simplicity for NOC guys. In some cases, say, if the RRs
never need to forward traffic to each other, you might even want to omit
the iBGP session between them.

But, again, if you just want to plug and go, the mentioned approach
seems to be the right start.

Regars,
Pavel

06.02.2013 12:17, Huan Pham wrote:
> Aggree with Doug with one condition: RRs do not share cluster ID.
>
> If the two RRs have the same Cluster ID, then one RR does not accept routes 
> advertised by the other RR which it receives from its clients. It however 
> DOES accept routes generated by the other RR itself.
>
> As a best practice, keep the Cluster ID unique to maximise the redundancy. 
> Although clients may receive redundant routing updates, no routing loop 
> occurs, nor there is a loop of routing updates. 
>
> Huan
>
>
> On 06/02/2013, at 2:02 PM, Doug Hanks  wrote:
>
>> vanilla ibgp between the RRs would work
>>
>>
>> On 2/5/13 6:36 PM, "Ali Sumsam"  wrote:
>>
>>> Hi All,
>>> I want to configure two RRs in my network.
>>> What should be the relation between two of them?
>>> I want them to send updates to each other and to the RR-Clients.
>>>
>>> Regards,
>>> *Ali Sumsam CCIE*
>>> *Network Engineer - Level 3*
>>> eintellego Pty Ltd
>>> a...@eintellego.net ; www.eintellego.net
>>>
>>> Phone: 1300 753 383 ; Fax: (+612) 8572 9954
>>>
>>> Cell +61 (0)410 603 531
>>>
>>> facebook.com/eintellego
>>> PO Box 7726, Baulkham Hills, NSW 1755 Australia
>>>
>>> The Experts Who The Experts Call
>>> Juniper - Cisco ­ Brocade - IBM
>>> ___
>>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>>
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] RR cluster

[Huan Pham]

Aggree with Doug with one condition: RRs do not share cluster ID.

If the two RRs have the same Cluster ID, then one RR does not accept routes 
advertised by the other RR which it receives from its clients. It however DOES 
accept routes generated by the other RR itself.

As a best practice, keep the Cluster ID unique to maximise the redundancy. 
Although clients may receive redundant routing updates, no routing loop occurs, 
nor there is a loop of routing updates. 

Huan


On 06/02/2013, at 2:02 PM, Doug Hanks  wrote:

> vanilla ibgp between the RRs would work
> 
> 
> On 2/5/13 6:36 PM, "Ali Sumsam"  wrote:
> 
>> Hi All,
>> I want to configure two RRs in my network.
>> What should be the relation between two of them?
>> I want them to send updates to each other and to the RR-Clients.
>> 
>> Regards,
>> *Ali Sumsam CCIE*
>> *Network Engineer - Level 3*
>> eintellego Pty Ltd
>> a...@eintellego.net ; www.eintellego.net
>> 
>> Phone: 1300 753 383 ; Fax: (+612) 8572 9954
>> 
>> Cell +61 (0)410 603 531
>> 
>> facebook.com/eintellego
>> PO Box 7726, Baulkham Hills, NSW 1755 Australia
>> 
>> The Experts Who The Experts Call
>> Juniper - Cisco ­ Brocade - IBM
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 
> 
> 
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] RR cluster

[Caillin Bathern]

Are these dedicated RR's or are they combined RR/PE devices?

-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Doug Hanks
Sent: Wednesday, 6 February 2013 2:02 PM
To: Ali Sumsam; 
Subject: Re: [j-nsp] RR cluster

vanilla ibgp between the RRs would work


On 2/5/13 6:36 PM, "Ali Sumsam"  wrote:

>Hi All,
>I want to configure two RRs in my network.
>What should be the relation between two of them?
>I want them to send updates to each other and to the RR-Clients.
>
>Regards,
>*Ali Sumsam CCIE*
>*Network Engineer - Level 3*
>eintellego Pty Ltd
>a...@eintellego.net ; www.eintellego.net
>
>Phone: 1300 753 383 ; Fax: (+612) 8572 9954
>
>Cell +61 (0)410 603 531
>
>facebook.com/eintellego
>PO Box 7726, Baulkham Hills, NSW 1755 Australia
>
>The Experts Who The Experts Call
>Juniper - Cisco - Brocade - IBM
>___
>juniper-nsp mailing list juniper-nsp@puck.nether.net 
>https://puck.nether.net/mailman/listinfo/juniper-nsp
>



___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
--
Message  protected by MailGuard: e-mail anti-virus, anti-spam and
content filtering.http://www.mailguard.com.au/mg


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] RR cluster

[Doug Hanks]

vanilla ibgp between the RRs would work


On 2/5/13 6:36 PM, "Ali Sumsam"  wrote:

>Hi All,
>I want to configure two RRs in my network.
>What should be the relation between two of them?
>I want them to send updates to each other and to the RR-Clients.
>
>Regards,
>*Ali Sumsam CCIE*
>*Network Engineer - Level 3*
>eintellego Pty Ltd
>a...@eintellego.net ; www.eintellego.net
>
>Phone: 1300 753 383 ; Fax: (+612) 8572 9954
>
>Cell +61 (0)410 603 531
>
>facebook.com/eintellego
>PO Box 7726, Baulkham Hills, NSW 1755 Australia
>
>The Experts Who The Experts Call
>Juniper - Cisco ­ Brocade - IBM
>___
>juniper-nsp mailing list juniper-nsp@puck.nether.net
>https://puck.nether.net/mailman/listinfo/juniper-nsp
>



___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp