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.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
