Mailing List Archive

Unit-ID's revisited / accessing committed configuration
Is it possible to somehow get the committed configuration as it looked
after commit-scripts were applied? I do not want the commit-scripts
re-run, I simply want to fetch the configuration as it was after all
scripts were run and the commit succeeded.

To explain why I need to do this, it is necessary to go back to the unit
ID problem I posted about earlier.

To reiterate, the challenge is to generate unit ID's for a bunch of
q-in-q interfaces like this:

unit 5239 {
encapsulation vlan-ccc;
vlan-tags outer 1559 inner 3;
input-vlan-map pop-pop;
output-vlan-map push-push;
}

I solved it, or so I thought, by keeping all configuration in
apply-macros, like this:

apply-macro eompls-1001089 {
inner 3;
interface ge-1/0/4;
outer 1559;
}

which then generates the above q-in-q interface as a transient-change.
The unit ID is simply the position of the apply-macro in the
configuration file + 5000, so this particular apply-macro happens to be
the 239th apply-macro.

It all works really well, in general. Except I had not considered what
happens if you remove an apply-macro. All is well if you remove the last
apply-macro, but if you happen to remove one of the first ones, every
interface below changes unit ID. The MX80 was less than happy about
hundreds of interfaces being torn down and rebuilt...

At this point it is tempting to give up on that design and "simply" add a
unit ID to the provisioning database and to the apply-macro. Keeping
them consistent is no fun at all.

However, I would like to give the dynamic ID's one more chance. If it is
possible to find out which unit ID the previous commit used for a
particular apply-macro, I can then reuse that unit ID. Since all the
changes my commit script does are transient, this seems to be a
challenging task.

Any help is really appreciated!


/Benny

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: Unit-ID's revisited / accessing committed configuration [ In reply to ]
show configuration | display commit-scripts

On Thu, Apr 26, 2012 at 7:53 AM, Benny Amorsen <benny+usenet@amorsen.dk> wrote:
> Is it possible to somehow get the committed configuration as it looked
> after commit-scripts were applied? I do not want the commit-scripts
> re-run, I simply want to fetch the configuration as it was after all
> scripts were run and the commit succeeded.
>
> To explain why I need to do this, it is necessary to go back to the unit
> ID problem I posted about earlier.
>
> To reiterate, the challenge is to generate unit ID's for a bunch of
> q-in-q interfaces like this:
>
>   unit 5239 {
>        encapsulation vlan-ccc;
>        vlan-tags outer 1559 inner 3;
>        input-vlan-map pop-pop;
>        output-vlan-map push-push;
>    }
>
> I solved it, or so I thought, by keeping all configuration in
> apply-macros, like this:
>
> apply-macro eompls-1001089 {
>    inner 3;
>    interface ge-1/0/4;
>    outer 1559;
> }
>
> which then generates the above q-in-q interface as a transient-change.
> The unit ID is simply the position of the apply-macro in the
> configuration file + 5000, so this particular apply-macro happens to be
> the 239th apply-macro.
>
> It all works really well, in general. Except I had not considered what
> happens if you remove an apply-macro. All is well if you remove the last
> apply-macro, but if you happen to remove one of the first ones, every
> interface below changes unit ID. The MX80 was less than happy about
> hundreds of interfaces being torn down and rebuilt...
>
> At this point it is tempting to give up on that design and "simply" add a
> unit ID to the provisioning database and to the apply-macro. Keeping
> them consistent is no fun at all.
>
> However, I would like to give the dynamic ID's one more chance. If it is
> possible to find out which unit ID the previous commit used for a
> particular apply-macro, I can then reuse that unit ID. Since all the
> changes my commit script does are transient, this seems to be a
> challenging task.
>
> Any help is really appreciated!
>
>
> /Benny
>
> _______________________________________________
> 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
Re: Unit-ID's revisited / accessing committed configuration [ In reply to ]
Tim Jackson <jackson.tim@gmail.com> writes:

> show configuration | display commit-scripts

Sorry, I forgot to mention the crucial detail: It has to be available to
a script. Unfortunately that command does not seem to have a junoscript
equivalent; "display commit-scripts view" does have a junoscript
equivalent but does not do what I need.


/Benny

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: Unit-ID's revisited / accessing committed configuration [ In reply to ]
>
> Sorry, I forgot to mention the crucial detail: It has to be available
> to
> a script. Unfortunately that command does not seem to have a junoscript
> equivalent; "display commit-scripts view" does have a junoscript
> equivalent but does not do what I need.
>

Junos 12.1 added new options for the <get-configuration> commit-scripts attribute, apply and apply-no-transients, that allow you to retrieve the post-commit-script configuration, and prior to Junos 12.1 you could always do something like <command> "show configuration | display xml | display commit-scripts" (be aware that the returned XML structure will be different than <get-configuration>), however, these work by running the configuration through the commit scripts again, so if you try to call them from a commit script you're liable to get a loop.

Why not just have your commit script automatically add the unit number to the apply-macros. i.e. if the unit number is already present in the macro then use it for the logical interface, but if it is missing then figure out the first unused number, use it for the interface, and record it in the macro.


_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: Unit-ID's revisited / accessing committed configuration [ In reply to ]
Curtis Call <ccall@juniper.net> writes:

> Junos 12.1 added new options for the <get-configuration>
> commit-scripts attribute, apply and apply-no-transients, that allow
> you to retrieve the post-commit-script configuration, and prior to
> Junos 12.1 you could always do something like <command> "show
> configuration | display xml | display commit-scripts" (be aware that
> the returned XML structure will be different than
> <get-configuration>), however, these work by running the configuration
> through the commit scripts again, so if you try to call them from a
> commit script you're liable to get a loop.

Ah clever idea, but you are right, it would loop. It could only work if
there was a way to get the actual configuration as it was applied after
the commit scripts of the last commit, without having to actually rerun
the commit script.

> Why not just have your commit script automatically add the unit number
> to the apply-macros. i.e. if the unit number is already present in the
> macro then use it for the logical interface, but if it is missing then
> figure out the first unused number, use it for the interface, and
> record it in the macro.

Yes that sounds like a workable solution.


Thank you!


/Benny
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp