-
Notifications
You must be signed in to change notification settings - Fork 174
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"socket path does not exist or cannot be found" only when running cisco.ios.ios_bgp_address_family #682
Comments
Hi Gian! Long time no see 😄 I could be off on this but could you try libssh instead of paramiko?
Read this for more info: New LibSSH Connection Plugin for Ansible Network Replaces Paramiko Hope it works! |
Sorry about that. Bad research from my side. Figured you had a reason for using paramiko :) I noticed the trace says Have you tried increasing the timeout by adding the following to ansible.cfg:
It appears to me that the ios.bgp_address_family is a bit slower to start executing than other modules. Would you agree? But I must admit I'm not being very scientfic on this :) I'll look more into it. |
I did some research. The module is doing some heavy duty parsing on the neighbor statements which makes it appear slower than other modules and in some cases triggers the persistent connection idle timeout mentioned in the previous post. Increasing the timeout value should work, though. Could you verify @netexgb ? |
Hey @netexgb as @bentole suggested increasing the persistent connection timeout is definitely a good option, but the parsers for bgp_address_family should not be a core reason for the module to lose connection or the error you got. |
Hi @bentole I changed the command_timeout to 90 under [persistent_connection} to no avail. When I ran the playbook, I still got the error:
|
Thanks Gian! That is some major league BGP configuration :) @KB-perByte I havent spent much time looking into this, but I noticed by removing @netexgb I notice you're running a recent IOS-XE version. I feel like I am cheating on the IOS module by saying this, but have you considered ansible.netcommon.netconf_config? Sounds like a better fit for your configuration volume. Let me know if you need a sample. |
Hi @bentole I did consider using NETCONF however (a) not all our devices are on IOS-XE, and (b) that would require upgrading and changing our whole landscape to enable it :) |
Hi @KB-perByte ! I noticed you have a PR up that address this issue. I did some research and one of my customers are experencing same issues as @netexgb so I spent some time the other day digging into this. So what i could find so far is that there are two things that caught my attention. There's "catastrophic backtracking" issues with regular expressions when peer-group names are too long. Another issue is with the parser funcs inside the very core of ansible.netcommon. They have a potential for optimization. Too much to explain here so I have created a project to demonstrate this in a pure python environment here using @netexgb BGP configuration. As you (hopefully) can see running the optimized parser takes seconds while the original parser takes minutes. I also have a PR ready for this, but I'm wondering, are we even "allowed" to override ansible.netcommon funcs for custom optimization? the funcs in question are |
@bentole I appreciate you taking the time to investigate it, yes the parsers for bgp_address_family needed some defragmentation and the facts processing needed improvement. With the PR that I have added, the running time has come down significantly as a lot of config parsing heavy lifting is done via regex, not jinja templates which was the case previously. And, I am unsure about the part where you are asking about overriding netcommon functions for a particular use case? Taking about parse specifically we are looking at ways to optimize it for the faster crunching of config lines ( _any ideas or PRs are appreciated ) but overriding a function might work just fine for a specific collection you are looking at but may have consequences in performance of other collections relying on the same. |
Hi again @KB-perByte! I pulled your PR and ran it in my test case, but couldnt see any effects yet. I notice it's a WIP so I should probably not whine about it 😄 Anyhow, I put my PR #688 up. It differs from your approach by optimizing the parsing of the existing jinja2 templates and fixing the broken regex. It's tested against @netexgb configuration and playbook and it reduces the time by about 40 times the original. But I do agree, replacing jinja2 with regex is a better approach altogether so keep up the good work 😃 Oh and btw, @netexgb. To make the playbook above idempotent you should leave out unicast from the address-family when using VRFs. IOS will accept the command |
Hi @bentole Thank you for the suggestion. Once the programming has been optimized, I will give it a go without using safi: unicast in the playbook 👍 |
@KB-perByte I peeked at your PR and noticed you've done some serious crunching the last couple of days. Respekt! Since the WIP was removed I pulled and tested your changes using @netexgb's configuration and playbook and it brought down the deployment time on my system from about 8 minutes to mere seconds. So as far as I see it this issue is now fixed. I've closed PR #688. No need for a workaround by overriding superclasses when things are done properly 😄 Thanks for all the hard work! 😃 |
SUMMARY
Only when I run a "cisco.ios.ios_bgp_address_family" task I get the error "socket path does not exist or cannot be found", working with other cisco.ios modules is fine.
ISSUE TYPE
COMPONENT NAME
cisco.ios.ios_bgp_address_family
ANSIBLE VERSION
COLLECTION VERSION
CONFIGURATION
STEPS TO REPRODUCE
I just configured the YAML file as seen below and ran it against the Cisco Router and got the problem as shown below. The strange thing is, I also ran tasks using other cisco.ios modules, i.e. cisco.ios.ios_config and cisco.ios.ios_route_maps and they all work fine. The YAML configuration below is pretty simple, just wanting to add an aggregate-address command to no avail.
EXPECTED RESULTS
I would have expected the following configuration in the router:
DEBUGGING
The text was updated successfully, but these errors were encountered: