JunOS config yacc grammar?

Thu Aug 24 17:22:04 UTC 2023

It may have been covered already, but another place to look is at code for
Batfish

https://github.com/batfish/batfish

https://www.batfish.org/

Its goal. and there are even podcast episodes that cover it:

https://www.podchaser.com/podcasts/episode-archive-packet-pushers-1755/episodes/heavy-networking-658-using-bat-156733916

https://blog.ipspace.net/2019/09/intent-based-networking-with-batfish-on.html

was to parse configs and out of that derive overall topology forwarding
graph and do config verification, so the tool itself may be of some use,
but for their parsing they use ANTLR, so you can reuse some of the code.

Which would be a pretty useful functionality, because then you could build
router stack independent policy processors and verification.

And it would be nice to have RC9067 policy parser and compiler into
proprietary config schema of one's choice.  With some verification.

Yan

On Thu, Aug 24, 2023 at 1:04 PM Warren Kumari <warren at kumari.net> wrote:

>
>
>
>
> On Thu, Aug 24, 2023 at 10:10 AM, Christopher Morrow <
> morrowc.lists at gmail.com> wrote:
>
>> On Tue, Aug 22, 2023 at 11:39 PM Grant Taylor via NANOG <nanog at nanog.org>
>> wrote:
>>
>> On 8/21/23 7:09 PM, Diogo Montagner wrote:
>>
>> I would first try to understand what you are trying to achieve. JUNOS is
>> very flexible on this front and I am wondering why you think yacc is the
>> right way to achieve what you are trying to do.
>>
>> Drive by comment:
>>
>> Perhaps the OP is trying to parse a (pile of) config file(s) downstream
>> of the generation thereof and has no ability to alter their generation.
>>
>> this is a common problem (or is common when I look at things, perhaps I'm
>> looking wrongly, but...)
>> I'd love to have something that parsed all of my device type configs and
>> output the results into a
>> 'database' that i could then ask questions of like:
>> "Hey, what NTP servers are configured on all devices?"
>> "Hey, which devices have this <access-list/firewall/user> configured on
>> them?"
>>
>>
>>
>
> Isn't this YANG/NETCONF, and squish it all into DB/directory full of files?
>
> Basically a more standardized format for representing device
> configurations / states?
>
> W
>
>
> There are a host of other things I could ask those are but 2 simple
>> examples, and YES I can
>> grep/sed/awk|sort|uniq|sort-rn my way to success for the 2 examples I
>> provided... but really
>> that's NOT the way I want to do this, and I do really have a bunch of
>> other questions I'd
>> like to ask, regularly, to solve rollout-of-new-feature / compliance /
>> legal / troubleshooting / etc
>> questions.
>>
>> In looking around there are examples of some of this, in a way, the most
>> common thing
>> I end up looking at, and getting sad about, is some java monstrosity
>> (who's name escapes me)
>> but has shown up in a few nanog presentations over the years... it makes
>> me sad because it's
>> not super useful in my world :( 'hard to use' is probably the best way to
>> describe it.
>>
>> One note about XML and Juniper, the schema changes by OS version, it
>> changes quite a bit :(
>> You CAN parse through it reasonably well with python lxml.Etree, because
>> (I think) python's parse
>> is VERY forgiving. If you attempt this path with golang :( you will be
>> sad, very sad :( because
>> the go->xml world is very 'build a struct of structs that mirrors the xml
>> tree' and 'changes at every
>> OS version' means now you have a LOT of versions of that :( maintenance
>> gets back to saku's
>> comment about feature velocity :(
>>
>> I do see:
>> https://pypi.org/project/juniper-nxpy/
>>
>> which may be useful to you as well Lyndon.
>> (I'd also point to tftp as not being the super best option from a
>> security and reliability perspective,
>> but if that's what you've got that's what you've got... you COULD have
>> the switch cronjobs curl/post
>> to an https destination with little hard work, and a gain in
>> reliabilty/security)
>>
>> -chris
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230824/f7b40860/attachment.html>