I agree with the yang approach. I would probably convert to using Yang and download the yang files for whatever code version you are running. For every code version you can download the yang files.

Then you have a choice to decide, either right a yang to yacc conversion tool or find one, or think about switching to a netconf approach or ODL/restconf -> netconf style approach depending on how you are using the yacc files today as that will auto check and verify basics and reject non compliant configs to some level.

On Tue, Aug 22, 2023 at 9:36 AM Diogo Montagner <diogo.montagner@gmail.com> 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.

If no one (or very few) these days is using yacc grammar for parsing router configs, that should be a good indication whether you are on the right path or not.

As already pointed out, navigating the XML trees or JSON structures would be much easier than writing a yacc grammar parser.

Alternatively, I would look into the YANG files: https://github.com/Juniper/yang

But without understanding what you are trying to do, this is just another suggestion.

./diogo -montagner
JNCIE-SP 0x41A

On Tue, 22 Aug 2023 at 09:53, Lyndon Nerenberg (VE7TFX/VE6BBM) <lyndon@orthanc.ca> wrote:
Nick Hilliard writes:

> No need to reinvent that wheel:
>
> root@foo> show configuration | display xml
> root@foo> show configuration | display json

That doesn't quite work for this scenario. It would mean ssh-ing
to the switch to grab it, and that's pretty locked down. We already
have cron jobs running on the switches that tftp the config file
to a server, and I'd prefer to leverage off that.

Also, the yacc parser would let me do some validation checks
before we push new configs.

--lyndon