Extreme Networks Summit400-48t 7.8e.1.1 - xos model triggers false positive confich changes and changes config itself

[sq9mev]

We have two problems with these legacy devices:

1. Regexp in https://github.com/ytti/oxidized/blob/master/lib/oxidized/model/xos.rb#L30 is too restricteve, our device reports as "Summit400-48t", so regexp is missing dash.
2. Statement "disable clipaging" in https://github.com/ytti/oxidized/blob/master/lib/oxidized/model/xos.rb#L44 modifies config itself before next statements, so we always end up with "*" in the prompt (which in itself is quite misleading), and sets "Config Modified" field to new value, and it's another cause of false positive.

My teammate is preparing PR resolving this issue.

[sq9mev]

Our Summit400-48t supports "disable clipaging session" statement, which does not modify config at all, but unfortunately this is not supported by newer devices… Our idea is just to implement xoslegacy model, but not sure if regexp (1) should be changed in xos.rb also.

[wk]

Are there disadvantages to issuing a 2nd post_login statement in the base xos.rb model with disable clipaging session, which will result in both commands being executed at each run (one of the two generating a silent error), and thus keeping this as one single model?

Expanding the Configuration generated match in the base xos.rb model also seems to make sense.

[sq9mev]

Are there disadvantages to issuing a 2nd post_login statement in the base xos.rb model […]

Having this in one model would be nice, but…

Well, on newer devices this might make sense, but on legacy emitting disable clipaging marks the config as changed so this is not an option.

Another approach would be try to execute disable paging session and when it fails execute disable paging - the problem is we came from Python world and do not know Ruby at all ;(.

One another solution - emit show version, try to parse it, and issue disable clipaging or disable clipaging session basing on version, we did not find out which Extremeware version stopped to support disable clipaging session.

What do you think?

[wk]

Based on ExtremeWare XOS documentation, the transition from disable clipaging session to disable clipaging for disabling paging in the current session took place in version 10.1.

We have a few ways to go here to keep this all within one model:

• introduce a xos_legacy knob (true or false) which will choose the disable clipaging session formulation over the disable clipaging one, letting the user configure which devices are legacy and requiring this formulation (see comware.rb for inspiration)
• condition the command based on version (see junos.rb for inspiration, but won't work with post_login outright, as those commands are executed before any version commands, so requires a small refactoring)
• introduce a 2nd model for legacy XOS

My preference is for keeping this in one model, but reliable version detection with no quirks is nothing that can be taken for granted. Does XOS return show version consistently from pre-10.1 versions and post-10.1 versions so we can reasonably put this in place without introducing breakage? Should we leave it up to the user? Which way would you prefer here?

[sq9mev]

Well, parsing version string seems to be not reliable in the long run… would you accept solution basing on checking if device supports disable clipaging session?

[sq9mev]

I think the most general way is to try emit

dtac-sw-kfel23-127-004.ctpt:1 # disable clipaging session 
dtac-sw-kfel23-127-004.ctpt:2 # 

and stop executing post_login when it returns newline and prompt or emit

dist-sw-mrozan3-127-199.ctpt.2 # disable clipaging
dist-sw-mrozan3-127-199.ctpt.3 # 

when the first statement returns anything more than newline and prompt, especially:

dist-sw-mrozan3-127-199.ctpt.2 # disable clipaging
dist-sw-mrozan3-127-199.ctpt.3 # disable clipaging session
                                                   ^
%% Invalid input detected at '^' marker.

How about it?

[wk]

Looks perfectly reasonable!