Mailing List Archive: nsp: juniper

Bulk Provisioning Question

Index | Next | Previous | View Threaded

skeeve+junipernsp at eintellego

Apr 29, 2012, 8:31 PM

Post #1 of 3 (297 views)
Permalink

Bulk Provisioning Question

Hey all,

We have a client who is using MX80s in front of a Vmware Cluster.

They are using the XML provisioning API to manage the provisioning on
VLAN's, Layer 3 and Layer 2 services. Not that important what is being
provisioned though.

The issue is they want to be able to rapidly provision without causing
conflicts between provisioning processes and also NetOps staff doing
changes.

An an example, there are 4 processes at the moment which are creating
juniper config (let's keep it simple and say VLAN's with a layer 3 - which
is an ae unit, then a bridge domain, then an IRB.

The config being applied doesn't conflict (or at least shouldn't), but the
real issue comes when wanting to commit the changes.

Having 4 processes simultaneously wanting to commit is going to cause
havoc, and I am trying to find out if someone out there has an easier way
to do this.

We've considered having a single process using edit exclusive, but this is
going to slow things down significantly.

I've been looking at 'edit private' as an option, which might be
interesting, but if there are a dozen changes done, and you commit, and
there is an error somewhere, tracking that down will be a pita.

I've also thought of loading the config into a file, putting it onto the
box, then bulk importing... but this also seems an issue to catch problems.

Any thoughts? Thanks all if anyone have any ideas.

*Skeeve Stevens, CEO*
eintellego Pty Ltd
skeeve [at] eintellego ; www.eintellego.net <http://www.eintellego.net.au>

Phone: 1300 753 383 ; Fax: (+612) 8572 9954

Cell +61 (0)414 753 383 ; skype://skeeve

facebook.com/eintellego

twitter.com/networkceoau ; www.linkedin.com/in/skeeve

PO Box 7726, Baulkham Hills, NSW 1755 Australia

The Experts Who The Experts Call
Juniper - Cisco – Brocade - IBM
_______________________________________________
juniper-nsp mailing list juniper-nsp [at] puck
https://puck.nether.net/mailman/listinfo/juniper-nsp

phil at juniper

Apr 30, 2012, 4:56 AM

Post #2 of 3 (258 views)
Permalink

Re: Bulk Provisioning Question [In reply to]

Skeeve Stevens writes:
>We've considered having a single process using edit exclusive, but this is
>going to slow things down significantly.

Commits are serialized, so they are effectively a single process
on the box. Using "edit private" will likely decrease performance,
since internally it's doing diff/patch processing at commit time.

I would use the <lock-configuration> RPC ("configure exclusive")
and consider pushing all changes via a single external process
that can "batch" them together, if you can trust the patches.

Also I always suggest putting application-based configuration into
a configuration group so that (a) it's easy to see what's application
provided and what's hand configured, (b) it's easy to "load replace"
that config group with new application data, and (c) the human user
can override the application using the foreground config. It's
also easy to test application by turning off the "apply-groups" for
that app's config group. Not required, but something that has
worked well for me.

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

skeeve+junipernsp at eintellego

Apr 30, 2012, 6:41 AM

Post #3 of 3 (264 views)
Permalink

Re: Bulk Provisioning Question [In reply to]

Phil,

Thanks for the advice.

*Skeeve Stevens, CEO*
eintellego Pty Ltd
skeeve [at] eintellego ; www.eintellego.net <http://www.eintellego.net.au>

Phone: 1300 753 383 ; Fax: (+612) 8572 9954

Cell +61 (0)414 753 383 ; skype://skeeve

facebook.com/eintellego

twitter.com/networkceoau ; www.linkedin.com/in/skeeve

PO Box 7726, Baulkham Hills, NSW 1755 Australia

The Experts Who The Experts Call
Juniper - Cisco – IBM

On Mon, Apr 30, 2012 at 21:56, Phil Shafer <phil [at] juniper> wrote:

> Skeeve Stevens writes:
> >We've considered having a single process using edit exclusive, but this is
> >going to slow things down significantly.
>
> Commits are serialized, so they are effectively a single process
> on the box. Using "edit private" will likely decrease performance,
> since internally it's doing diff/patch processing at commit time.
>
> I would use the <lock-configuration> RPC ("configure exclusive")
> and consider pushing all changes via a single external process
> that can "batch" them together, if you can trust the patches.
>
> Also I always suggest putting application-based configuration into
> a configuration group so that (a) it's easy to see what's application
> provided and what's hand configured, (b) it's easy to "load replace"
> that config group with new application data, and (c) the human user
> can override the application using the foreground config. It's
> also easy to test application by turning off the "apply-groups" for
> that app's config group. Not required, but something that has
> worked well for me.
>
> Thanks,
> Phil
>
_______________________________________________
juniper-nsp mailing list juniper-nsp [at] puck
https://puck.nether.net/mailman/listinfo/juniper-nsp

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads