Add Cisco Nexus support about capirca HOT 22 CLOSED

Hi,
Can you give me more details on what is different between the syntax?
I do not have a nexus device to test things out on.

Original comment by [email protected] on 23 Jun 2015 at 5:26

from capirca.

[deleted comment]

from capirca.

Our Nexus acl's are quite simple. The differences i found until now:

- Keyword 'extended' needs to be removed
- Protocol numbers need to be replaced by their respective name (eg 6 is tcp, 
17 is udp etc)
- Only when using in switchprofile mode (in that case acl's are automatically 
distributed between multiple switches) it is necessary to number the list 
entries. But not every Nexus user uses that i guess.

A (very) simple and dirty conversion script i use at the moment:
./aclgen.py
find ./ -iname '*.acl' | while read f
do
sed  -i 's/ extended / /g' "$f"
sed  -i 's/ 6 / tcp /g' "$f"
sed  -i 's/ 17 / udp /g' "$f"
head -n 4 "$f" > "$f".head
sed '1,4d' "$f" > "$f".sed 
nl -i10 -v10 -s "  " "$f".sed | grep -v " end" >> "$f".head
rm "$f".sed
mv "$f".head "$f"
done

Original comment by [email protected] on 24 Jun 2015 at 1:41

from capirca.

One other difference is, NX-OS supports CIDR notation for subnets.
I do have a language generator for NX-OS - I have uploaded the relevant diffs to my git tree at https://github.com/nyanto/capirca - feel free to check it out.
The module is called cisconx.py.
There are quite a few other changes to the cisco.py module which we use but are unrelated to the cisconx module - unfortunately, some minimal changes to the cisco.py module are required for the cisconx.py module to work. I can break those out in a smaller patch if needed.

from capirca.

Not sure if this is relevant anymore. This issue was imported from the old code.google.com site and I am unsure if the original person is looking at these comments.

@nyanto I have not worked with the NX series much but is CIDR notation actually required? ciscoxr.py and cisconx.py look awfully similar besides for just that.

from capirca.

I don't think the CIDR notation is required to enter an ACL on NX.
But it is converted to CIDR in the configuration, and we have a
verification step where we require the configured ACL on the device to
match the filter. I agree with your assessment that this issue is probably
not too relevant to most people.

On Wed, Apr 20, 2016 at 12:52 PM, ankenyr [email protected] wrote:

Not sure if this is relevant anymore. This issue was imported from the old
code.google.com site and I am unsure if the original person is looking at
these comments.

@nyanto https://github.com/nyanto I have not worked with the NX series
much but is CIDR notation actually required? ciscoxr.py and cisconx.py look
awfully similar besides for just that.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#39 (comment)

from capirca.

Actually that is good information to know. We have changed our generators before because they were outputting things that, while valid, would change when requesting the config after commit.

I have not worked on the XR systems myself but do they also take CIDR notation? If so then maybe unifying the XR and NX code and making a platform option would be a better way to handle this?

from capirca.

In my experience XR uses a syntax which is much closer to traditional Cisco
IOS - in our deployments, we have used the regular cisco generator and
massaged the output with a few sed string substitutions...
For consistency, I would probably like to see either all three (IOS, XR,
NX) handled as part of the cisco generator, or, XR and NX generators
derived from the generic cisco class, which is how I had implemented my NX
generator.

On Thu, Apr 21, 2016 at 3:05 PM, ankenyr [email protected] wrote:

Actually that is good information to know. We have changed our generators
before because they were outputting things that, while valid, would change
when requesting the config after commit.

I have not worked on the XR systems myself but do they also take CIDR
notation? If so then maybe unifying the XR and NX code and making a
platform option would be a better way to handle this?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#39 (comment)

from capirca.

We need this as well. I've taken a single commit from @nyanto's fork, commit c2d6c8 and am working on it now in a branch. This commit breaks some of the regression tests I added in PR #56, so I'll work with these changes to ensure they're backwards compatible with the existing code (that is, have the same behaviour), and will add some tests for Nexus ACL generation. I'll work with a teammate re the tests for these.

I'll push these changes up to my fork, at branch https://github.com/jzohrab/capirca/commits/wip_nxos. I'll rebase everything when it's done, at the moment it's just hacking.

@nyanto thanks for commenting on this PR!

from capirca.

I am the original poster. Would still come in handy, but as said before: for my requirements sed works fine at the moment.

from capirca.

I'm going to work on merging Capirca's code into mine, for release back up to Capirca master. This will include the Nexus code.

from capirca.

Added nyanto's code, with some modifications, in PR #68.

from capirca.

Any chance this is going to get merged into the maintree? I see that the main tree still has no nexus support.

Thanks

from capirca.

Hi @usagichan
The code currently exists in #68 but since that builds ontop of other PRs I cannot accept it in the current form. I have not had time to take a look at those PRs. If @jzohrab or @nyanto want to send me a PR with just that code I should be able to accept it much easier.

from capirca.

Is there any progress on the NXOS merge/integration yet?

from capirca.

Not much yet, got held up with some work and a different PR. Will try to pull those changes in once we resolve that as it changes some of the setup of a generator.

from capirca.

@ankenyr I just ported the NXOS part of @jzohrab commit with some basic tests. Could you take a look at it here?

from capirca.

from capirca.

@ankenyr reading the previous comments again, I realized validation/verification purposes in mind protocol name resolution is necessary for some people, I will revise and resend the pull request to address that. Thanks.

from capirca.

No worries, thanks for the work! Let me know when it is complete.

from capirca.

Hi @ankenyr,

I have tested this patch on 3K and 5K switches. The remaining tasks for verification ease is first tcp/udp port number translation, host vs /32, duplicate remarks combined by nxos.

I think if you can review the patch, we can work on the remaining items separately. I think port translation requires changes on ios, xr and asa. @jzohrab's patch has the support but need some work. I have seen some inconsistency where sometimes defined networks return /32 and sometimes host. Why number of host does not work consistently, I am investigating that right now. Currently it does not cause any problems just aesthetics and consistency matter. Third part, I need to test on ios and xr to check if behavior is the same. If two remarks have the same content, the second one is skipped regardless how many aces in between.

Thanks,
Tarik

from capirca.

Going to close this issue, if someone wants to contribute please make a PR

from capirca.