suggestions for JUNOS rtconfig
Robin Pimentel
robin at pimentel.me
Wed Mar 7 17:34:08 UTC 2012
Thanks for clarifying. I did misunderstand. I hope I am able to
understand it better this time around. Originally, I did not mean to
suggest that m work-around was compatible with rtconfig. I was offering a
work-around in lieu of the rtconfig feature request, which I hope gets
consideration. Outside of rtconfig, if you would like to consider a
work-around, I have modified junoscript example scripts to push configs
over SSL and XNM to do what you describe. In the situation you describe, I
have used both "load replace" on the cli and the modified tools I have
mentioned to push configurations from (for example) revision controlled
source files. A text configuration such as this is similar to what I push
to routers:
policy-options {
replace: policy-statement INTER-CONTINENTAL-EXPORT {
term next-hop-self {
from {
protocol bgp;
route-type external;
}
then {
community add THIS.REGION;
next-hop self;
next term;
}
}
/* shortened for brevity */
}
}
Here I have chosen to replace at the policy statement level, but the
replace tag will overwrite everything in the hierarchy below the level at
which it is placed. Hence, if you wanted to replace just the term, you
would move the replace tag to that level and that term would be re-written
(not merged).
Good luck with your projects.
Robin.
On Wed, Mar 7, 2012 at 2:15 AM, Vladimir Prokofyev
<themightywisp at gmail.com>wrote:
> 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
>>>>
>>>
>>>
>>
>
> _______________________________________________
> 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/054523e2/attachment.html>
More information about the irrtoolset
mailing list