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.<br>
<br>For example,<br>protocols {<br> bgp {<br> group PRIVATE-PEER {<br> delete: neighbor 1.1.1.2;<br> }<br> }<br>}<br><br>Works fine from a text standpoint. If you are using xml, you have to do something like <br>
...<br><neighbor delete="delete"><br> <name>1.1.1.2</name><br></neighbor><br>...<br><br>
<br><div class="gmail_quote">On Tue, Mar 6, 2012 at 2:36 PM, Robin Pimentel <span dir="ltr"><<a href="mailto:robin@pimentel.me">robin@pimentel.me</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
<br><div class="gmail_quote"><div><div class="h5">On Mon, Mar 5, 2012 at 12:52 AM, Vladimir Prokofyev <span dir="ltr"><<a href="mailto:themightywisp@gmail.com" target="_blank">themightywisp@gmail.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
Hi.<div><br></div><div>I have some suggestions for JUNOS-style configuration of rtconfig. Would be nice if someone more skilled than me could implement them.</div><div><br></div><div>1. "load set" configuration style.</div>
<div>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.</div>
<div>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.</div><div><br>
</div><div>2. Ability to specify a VR for a peer.</div><div>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.</div><div>If nothing is set - leave default.</div>
<div>Cisco-style would also benefit from this feature.</div><div><br></div><div>3. IPv4/IPv6 prefix lists in separate policies.</div><div>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.</div>
<div><br></div><div>Those three are the only things that separate me from peer update automatisation heaven :) or so I think at the moment.</div>
<br></div></div>_______________________________________________<br>
irrtoolset mailing list<br>
<a href="mailto:irrtoolset@lists.isc.org" target="_blank">irrtoolset@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/irrtoolset" target="_blank">https://lists.isc.org/mailman/listinfo/irrtoolset</a><br></blockquote></div><br>
</blockquote></div><br>