Hey Andrew,
We largely do not use any in-device tooling for configuration generation,
as that creates vendor dependencies we try to add sparingly. All data is
formal data in SQL and we turn this formal data into informal router
configuration via templates.
We consider router configurations immutable, we never change
configurations, we only reassign it. Not unlike in purely functional
programming.
On Wed, 20 Jun 2018 at 06:44, Andrew Thrift <and...@networklabs.co.nz>
wrote:
> Hi Saku,
>
> I was just wondering how you are populating:
>
> source-prefix-list {
> rsvp_neighbors;
> }
>
> Manually, or via an apply-path ?
>
>
> Regards,
>
>
>
>
> Andrew
>
> On Wed, Jun 20, 2018 at 1:03 AM, Saku Ytti <s...@ytti.fi> wrote:
>
>> Hey Rei,
>>
>> Great catch.
>>
>> We have this:
>> term rsvp:self_ping {
>> from {
>> source-prefix-list {
>> rsvp_neighbors;
>> }
>> protocol udp;
>> destination-port 8503;
>> }
>> then {
>> count rsvp:self_ping;
>> accept;
>> }
>> }
>>
>>
>> This is really great feature, because previously make-before-break was
>> based on timer, with no idea if actually new LSP has been established or
>> if
>> old LSP is no longer used. So it could very easily lead to situation where
>> you push traffic to new LSP which isn't working or remove old LSP still
>> being used.
>>
>> self_ping removes the problem of pushing traffic to LSP which is not up
>> yet
>> and 'optimize-adaptive-teardown' removed problem of removing LSP still
>> being used. Making both sides triggered instead of arbitrary timer.
>>
>>
>>
>>
>> On Tue, 19 Jun 2018 at 17:56, Rei Alexandra Aoyama <
>> rei.a.aoy...@gmail.com>
>> wrote:
>>
>> > Hi Ian,
>> >
>> > 16.1R7 or 17.3R3 should be good. If you use MPLS RSVP, make sure you
>> look
>> > up MPLS self-ping which is a new feature in 16.1 - especially if you
>> have
>> > lo0 firewall. Otherwise you will have issue with LSP switchover. I think
>> > there is a PSN on that. I will look it up.
>> >
>> > ReiA
>> >
>> > On Sat, Jun 16, 2018 at 4:34 AM Ian Goodall <bbaa4...@gmail.com> wrote:
>> >
>> > > Hi All
>> > >
>> > > Were looking to upgrade JUNOS on some of our older PE MX480/960
>> running
>> > pre
>> > > 15 code. We've had success on the 17.x train in P roles.
>> > >
>> > > 15.1 is recommended by JTAC but it's EOL in under 12 months.
>> > >
>> > > Historically picking a recent version with a high R release was
>> always a
>> > > good starting point. The release strategy has changed somewhat and
>> most
>> > > versions now don't go beyond R2.
>> > >
>> > > What's everyone deploying currently?
>> > >
>> > > Thanks
>> > >
>> > > IG
>> > > _______________________________________________
>> > > juniper-nsp mailing list juniper-nsp@puck.nether.net
>> > > https://puck.nether.net/mailman/listinfo/juniper-nsp
>> > >
>> > _______________________________________________
>> > juniper-nsp mailing list juniper-nsp@puck.nether.net
>> > https://puck.nether.net/mailman/listinfo/juniper-nsp
>> >
>>
>>
>> --
>> ++ytti
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>
>
--
++ytti
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
