[j-nsp] Optimizing the FIB on MX

[Raphael Mazelier]

Very interresting topic.

Some questions about your setup :

In 2) you set advertise-external, is it working the same by using 
multipath ?

In 3) you set 'unicast protection'. It is the same thing as PIC 'protect 
core' knob ?

If I understand correctly, before 15.1 PIC is only available on l3vpn, 
so my question is :

Is it advisable to run the dmz/internet table in a vrf/routing instance 
on juniper ? and what are the pros/cons of doing that ?

pros : PIC, more flexibily ?
cons : more complex setup, performance issue (I've heard some storie 
about that) ?

Best,

-- 
Raphael Mazelier

Le 18/02/2016 11:50, Adam Vitkovsky a écrit :

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