Re: [j-nsp] Full BGP table, one provider w/ 2 routers, slow forwarding convergence

[Sebastian Wiesinger]

* Olivier Benghozi  [2014-08-23 20:09]:
> Maybe you should wait.
> 
> In 12.3R6 and before you can hit PR593444.
> But in 12.3R7 you will hit PR671136.

PR671136 is fixed in 12.3R7-S2 at least.

Other than that I'm really waiting for 14.2 to see if they did manage
to fix this. Funny that it took so long for the convergence problems
to get a larger audience. For a long time it seemed that we were the
only ones with MX80/JFlow combination.

Regards

Sebastian

-- 
GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A  9D82 58A2 D94A 93A0 B9CE)
'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE.
-- Terry Pratchett, The Fifth Elephant
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Full BGP table, one provider w/ 2 routers, slow forwarding convergence

[Justin M. Streiner]

On Sat, 23 Aug 2014, Olivier Benghozi wrote:


Maybe you should wait.

In 12.3R6 and before you can hit PR593444.
But in 12.3R7 you will hit PR671136.

Maybe in 12.3R8 it will "just" be slow, who knows...


Good point, and thank you for the heads-up.  I looked up that PR and it's 
listed as closed, but there is no version of Junos listed for the fix. 
I'm following up with Juniper on this one.


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

Re: [j-nsp] Full BGP table, one provider w/ 2 routers, slow forwarding convergence

[Olivier Benghozi]

Maybe you should wait.

In 12.3R6 and before you can hit PR593444.
But in 12.3R7 you will hit PR671136.

Maybe in 12.3R8 it will "just" be slow, who knows...


Olivier


Le 22 août 2014 à 15:26, Justin M. Streiner  a écrit :
> Convergence with multiple full feeds (IPv4 and IPv6) is good if I disable all 
> sampling.  This is on a pair of MX480s running 12.3R6.6.  We are planning to 
> upgrade to 12.3R7.7 in the next few weeks, which is supposed to fix the 
> sampling.
> 
> I've also been hearing that how sampled interacts with rpd and the kernel is 
> supposed to be totally re-worked...
> 
> jms
> 
> On Fri, 22 Aug 2014, david@orange.com wrote:
> 
>> I've planned to test this precious enhancement in the 14.2 beta program :)
>> 
>> David
>> 
>> 
>>  
>> David Roy
>> IP/MPLS NOC engineer - Orange France
>> Ph. : +33 2 99 87 64 72
>> Mob. : +33 6 85 52 22 13
>> SkypeID : davidroy.35
>> david@orange.com
>>  
>> JNCIE x3 (SP #703 ; ENT #305 ; SEC #144)
>> 
>> 
>> 
>> -Original Message-
>> From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
>> Darren O'Connor
>> Sent: vendredi 22 août 2014 17:27
>> To: Scott Granados; Euan Galloway
>> Cc: juniper-nsp@puck.nether.net
>> Subject: Re: [j-nsp] Full BGP table, one provider w/ 2 routers, slow 
>> forwarding convergence
>> 
>> I've been hearing for years that quicker convergence is coming 'in a later 
>> release'
>> 
>> Thanks
>> Darren
>> http://www.mellowd.co.uk/ccie
>> 
>> 
>> 
>>> From: sc...@granados-llc.net
>>> To: euang+juniper-...@lists.eusahues.co.uk
>>> Date: Fri, 22 Aug 2014 10:40:29 -0400
>>> CC: juniper-nsp@puck.nether.net
>>> Subject: Re: [j-nsp] Full BGP table, one provider w/ 2 routers, slow
>>> forwarding convergence
>>> 
>>> I can confirm with inline flow sampling enabled and even with the code to 
>>> fix the PR convergence is still slower.  I hear there's a better fix being 
>>> released in later code 14.2 if memory serves but I'm not sure.
>>> 
>>> On Aug 22, 2014, at 5:13 AM, Euan Galloway 
>>>  wrote:
>>> 
>>>> On Thu, Aug 21, 2014 at 03:38:32PM -0400, Clarke Morledge wrote:
>>>> 
>>>>> I did upgrade to 13.3R3 to try to resolve PR963060, but I am still
>>>>> seeing enough traffic loss that it makes me skeptical as to whether
>>>>> I have really hit this PR, if the issue has not really been resolved, or 
>>>>> if something
>>>>> else is going on.   I still think Junos should converge faster.
>>>> 
>>>> Did you try disabling inline jflow (and sampling if used), which
>>>> would answer the is it/isn't it on that PR (and someone/something to shout 
>>>> at).


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

Re: [j-nsp] Full BGP table, one provider w/ 2 routers, slow forwarding convergence

[David Siebörger]

On Friday, 22 August 2014 9:26:22 AM Justin M. Streiner wrote:
> Convergence with multiple full feeds (IPv4 and IPv6) is good if I disable
> all sampling.

While we're on this subject, does anyone know whether the situation is any 
better with "Junos Traffic Vision" NetFlow running on an MS-MIC in an MX80?  
i.e. does convergence time improve when the NetFlow processing is offloaded to 
the extra hardware, or is it just as bad?


-- 
David Siebörger
d...@sieborger.nom.za


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

Re: [j-nsp] Full BGP table, one provider w/ 2 routers, slow forwarding convergence

[Justin M. Streiner]

Convergence with multiple full feeds (IPv4 and IPv6) is good if I disable 
all sampling.  This is on a pair of MX480s running 12.3R6.6.  We are 
planning to upgrade to 12.3R7.7 in the next few weeks, which is supposed 
to fix the sampling.


I've also been hearing that how sampled interacts with rpd and the kernel 
is supposed to be totally re-worked...


jms

On Fri, 22 Aug 2014, david@orange.com wrote:


I've planned to test this precious enhancement in the 14.2 beta program :)

David


 
David Roy
IP/MPLS NOC engineer - Orange France
Ph. : +33 2 99 87 64 72
Mob. : +33 6 85 52 22 13
SkypeID : davidroy.35
david@orange.com
 
JNCIE x3 (SP #703 ; ENT #305 ; SEC #144)



-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
Darren O'Connor
Sent: vendredi 22 août 2014 17:27
To: Scott Granados; Euan Galloway
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Full BGP table, one provider w/ 2 routers, slow forwarding 
convergence

I've been hearing for years that quicker convergence is coming 'in a later 
release'

Thanks
Darren
http://www.mellowd.co.uk/ccie




From: sc...@granados-llc.net
To: euang+juniper-...@lists.eusahues.co.uk
Date: Fri, 22 Aug 2014 10:40:29 -0400
CC: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Full BGP table, one provider w/ 2 routers, slow
forwarding convergence

I can confirm with inline flow sampling enabled and even with the code to fix 
the PR convergence is still slower.  I hear there's a better fix being released 
in later code 14.2 if memory serves but I'm not sure.

On Aug 22, 2014, at 5:13 AM, Euan Galloway 
 wrote:


On Thu, Aug 21, 2014 at 03:38:32PM -0400, Clarke Morledge wrote:


I did upgrade to 13.3R3 to try to resolve PR963060, but I am still
seeing enough traffic loss that it makes me skeptical as to whether
I have really hit this PR, if the issue has not really been resolved, or if 
something
else is going on.   I still think Junos should converge faster.


Did you try disabling inline jflow (and sampling if used), which
would answer the is it/isn't it on that PR (and someone/something to shout at).

--
Euan Galloway
___
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

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.


___
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] Full BGP table, one provider w/ 2 routers, slow forwarding convergence

[david.roy]

I've planned to test this precious enhancement in the 14.2 beta program :) 

David


 
David Roy 
IP/MPLS NOC engineer - Orange France
Ph. : +33 2 99 87 64 72
Mob. : +33 6 85 52 22 13
SkypeID : davidroy.35
david@orange.com
 
JNCIE x3 (SP #703 ; ENT #305 ; SEC #144)



-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
Darren O'Connor
Sent: vendredi 22 août 2014 17:27
To: Scott Granados; Euan Galloway
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Full BGP table, one provider w/ 2 routers, slow forwarding 
convergence

I've been hearing for years that quicker convergence is coming 'in a later 
release' 

Thanks
Darren
http://www.mellowd.co.uk/ccie



> From: sc...@granados-llc.net
> To: euang+juniper-...@lists.eusahues.co.uk
> Date: Fri, 22 Aug 2014 10:40:29 -0400
> CC: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] Full BGP table, one provider w/ 2 routers,   slow
> forwarding convergence
> 
> I can confirm with inline flow sampling enabled and even with the code to fix 
> the PR convergence is still slower.  I hear there's a better fix being 
> released in later code 14.2 if memory serves but I'm not sure.
> 
> On Aug 22, 2014, at 5:13 AM, Euan Galloway 
>  wrote:
> 
> > On Thu, Aug 21, 2014 at 03:38:32PM -0400, Clarke Morledge wrote:
> > 
> >> I did upgrade to 13.3R3 to try to resolve PR963060, but I am still 
> >> seeing enough traffic loss that it makes me skeptical as to whether 
> >> I have really hit this PR, if the issue has not really been resolved, or 
> >> if something
> >> else is going on.   I still think Junos should converge faster.
> > 
> > Did you try disabling inline jflow (and sampling if used), which 
> > would answer the is it/isn't it on that PR (and someone/something to shout 
> > at).
> > 
> > --
> > Euan Galloway
> > ___
> > 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

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.


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

Re: [j-nsp] Full BGP table, one provider w/ 2 routers, slow forwarding convergence

[Darren O'Connor]

I've been hearing for years that quicker convergence is coming 'in a later 
release' 

Thanks
Darren
http://www.mellowd.co.uk/ccie



> From: sc...@granados-llc.net
> To: euang+juniper-...@lists.eusahues.co.uk
> Date: Fri, 22 Aug 2014 10:40:29 -0400
> CC: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] Full BGP table, one provider w/ 2 routers,   slow
> forwarding convergence
> 
> I can confirm with inline flow sampling enabled and even with the code to fix 
> the PR convergence is still slower.  I hear there’s a better fix being 
> released in later code 14.2 if memory serves but I’m not sure.
> 
> On Aug 22, 2014, at 5:13 AM, Euan Galloway 
>  wrote:
> 
> > On Thu, Aug 21, 2014 at 03:38:32PM -0400, Clarke Morledge wrote:
> > 
> >> I did upgrade to 13.3R3 to try to resolve PR963060, but I am still seeing 
> >> enough traffic loss that it makes me skeptical as to whether I have really 
> >> hit this PR, if the issue has not really been resolved, or if something 
> >> else is going on.   I still think Junos should converge faster.
> > 
> > Did you try disabling inline jflow (and sampling if used), which would 
> > answer 
> > the is it/isn't it on that PR (and someone/something to shout at).
> > 
> > -- 
> > Euan Galloway
> > ___
> > 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] Full BGP table, one provider w/ 2 routers, slow forwarding convergence

[Scott Granados]

I can confirm with inline flow sampling enabled and even with the code to fix 
the PR convergence is still slower.  I hear there’s a better fix being released 
in later code 14.2 if memory serves but I’m not sure.

On Aug 22, 2014, at 5:13 AM, Euan Galloway 
 wrote:

> On Thu, Aug 21, 2014 at 03:38:32PM -0400, Clarke Morledge wrote:
> 
>> I did upgrade to 13.3R3 to try to resolve PR963060, but I am still seeing 
>> enough traffic loss that it makes me skeptical as to whether I have really 
>> hit this PR, if the issue has not really been resolved, or if something 
>> else is going on.   I still think Junos should converge faster.
> 
> Did you try disabling inline jflow (and sampling if used), which would answer 
> the is it/isn't it on that PR (and someone/something to shout at).
> 
> -- 
> Euan Galloway
> ___
> 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] Full BGP table, one provider w/ 2 routers, slow forwarding convergence

[Euan Galloway]

On Thu, Aug 21, 2014 at 03:38:32PM -0400, Clarke Morledge wrote:

> I did upgrade to 13.3R3 to try to resolve PR963060, but I am still seeing 
> enough traffic loss that it makes me skeptical as to whether I have really 
> hit this PR, if the issue has not really been resolved, or if something 
> else is going on.   I still think Junos should converge faster.

Did you try disabling inline jflow (and sampling if used), which would answer 
the is it/isn't it on that PR (and someone/something to shout at).

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

Re: [j-nsp] Full BGP table, one provider w/ 2 routers, slow forwarding convergence

[Clarke Morledge]

I wanted to follow-up on the list with a report of what I did to try to 
resolve this issue.


I have not had the opportunity to try to play tricks with routing policy 
to only populate the forwarding table with a default router while still 
receiving a full Internet router table via BGP.  It is a little bit tricky 
for me since I also have another ISP to worry about that complicates our 
BGP design.


However, what I did try was the load balancing method across both of my 
outgoing links using the "multipath" option described here:


http://www.juniper.net/techpubs/en_US/junos13.3/topics/topic-map/bgp-multipath-unequal.html

It breaks my plan to do active/passive between the two links for outgoing 
traffic. I am using MED to control preference for incoming traffic, which 
works well for an active/passive design for incoming traffic.


I was able to reduce the failover time in the event of a "fiber cut" type 
of issue from 90 seconds down to about 10 or 20 seconds for most traffic. 
However, this only works if you are receiving the exact same copy of the 
Internet routing table from the upstream provider.


In my case, there is enough variation in routes coming from the upstream 
provider between their two routers that I do not really get full load 
balancing going on in the forwarding table.  In those cases, I am back to 
about 70 to 90 seconds to complete a failover transition for outgoing 
traffic.


I did upgrade to 13.3R3 to try to resolve PR963060, but I am still seeing 
enough traffic loss that it makes me skeptical as to whether I have 
really hit this PR, if the issue has not really been resolved, or if 
something else is going on.   I still think Junos should converge faster.



Clarke Morledge
College of William and Mary


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

Re: [j-nsp] Full BGP table, one provider w/ 2 routers, slow forwarding convergence

[Darren O'Connor]

indirect-next-hop doesn't help with two distinct directly connected BGP 
neighbours unfortunately. It only really helps with iBGP neighbours in which 
the next-hop remains the same but the path changes to that next-hop

Thanks
Darren
http://www.mellowd.co.uk/ccie



> Date: Thu, 14 Aug 2014 16:39:45 +0200
> To: chm...@wm.edu
> From: sth...@nethelp.no
> CC: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] Full BGP table, one provider w/ 2 routers, slow 
> forwarding convergence
> 
> Do you have
> 
> set routing-options forwarding-table indirect-next-hop
> 
> Relevant for FIB update speed.
> 
> Steinar Haug, Nethelp consulting, sth...@nethelp.no
> ___
> 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] Full BGP table, one provider w/ 2 routers, slow forwarding convergence

[Toni Mattila]

Hi,

On 14.8.2014 16:01, Clarke Morledge wrote:

Do you happen to know the PR number on the full routing table and
netflow issue? I am doing inline-jflow, so perhaps that may have
something to do with it.


PR963060 Resolved in 12.2R9 12.3R5-S4 12.3R7 13.1R5 13.2R5 13.3R3 14.1R1

Though I hear there will be total resolution somewhere in 14.2 time 
frame. This fix just mitigates the issue.


Cheers,
Toni

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

Re: [j-nsp] Full BGP table, one provider w/ 2 routers, slow forwarding convergence

[Darren O'Connor]

indirect-next-hop doesn't help with two distinct directly connected BGP 
neighbours unfortuantely. It only really helps with iBGP neighbours in which 
the protocol next-hop stays the same but the path to that next-hop changes

Thanks
Darren
http://www.mellowd.co.uk/ccie



> Date: Thu, 14 Aug 2014 16:39:45 +0200
> To: chm...@wm.edu
> From: sth...@nethelp.no
> CC: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] Full BGP table, one provider w/ 2 routers, slow 
> forwarding convergence
> 
> Do you have
> 
> set routing-options forwarding-table indirect-next-hop
> 
> Relevant for FIB update speed.
> 
> Steinar Haug, Nethelp consulting, sth...@nethelp.no
> ___
> 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] Full BGP table, one provider w/ 2 routers, slow forwarding convergence

