arista ssh access.

[thomasbridge74]

As discussed in #1014 I'm starting work on allowing the EOS module to use ssh as a transport rather than HTTP/HTTPS. This does necessitate some additional if statements within the code base.

So far I've managed to get this working to the extent we can connect to an Arista device using the ssh as the underlying transport. I've updated a number of getter functions (not all yet) as well as the is_alive() function to cover the case where we're using ssh as the transport. This PR is very much a WIP and (in my view) is not ready for committing to the develop branch but given there's still an amount of effort involved (the rest of the getters, ping and traceroutes, not to mention the configuration support options I've not even started to look at), I wanted to submit something for feedback!

[thomasbridge74]

I've now updated as per 2ff4e21 the get functions that do not try to parse the show running-config output.

This still excludes the following functions on Arista that use them:

• "get_bgp_config"
• "get_bgp_neighbors",
• "get_bgp_neighbors_detail",
• "get_config",
• "get_ntp_severs",
• "get_snmp_information",

I also need to look at the following functions for further testing:

• "get_route_to",
• "get_users"

In get_users it appears to be that the newer version of vEOS I'm testing against (4.26.1F) does support JSON in the output for the command but is using a newer command syntax.

[mirceaulinic]

Nice work @thomasbridge74! This looks good to me, @ktbyers any opinion?

[mirceaulinic]

We already have an optional argument, eos_fn0039_config, whose value you can access it from self.fn0039_config - doesn't have to be per-method. Or could you explain what are you trying to do here?

[thomasbridge74]

So obviously the main goal is to be able to convert commands between the old and new syntax.

Digging into how this was done for EAPI connections, I found inside the run_commands method of the Node inside the pyeapi_syntax_wrapper.py file the above code, and basically copied it to maintain the logic.

I assume your recommendation here is drop the line

fn0039_transform = kwargs.pop("fn0039_transform", True)

and replace the following if statement with

if self.fn0039_config

Happy to do that - it looks like I missed the significance of that setting as I poked around the code.

[thomasbridge74]

While I've done the get functions, I still need to do the following:

1. ping.
2. traceroute
3. load_template

UPDATE: these are now done! - Oct 19th

as well as update the neccessary functions for the configuration support matrix

[thomasbridge74]

I've completed the commands for configuration management.

One caveat: in order to get the SSH version of the session management to work, I've changed the logic in commit config from:

configuration session <sessionid>
commit [timer <revert_in>]

to

configuration session <sessionid> commit [timer <revert_in>]

(ie a oneline command instead of two lines). This is because it's a little messy using napalm with two lines considering that effectively enters configuration mode - which would also need to be quit but changes the prompt as well. This may have issues. I'll raise a question with my companies Arista Sales Architect.

[thomasbridge74]

I had confirmation from the Arista account contact who advised that

There shouldn't be any issues as the single line approach was implemented with config session timers from day 1 in 4.18.0F

So I'm happy leaving this modified approach if that's okay?

[mirceaulinic]

There shouldn't be any issues as the single line approach was implemented with config session timers from day 1 in 4.18.0F

I'm not a big fan of this, as this means only people running EOS 4.18.0F or newer will be able to use this. But otoh, I can't see a better workaround, so I'm fine to proceed. I'd like to request however to document this caveat. Thanks @thomasbridge74!

[thomasbridge74]

just checking in - is there anything you're waiting on from me to merge this?

Two things with regard to the issue around 4.18.0F or newer

1. Arista are only supporting 4.20F and above now.
2. The config session calls won't work with earlier versions regardless of EAPI or SSH connection as it didn't exist. Nothing in my patch should therefore be different depending on transport.

[mirceaulinic]

Hi @thomasbridge74 - yes, I think we want a documented caveat for this.

1. Arista are only supporting 4.20F and above now.

True, but I wouldn't assume there aren't people still EOS older than 4.20F (in fact, I'm absolutely sure there are). Here in NAPALM, is not our job to limit this.

2. The config session calls won't work with earlier versions regardless of EAPI or SSH connection as it didn't exist. Nothing in my patch should therefore be different depending on transport.

No so sure about that: in the past, I've personally used NAPALM with EOS versions earlier than 4.18 which made use of the configue sessions (this behaviour didn't change over the last 6 years at least).

[scetron]

Hello @thomasbridge74! I have an interest in getting napalm to work with arista over ssh as well. I wanted to try out your extensions. I've noticed that I have a problem with opening connections to devices with optional args, specifically an alternative port. I believe the issue is the transport_class being a string doesn't allow all of the optional args to make it to the netmiko_optional_args dict that is used.

I can share the full traceback if necessary and happy to have a chat or take a look my self if necessary. Thanks!

[scetron]

transport_class as a string runs into an issue on line 150 and again in line 155 where a string only has self, so no optional args get passed into netmiko_optional_args.

[thomasbridge74]

I've merged the changes to the napalm/eos/eos.py file.

[ktbyers]

This PR:

#1613

Will affect these changes.

[bewing]

This might have to be | json version 2. I can't remember exactly which version/reversion of JSON output EAPI uses. Might have to ask Arista for exact clarification.

[mirceaulinic]

CC @thomasbridge74 - I let you investigate this, feel free to come up with a subsequent PR if needed.

[thomasbridge74]

@mirceaulinic I've updated the pull request with the update to the driver file from @scetron but not including his (very substantial) suite of tests. I've also made a couple of minor updates to the documentation.

With regard to the comment about 4.18.0F versus earlier versions, it would appear it was specifically the config timer that was introduced with 4.18.0F - I've included a comment about that in the documentation updates. I can also be pinged on the NTC Slack if you think that might be a quicker path to resolving the issues here.

[mirceaulinic]

This looks good to me.

Thanks for your work @thomasbridge74! This will be included in release 4.0.0, which I target to release very soon.

[AshikKuppili]

@mirceaulinic, with this can we use SSH for EOS like NXOS_SSH , what should be driver name for this
I tried today , but some how it failed for EOS , what should driver name
Error I am getting is ""SSL Handshake not properly done"" something like that

[ktbyers]

@AshikKuppili Try setting the transport in optional_args to be "ssh":

https://github.com/napalm-automation/napalm/blob/develop/napalm/eos/eos.py#L144

[SkyFields]

@AshikKuppili Try setting the transport in optional_args to be "ssh":

https://github.com/napalm-automation/napalm/blob/develop/napalm/eos/eos.py#L144

Hello, I am trying to use transport SSH for Arista with napalm-ansible, passing optional_args ssh, it looks like working, but I keep receiving an error

FAILED! => {"changed": false, "msg": "cannot close device connection: 'AristaSSH' object has no attribute 'connection'"}

example of my task

- name: get facts from device
      napalm_get_facts:
        hostname: '{{ ansible_host }}'
        username: '{{ ansible_user }}'
        dev_os: '{{ os }}'
        password: 
        optional_args:
          port: '{{ ansible_port }}'
          transport: 'ssh'
        filter: 'facts,interfaces,bgp_neighbors'
      register: result