Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: nsp: juniper

Unit-ID's revisited / accessing committed configuration

 

 

nsp juniper RSS feed   Index | Next | Previous | View Threaded


benny+usenet at amorsen

Apr 26, 2012, 5:53 AM

Post #1 of 5 (841 views)
Permalink
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 [at] puck
https://puck.nether.net/mailman/listinfo/juniper-nsp


jackson.tim at gmail

Apr 26, 2012, 5:59 AM

Post #2 of 5 (790 views)
Permalink
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 [at] amorsen> 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 [at] puck
> https://puck.nether.net/mailman/listinfo/juniper-nsp

_______________________________________________
juniper-nsp mailing list juniper-nsp [at] puck
https://puck.nether.net/mailman/listinfo/juniper-nsp


benny+usenet at amorsen

Apr 26, 2012, 6:30 AM

Post #3 of 5 (788 views)
Permalink
Re: Unit-ID's revisited / accessing committed configuration [In reply to]

Tim Jackson <jackson.tim [at] gmail> 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 [at] puck
https://puck.nether.net/mailman/listinfo/juniper-nsp


ccall at juniper

Apr 26, 2012, 10:20 AM

Post #4 of 5 (784 views)
Permalink
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 [at] puck
https://puck.nether.net/mailman/listinfo/juniper-nsp


benny+usenet at amorsen

Apr 26, 2012, 1:07 PM

Post #5 of 5 (779 views)
Permalink
Re: Unit-ID's revisited / accessing committed configuration [In reply to]

Curtis Call <ccall [at] juniper> 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 [at] puck
https://puck.nether.net/mailman/listinfo/juniper-nsp

nsp juniper RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.