[sthaug]

Do you have

set routing-options forwarding-table indirect-next-hop

Relevant for FIB update speed.

Steinar Haug, Nethelp consulting, sth...@nethelp.no
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Full BGP table, one provider w/ 2 routers, slow forwarding convergence

[Clarke Morledge]

I will probably try the FIB filtering idea, but I was curious to know if 
anyone has tried doing an active/passive scenario with a single provider 
multihomed on two different routers in using BGP multipath for load 
balancing.


I see a document that describes "Load Balancing BGP Traffic with Unequal 
Bandwidth Allocated to the Paths":


http://www.juniper.net/techpubs/en_US/junos13.3/topics/topic-map/bgp-multipath-unequal.html

But in the future, I would like to be able to better control the routes I 
send out to the upstream provider and not get them too involved with 
tweaking stuff on their end.  Using BGP multipath, I think I can just use 
something like MED to control preference for incoming traffic, but I 
believe this is applied on the neighbor statement; that is, something that 
I can not control via policy when involving more than one neighbor for 
different routes that I am advertising.


Please correct me if I am wrong.

Does anyone have experience with this?

Clarke Morledge
College of William and Mary
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Full BGP table, one provider w/ 2 routers, slow forwarding convergence

[Clarke Morledge]

Roland Dobbins asked in response to my question here:


Can I do what I need to do with some sort of BGP multipath load balancing, but 
with keeping my traffic engineering objectives intact?


Why are you going for failover instead of active/active?  With a failover 
scenario, X% of your capacity is going unused . . .


Also, why multihome into the same upstream transit provider?  A higher 
degree of resiliency is achieved by multihoming with multiple transit 
providers.



Hi, Roland,

It is a bit involved, but both of my paths up to router A and router B for 
this particular ISP are being shared with other customers.  So I am trying 
to do some traffic engineering and shaping so that I do not interfere with 
what the other customers are doing on these shared pipes.


As I mentioned earlier, I do have multiple providers, but I am mainly 
trying to solve the forwarding problem for my main provider where I am 
multi-homed to meet my traffic engineering requirements.


Clarke Morledge
College of William and Mary
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Full BGP table, one provider w/ 2 routers, slow forwarding convergence

[Darren O'Connor]

> I do need the full Internet feeds for other reasons, but I am interested 
> in the option to filter routes between RIB & FIB to keep my FIB smaller, 
> but send the full table downstream.  What JUNOS knob does that?

Create a policy matching specific BGP routes and export into the forwarding 
table, exclude all other BGP routes and then accept all else. The RIB is still 
full as normal and can be advertised to other peers. Of course make sure you 
have some kind of default route in your fib to send traffic on it's way

Thanks
Darren
http://www.mellowd.co.uk/ccie



> Date: Thu, 14 Aug 2014 09:01:17 -0400
> From: chm...@wm.edu
> To: a...@oasis-tech.net
> CC: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] Full BGP table, one provider w/ 2 routers, slow 
> forwarding convergence
> 
> Amos,
> 
> I am using an MX240, and I am aware of the MX80 platform issue when 
> dealing with multiple BGP feeds.  I have the newer 1800 RE, so I was 
> hoping to completely avoid anything like that with a beefier RE, running 
> 64-bit JUNOS.
> 
> I do need the full Internet feeds for other reasons, but I am interested 
> in the option to filter routes between RIB & FIB to keep my FIB smaller, 
> but send the full table downstream.  What JUNOS knob does that?
> 
> Do you happen to know the PR number on the full routing table and netflow 
> issue? I am doing inline-jflow, so perhaps that may have something to do 
> with it.
> 
> Clarke Morledge
> College of William and Mary
> 
> 
> 
> On Thu, 14 Aug 2014, Amos Rosenboim wrote:
> 
> > What model of router are you using ?
> > What you are describing is a general problem of juniper routers, however 
> > it's really bad on
> > the low-mid range routers, MX5-80, the 104 is slightly better but not very.
> > The stronger REs are less prone for this, although the real solution is a 
> > serious change to
> > RPD.
> > Recent releases should have incremental improvements, although afaik the 
> > root cause was not
> > corrected.
> > 
> > There was also another similar issue that involved full routing table and 
> > netflow.
> > I believe this one was corrected in one of the recent releases.
> > 
> > Do you really need full routing table?
> > Especially when both links are to the same ISP?
> > 
> > There is also an option to filter routes between the RIB and FIB, so you 
> > can send the full
> > table downstream but rely on a smaller set of routes for forwarding.
> > 
> > Cheers,
> > 
> > Amos
> ___
> 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] Full BGP table, one provider w/ 2 routers, slow forwarding convergence

[Amos Rosenboim]

Clarke,

I only got my phone with me, so not much detailed information.
The filtering is done under routing-options forwarding table.
You can define policies there.

I hope this helps.

Amos

Sent from my iPhone

On 14 Aug 2014, at 16:01, "Clarke Morledge" 
mailto:chm...@wm.edu>> wrote:

Amos,

I am using an MX240, and I am aware of the MX80 platform issue when
dealing with multiple BGP feeds.  I have the newer 1800 RE, so I was
hoping to completely avoid anything like that with a beefier RE, running
64-bit JUNOS.

I do need the full Internet feeds for other reasons, but I am interested
in the option to filter routes between RIB & FIB to keep my FIB smaller,
but send the full table downstream.  What JUNOS knob does that?

Do you happen to know the PR number on the full routing table and netflow
issue? I am doing inline-jflow, so perhaps that may have something to do
with it.

Clarke Morledge
College of William and Mary



On Thu, 14 Aug 2014, Amos Rosenboim wrote:

What model of router are you using ?
What you are describing is a general problem of juniper routers, however it's 
really bad on
the low-mid range routers, MX5-80, the 104 is slightly better but not very.
The stronger REs are less prone for this, although the real solution is a 
serious change to
RPD.
Recent releases should have incremental improvements, although afaik the root 
cause was not
corrected.

There was also another similar issue that involved full routing table and 
netflow.
I believe this one was corrected in one of the recent releases.

Do you really need full routing table?
Especially when both links are to the same ISP?

There is also an option to filter routes between the RIB and FIB, so you can 
send the full
table downstream but rely on a smaller set of routes for forwarding.

Cheers,

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

Re: [j-nsp] Full BGP table, one provider w/ 2 routers, slow forwarding convergence

[Amos Rosenboim]

Hi,

What model of router are you using ?
What you are describing is a general problem of juniper routers, however it's 
really bad on the low-mid range routers, MX5-80, the 104 is slightly better but 
not very.
The stronger REs are less prone for this, although the real solution is a 
serious change to RPD.
Recent releases should have incremental improvements, although afaik the root 
cause was not corrected.

There was also another similar issue that involved full routing table and 
netflow.
I believe this one was corrected in one of the recent releases.

Do you really need full routing table?
Especially when both links are to the same ISP?

There is also an option to filter routes between the RIB and FIB, so you can 
send the full table downstream but rely on a smaller set of routes for 
forwarding.

Cheers,

Amos

Sent from my iPhone

On 14 Aug 2014, at 14:59, "Clarke Morledge" 
mailto:chm...@wm.edu>> wrote:

I am trying to resolve a forwarding convergence problem in our existing
architecture all doing BGP with full routing feeds with upstream
providers. In one particular case, I am multihomed with one single
provider (single AS) with two routers (A and B)  existing in different
locations for redundancy.

My objective initially is an active/passive scenario, failing over to the
backup link to this provider in the event of a fiber cut, using BFD to
signal to BGP a problem. My first thought was to establish one external
BGP group connecting to neighbor A, sending out my routes without much AS
prepending and setting a high local preference for incoming routes. A
second external BGP group connects to neighbor router B, using lots of AS
prepending for my routes going out, and using a lower local preference for
routes coming in.

In testing the design, my advertisements going out get updated almost
immediately with my upstream provider, per looking at their looking glass
during a "fiber cut." But on my end, even though BGP starts to change
the preference for the incoming routes fairly quickly, it takes a long
time to push the changes to the forwarding tables in the PFE.  With the
full Internet table, I have seen it take up to about 80 to 90 seconds for
a few selected routes.

My objective was to get the failover to complete in less than 20 seconds.
Presumably, if I were only handling the default route, the solution would
be trivial, but at this point I need to keep on receiving the full
Internet table.

Can I do what I need to do with some sort of BGP multipath load balancing,
but with keeping my traffic engineering objectives intact?

Below are some config snippets. Thanks for any suggestions/solutions.

Clarke Morledge
College of William and Mary




Upstream Provider ASN: 65001
Upstream Provider Router A (Primary): 172.16.0.2
Upstream Provider Router B (Backup): 172.16.1.2


[edit policy-options policy-statement bgp-isp-router-b-out]
term local-16 {
from {
route-filter 192.168.0.0/16 exact;
}
then {
as-path-prepend "65002 65002 65002 65002 65002 65002 65002 65002
65002";
accept;
}
}

[edit policy-options policy-statement bgp-isp-router-a-out]
term local-16 {
from {
route-filter 192.168.0.0/16 exact;
}
then {
as-path-prepend "65002 65002 65002";
accept;
}
}
[edit policy-options policy-statement bgp-isp-router-b-in]
term default {
then {
local-preference 285;
accept;
}
}
[edit policy-options policy-statement bgp-isp-router-a-in]
term default {
then {
local-preference 290;
accept;
}
}
[protocols bgp]
group isp-router-a {
type external;
import bgp-isp-router-a-in;
export bgp-isp-router-a-out;
peer-as 65001;
bfd-liveness-detection {
minimum-interval 999;
multiplier 10;
}
neighbor 172.16.0.2;
}
group isp-router-b {
type external;
import bgp-isp-router-b-in;
export bgp-isp-router-b-out;
peer-as 65001;
bfd-liveness-detection {
minimum-interval 999;
multiplier 10;
}
neighbor 172.16.1.2;


___
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] Full BGP table, one provider w/ 2 routers, slow forwarding convergence

[Clarke Morledge]

Amos,

I am using an MX240, and I am aware of the MX80 platform issue when 
dealing with multiple BGP feeds.  I have the newer 1800 RE, so I was 
hoping to completely avoid anything like that with a beefier RE, running 
64-bit JUNOS.


I do need the full Internet feeds for other reasons, but I am interested 
in the option to filter routes between RIB & FIB to keep my FIB smaller, 
but send the full table downstream.  What JUNOS knob does that?


Do you happen to know the PR number on the full routing table and netflow 
issue? I am doing inline-jflow, so perhaps that may have something to do 
with it.


Clarke Morledge
College of William and Mary



On Thu, 14 Aug 2014, Amos Rosenboim wrote:


What model of router are you using ?
What you are describing is a general problem of juniper routers, however it's 
really bad on
the low-mid range routers, MX5-80, the 104 is slightly better but not very.
The stronger REs are less prone for this, although the real solution is a 
serious change to
RPD.
Recent releases should have incremental improvements, although afaik the root 
cause was not
corrected.

There was also another similar issue that involved full routing table and 
netflow.
I believe this one was corrected in one of the recent releases.

Do you really need full routing table?
Especially when both links are to the same ISP?

There is also an option to filter routes between the RIB and FIB, so you can 
send the full
table downstream but rely on a smaller set of routes for forwarding.

Cheers,

Amos

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

Re: [j-nsp] Full BGP table, one provider w/ 2 routers, slow forwarding convergence

[Roland Dobbins]

On Aug 14, 2014, at 6:55 PM, Clarke Morledge  wrote:

> Can I do what I need to do with some sort of BGP multipath load balancing, 
> but with keeping my traffic engineering objectives intact?

Why are you going for failover instead of active/active?  With a failover 
scenario, X% of your capacity is going unused . . .

Also, why multihome into the same upstream transit provider?  A higher degree 
of resiliency is achieved by multihoming with multiple transit providers.

--
Roland Dobbins  // 

   Equo ne credite, Teucri.

  -- Laocoön


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

Re: [j-nsp] Full BGP table, one provider w/ 2 routers, slow forwarding convergence

[Olivier Benghozi]

Hi Clarke,

Are you using some MX80 routers ? :)

regards,
Olivier Benghozi
Wifirst

> In testing the design, my advertisements going out get updated almost 
> immediately with my upstream provider, per looking at their looking glass 
> during a "fiber cut." But on my end, even though BGP starts to change the 
> preference for the incoming routes fairly quickly, it takes a long time to 
> push the changes to the forwarding tables in the PFE.  With the full Internet 
> table, I have seen it take up to about 80 to 90 seconds for a few selected 
> routes.


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

[j-nsp] Full BGP table, one provider w/ 2 routers, slow forwarding convergence

[Clarke Morledge]

I am trying to resolve a forwarding convergence problem in our existing 
architecture all doing BGP with full routing feeds with upstream 
providers. In one particular case, I am multihomed with one single 
provider (single AS) with two routers (A and B)  existing in different 
locations for redundancy.


My objective initially is an active/passive scenario, failing over to the 
backup link to this provider in the event of a fiber cut, using BFD to 
signal to BGP a problem. My first thought was to establish one external 
BGP group connecting to neighbor A, sending out my routes without much AS 
prepending and setting a high local preference for incoming routes. A 
second external BGP group connects to neighbor router B, using lots of AS 
prepending for my routes going out, and using a lower local preference for 
routes coming in.


In testing the design, my advertisements going out get updated almost 
immediately with my upstream provider, per looking at their looking glass 
during a "fiber cut." But on my end, even though BGP starts to change 
the preference for the incoming routes fairly quickly, it takes a long 
time to push the changes to the forwarding tables in the PFE.  With the 
full Internet table, I have seen it take up to about 80 to 90 seconds for 
a few selected routes.


My objective was to get the failover to complete in less than 20 seconds. 
Presumably, if I were only handling the default route, the solution would 
be trivial, but at this point I need to keep on receiving the full 
Internet table.


Can I do what I need to do with some sort of BGP multipath load balancing, 
but with keeping my traffic engineering objectives intact?


Below are some config snippets. Thanks for any suggestions/solutions.

Clarke Morledge
College of William and Mary




Upstream Provider ASN: 65001
Upstream Provider Router A (Primary): 172.16.0.2
Upstream Provider Router B (Backup): 172.16.1.2


[edit policy-options policy-statement bgp-isp-router-b-out]
term local-16 {
from {
route-filter 192.168.0.0/16 exact;
}
then {
as-path-prepend "65002 65002 65002 65002 65002 65002 65002 65002 
65002";

accept;
}
}

[edit policy-options policy-statement bgp-isp-router-a-out]
term local-16 {
from {
route-filter 192.168.0.0/16 exact;
}
then {
as-path-prepend "65002 65002 65002";
accept;
}
}
[edit policy-options policy-statement bgp-isp-router-b-in]
term default {
then {
local-preference 285;
accept;
}
}
[edit policy-options policy-statement bgp-isp-router-a-in]
term default {
then {
local-preference 290;
accept;
}
}
[protocols bgp]
group isp-router-a {
type external;
import bgp-isp-router-a-in;
export bgp-isp-router-a-out;
peer-as 65001;
bfd-liveness-detection {
minimum-interval 999;
multiplier 10;
}
neighbor 172.16.0.2;
}
group isp-router-b {
type external;
import bgp-isp-router-b-in;
export bgp-isp-router-b-out;
peer-as 65001;
bfd-liveness-detection {
minimum-interval 999;
multiplier 10;
}
neighbor 172.16.1.2;


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