You got me wrong at some point.<div>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.</div><div>I'm perfectly comfortable with deleting old BGP-peers manually.</div>
<div><br></div><div>I thought only about deleting policies before creating new ones.</div><div>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.</div>
<div><br></div><div>That's why there should be an option to delete old policy before creating new one, like in cisco-style config.</div><div><br><div class="gmail_quote">2012/3/7 Robin Pimentel <span dir="ltr"><<a href="mailto:robin@pimentel.me">robin@pimentel.me</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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>...<div class="HOEnZb"><div class="h5"><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" target="_blank">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>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>
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>
</div></div></blockquote></div><br></div>