Posted on December 18, 2018 9:48 pm
 |  Asked by Anand Balakrishnan
Print Friendly, PDF & Email

Hello All,

I wanted to parse some values from eAPI output of “show running-config” of a device. I have attached the sample response from one of my device. In this, the commands are not split in “key” and “value” format. I.e. for eg. “ip address” should be the “key” and actual IP should be its “value”. But ip address and actual IP coming in “key” part and value part shows “null”. Is there an alternate way to utilise this output to parse the value? Also when can we expect show run output in parsable format? Thanks in advance!

Posted by Adam Levin
Answered on December 18, 2018 10:03 pm

Can you request more specific details from the API using, for example, “show interfaces Management1”? The show interfaces output will be more parse-able than the show running-config as a whole.

Marked as spam
Posted by Alexis Dacquay
Answered on December 19, 2018 1:57 pm

Hi Anand,

You would get what you want elsewhere than the running-config.

Is there anything else than IP addresses you are looking for?

This is the complete running-configuration, showing each line (complete line) as an entire key indeed, to keep it simple. The discrete values are in their relevant key binding in other command outputs.
Everything is available as Key:value, actually there is MUCH MORE than just the running config settings available, but they are shown in the relevant individual “show” commands outputs/queries.

It is not correct that ““ip address” should be the “key” and actual IP should be its “value””, because what would you do of a command like “ip address secondary” ? How would you manage the “secondary” value? And what about even longer commands like “ip name-server vrf default”?
It is there:

#show ip name | json
“v4NameServers”: [
“v6NameServers”: []

In summary, the running-config is just the list of the config commands,

The goal of the “sh run” output is to be fairly easy to digest by human eye. The real FULL config is shown in “show run all“.

For example, if you want interface IP detail, the best place is not the running configuration but the actual interface details:

Note the support of secondary and virtual IP addresses as well.

arista#show interfaces ma1 | json
"interfaces": {
"Management1": {
"lastStatusChangeTimestamp": 1545225224.4853666,
"lanes": 0,
"name": "Management1",
"interfaceStatus": "connected",
"autoNegotiate": "success",
"burnedInAddress": "00:1c:73:ee:c7:32",
"mtu": 1500,
"hardware": "ethernet",
"duplex": "duplexFull",
"bandwidth": 1000000000,
"forwardingModel": "routed",
"lineProtocolStatus": "up",
"interfaceAddress": [
"secondaryIpsOrderedList": [],
"broadcastAddress": "",
"virtualSecondaryIps": {},
"dhcp": false,
"secondaryIps": {},
"primaryIp": {
"maskLen": 22,
"address": ""
"virtualSecondaryIpsOrderedList": [],
"virtualIp": {
"maskLen": 0,
"address": ""
"physicalAddress": "00:1c:73:ee:c7:32",
"description": ""

Thanks Alexis for the detailed explanation. I agree with your points too. My intention was to utilise the config backup (which is anyway i have to take to store it) to understand device characteristics. I was aware about alternate show commands which can provide necessary information, but for that i need to create separate device call.

(Anand Balakrishnan at December 20, 2018 12:54 pm)

Post your Answer

You must be logged in to post an answer.