suggestions for JUNOS rtconfig

Robin Pimentel robin at
Tue Mar 6 23:05:02 UTC 2012

A quick clarification:  delete does work, but the syntax is more delicate.
For example to delete a neighbor you have to terminate the hierarchy with a
";" and exclude the contents "{...}" from the statement.  Of course you are
correct that someone would still have to implement it in a toolset, whether
home-grown, or otherwise.

For example,
protocols {
  bgp {
    group  PRIVATE-PEER {
      delete: neighbor;

Works fine from a text standpoint.  If you are using xml, you have to do
something like
<neighbor delete="delete">

On Tue, Mar 6, 2012 at 2:36 PM, Robin Pimentel <robin at> wrote:

> I'm sure you and others are aware of workarounds for 1).  One approach to
> try is to "replace:" at the "group" level of the hierarchy, or more
> generally: one level up.  Of course, this means one would have to
> programmatically have a way of populating the correct neighbors on a
> per-router, per-group basis (or derive it from the existing config), but it
> is one way.  Unfortunately, it also means you may be developing your own
> tool set :/ . I for one would like to see Junos implement the "delete:" tag.
> On Mon, Mar 5, 2012 at 12:52 AM, Vladimir Prokofyev <
> themightywisp at> wrote:
>> Hi.
>> I have some suggestions for JUNOS-style configuration of rtconfig. Would
>> be nice if someone more skilled than me could implement them.
>> 1. "load set" configuration style.
>> Current JUNOS configuration is compatible only with "load
>> merge/replace/override" style, which is not very usable. For example, there
>> isn't any "delete" statement before any configuration statement, which
>> means that every time you delete a peer from a list you have to manually
>> control you configuration update, or all policy lists shift numbers, and
>> configuration becomes incorrect.
>> For example, cisco-style configuration has a "no" statement before any
>> policy-map/prefix-list/etc, ensuring that there won't be any configuration
>> overlaps from old/new peers/configurations.
>> 2. Ability to specify a VR for a peer.
>> For example, I have some peers in separate VR, and it would be great to
>> have a config option that specifies VR for a peer.
>> If nothing is set - leave default.
>> Cisco-style would also benefit from this feature.
>> 3. IPv4/IPv6 prefix lists in separate policies.
>> Currently if I have two peers with single BGP-neighbour(same ASN) - one
>> IPv4 and one IPv6 - it creates single prefix-list for them both. This
>> configuration is unable to commit.
>> Those three are the only things that separate me from peer update
>> automatisation heaven :) or so I think at the moment.
>> _______________________________________________
>> irrtoolset mailing list
>> irrtoolset at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the irrtoolset mailing list