suggestions for JUNOS rtconfig

Vladimir Prokofyev themightywisp at gmail.com
Wed Mar 7 10:15:26 UTC 2012


You got me wrong at some point.
I don't want it to delete old/removed peers. For one, how it would
determine if a peer is removed? It has to have some old/new routing policy
check/comparison tool.
I'm perfectly comfortable with deleting old BGP-peers manually.

I thought only about deleting policies before creating new ones.
Consider this for example - you have two entries in rtconfig configuration
- first results in adding community 100:100, and second 200:200. When
rtconfig builds first configuration, it will use policy 101 for first peer,
and policy 102 for second. Now let's imagine that for some reason order of
those two enries is switched. Rtconfig will build new configuration, where
policy 101 will add community 200:200, and policy 102 will add 100:100. By
itself, this new configuration is perfectly fine, but due to the nature of
"load replace", new commited config will result in policy 101 adding both
community 100:100 and 200:200, and the same will go for policy 102, which
will shred your configuration and do horrible things with routing policy.

That's why there should be an option to delete old policy before creating
new one, like in cisco-style config.

2012/3/7 Robin Pimentel <robin at pimentel.me>

> 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 1.1.1.2;
>     }
>   }
> }
>
> Works fine from a text standpoint.  If you are using xml, you have to do
> something like
> ...
> <neighbor delete="delete">
>    <name>1.1.1.2</name>
> </neighbor>
> ...
>
>
>
> On Tue, Mar 6, 2012 at 2:36 PM, Robin Pimentel <robin at pimentel.me> 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 gmail.com> 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 lists.isc.org
>>> https://lists.isc.org/mailman/listinfo/irrtoolset
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/irrtoolset/attachments/20120307/9db3cab0/attachment-0001.html>


More information about the irrtoolset mailing list