[j-nsp] Optimizing the FIB on MX

[Adam Vitkovsky]

> Vincent Bernat
> Sent: Wednesday, February 17, 2016 11:14 PM
>
>  17 février 2016 22:56 GMT, Adam Vitkovsky
> <Adam.Vitkovsky at gamma.co.uk> :
>
> >> Being a bit unsatisfied with a pair of MX104 turning themselves as a
> >> blackhole during BGP convergence, I am trying to reduce the size of the
> FIB.
> >>
> > You mentioned earlier that this is a new installation so why not use
> > routing instance for Internet which allows you to use PIC with your
> > current version of code and save you all this trouble duck-taping the
> > solution together.
>
> You are right. I didn't understand your answer the first time as I thought that
> PIC was for "programmable integrated circuit", so I thought this was a plan
> for Juniper to fix the problem with some dedicated piece of hardware.
> --
Sorry about that, I'll try to be more explicit in my future posts.

The setup is really easy


1) carve up the FIB so that it allows for multiple next-hops (in our case pointer to a backup path)
set routing-options forwarding-table export lb
set policy-options policy-statement lb then load-balance per-packet


2)advertise the best external routes
set protocols bgp group MX140-IBGP advertise-external <<<configured on iBGP session between the MX140s

- BGP by default advertises only overall best-path to neighbours (to save memory) so if MX140-A has a prefix-X say with a shorter AS_PATH and advertises it to the neighbouring MX140-B -then that MX140-B, even though it has a route for prefix-X, although with longer AS_PATH, it would by default shut up and not tell MX140-A about it. So MX140-A wouldn't know there's a possible backup path it could use for BGP-PIC fast reroute.
So the "advertise best external" feature modifies the default behaviour and in addition to the overall best path a best path among all the eBGP paths is selected and advertised.


3)enable "provider edge link protection"
set routing-instances Internet protocols bgp group toTransit family inet unicast protection
set routing-instances Internet protocols bgp group toTransit family inet6 unicast protection


4)check
show route 1.1.1.6 extensive
-at the last tabbed section concerning the indirect next-hops
Next hop: ELNH Address 0x9240a74 weight 0x1, selected  <<<<<your primary next-hop to Transit ISP
Next hop: 10.1.1.26 via ge-2/0/2.0

Next hop: ELNH Address 0x92413a8 weight 0x4000 <<<<your backup next-hop to the other MX104
Next hop: 10.1.1.17 via ge-2/0/1.0
Label operation: Push 299840, Push 299776(top)


5)always prefer eBGP over iBGP*
set policy-options policy-statement FROM_TRANSIT term INGRESS_POLICY_A then preference 169 <<or whatever works for you

-by default,
If the MX140-A from our previous example loses its Transit link it will (via BGP-PIC) immediately reroute traffic to MX140-B
However by default MX140-B has a best path via MX140-A -so until it receives withdrawn from MX140-A it'll loop traffic back to MX140-A.
That's why you want MX140-B to prefer it's local exit.

*not sure what was Juniper and ALU thinking when they came up with the same protocol preference for eBGP and iBGP routes, there's a ton of reasons why you always want to prefer closest AS-EXIT.


Caveats:
"vrf-table-label" must be enabled at the routing-instance on the MX140s - just another stupidity in this script kiddie OS of Junos
Please note the advertise best external feature will cause increased RP RAM utilization


Sorry about the rants, just can't help it.
If Juniper is reinventing the wheel why wouldn't they make it circle shaped is just beyond my comprehension.

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 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.