[j-nsp] Optimizing the FIB on MX

[Alexander Marhold]

Hi

 

You wrote:

>One thing I haven't seen mentioned is that routers need indirect-nexthop feature enabled

 

IMHO exactly this is also called PIC   (prefix independent convergence) so to be exact to get a prefix amount independent convergence you need a pointer to a nexthop-pointer-structure which then points to the next-hop.

In case of a change of the nexthop you only need to change the pointer in the next-hop-pointer-structure independent how many prefixes are using that next-hop.

 

Regards

 

alexander

 

 

Von: Dragan Jovicic [mailto:draganj84 at gmail.com] 
Gesendet: Freitag, 19. Februar 2016 11:45
An: Adam Vitkovsky
Cc: alexander.marhold at gmx.at; sthaug at nethelp.no; Chuck Anderson; Vincent Bernat; juniper-nsp at puck.nether.net
Betreff: Re: [j-nsp] Optimizing the FIB on MX

 

Advertise-external or more general Additional Path capability (would prefer this if new install) could be used to distribute selected few routes if FIB space is of concern.

One thing I haven't seen mentioned is that routers need indirect-nexthop feature enabled, which should be by default enabled on recent Junos versions on all-MPC chassis. Otherwise, change of core interface will take at least a couple of dozen seconds to update FIB. DPC cards do not support this, and on older version you'd need to enable this feature by hand, if i remember correctly.

Also, if this protection is used in l3vpn, you would optimally need composite-nexthop feature which decouples link between indirect-nexhop and outer label (which is changed once core link fails).

 

Regards

 

On Fri, Feb 19, 2016 at 11:02 AM, Adam Vitkovsky <Adam.Vitkovsky at gamma.co.uk> wrote:

> Alexander Marhold [mailto:alexander.marhold at gmx.at]
> Sent: Thursday, February 18, 2016 6:50 PM
>
> Hi folks
>
> To make the discussion clearer and comming back to the Juniper MX 104
> implementation
>
> Here is a picture of 2 PEs on P  and 2 peers (ISP1 and IX1) let´s assume we
> want to prefer routes from IX1 over ISP1
> MX1 is EBGP (lpref 100) to  ISP1 and IBGP to MX2 and MX3
> MX2 is EBGP (lpref 110) to IX1 and IBGP to MX1 and MX3
>
>   ISP1                   IX1
>     | locpref         ^ locpref
>     |   100              |   110
>    MX1--------->-MX2
>     |                               |
>     |                               |
>     +------MX3--->--+
>
>
> In my opinion if you need also  the MX3 then  for this MX3 you need "PIC-
> CORE" to quickly switch between both paths
>
Yes that's right, "protect core" under routing-options of the Internet VRF.

However then I can ask what if MX2 fails or is severed from the core completely,
though with that I'd be opening a whole different and very interesting realm of convergence options.
First you'd need to tune your IGP so it propagates the unreachability of MX2's loopback towards MX3 as fast as possible.
Then I could argue that MX3 is in a different AS and it knows about MX2's loopback via BGP-LU -so you'd need to tune BGP-LU infrastructure(can't shave of much delay).
Then I could argue I want sub 50ms convergence in the above case and well then, then you'd have to rely on P routers to perform the local repair and swing from MX2 to MX1 If MX2 goes down.
And that brings me to Segment Routing and protecting a node segment upon the failure of its advertising node


> On MX1 you need "best-external" to advertise the external routes whereas
> the best is the internal route pointing to MX2
>
> On MX1 and MX2 you need "PIC-EDGE" to quickly switch when IX1 goes
> down
>
Well technically you need PIC-EDGE only on MX2 so it can do the local repair for traffic destined to IX1 and re-label it so that it gets to MX1.

> Do we all agree on that picture and the named mechanisms ( put in "") ?
>
>
> So now what versions of Junos is needed and what additional "unnecessary"
> methods like MPLS or LDP is now needed ?
>
Well I'm afraid you'd need to run MPLS L3VPNs for all this.


adam


        Adam Vitkovsky
        IP Engineer

T:      0333 006 5936
E:      Adam.Vitkovsky at gamma.co.uk
W:      www.gamma.co.uk

This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of this email are confidential to the ordinary user of the email address to which it was addressed. This email is not intended to create any legal relationship. No one else may place any reliance upon it, or copy or forward all or any of it in any form (unless otherwise notified). If you receive this email in error, please accept our apologies, we would be obliged if you would telephone our postmaster on +44 (0) 808 178 9652 <tel:%2B44%20%280%29%20808%20178%209652>  or email postmaster at gamma.co.uk

Gamma Telecom Limited, a company incorporated in England and Wales, with limited liability, with registered number 04340834, and whose registered office is at 5 Fleet Place London EC4M 7RD and whose principal place of business is at Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.



_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp