On 5/22/2018 11:46 AM, Brian Rak wrote:
On 5/22/2018 10:03 AM, Brian Rak wrote:
On 5/22/2018 12:58 AM, Phil Shafer wrote:
Brian Rak writes:
The downside seems to be that these can blow up the router somehow...
Not blow up, but obfuscate. Imagine a user (or support person) who
is unaware that ephemeral databases are in use and resorts to pulling
out hair, muttering profanity, and sticking pins in their "Mr. Phil
Voodoo Doll" (tm) [batteries sold separately] when their "show
configuration" output doesn't correlate to their true operational
state. The warning is more about "yes, I'm aware" than about
voiding warranties, explosions, or sharks with lasers.
Thanks,
Phil
Ah, I can imagine a number of situations where using an ephemeral
configuration can cause all sorts of confusion. At least for us, the
efficiency advantages definitely outweigh the additional complexity
here.
Thanks!
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Well, actually they can blow up the router too. I just managed to
crash the routing process by committing an invalid bgp community to an
ephemeral config:
This takes out routing until you delete it:
<config>
<configuration>
<policy-options>
<community>
<name>cl-FROM-AS13030</name>
<members>
large:20473:300:13030
</members>
</community>
</policy-options>
</configuration>
</config>
This works fine:
<config>
<configuration>
<policy-options>
<community operation="replace">
<name>cl-FROM-AS13030</name>
<members>large:20473:300:13030</members>
</community>
</policy-options>
</configuration>
</config>
Under normal configuration mode, the former isn't actually accepted.
Junos seems to be parsing the former as:
policy-options {
community cl-FROM-AS13030 members "
large:20473:300:13030\n ";
}
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Trip report:
Don't use these for massive IRR configs.
There's seemingly no garbage collection done on IRR configs, so you'll
be having to wipe the database via shell and start over around once a
week (we've got a config that's about 100k lines, and we only change the
BGP peers that actually have changes in IRR)
They have a size limit of 400mb, and that's pretty easy to hit. Once you
hit that size limit, you'll start getting weird errors back when
changing the normal configuration (it *seems* like it ends up committing
a fraction of the ephemeral configs, so for us it complaints about
missing communities and policy statements)
I'm considering changing over to prefix-lists (instead of
route-filter-lists), and moving to the dynamic DB instead. I'm not even
sure if this will help :/
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
