mkhachfeh
commented
3 years ago @mirceaulinic your ideas here will be super appreciated
Open mkhachfeh opened 3 years ago
mkhachfeh
commented
3 years ago @mirceaulinic your ideas here will be super appreciated
mkhachfeh
commented
3 years ago Just to complete the scenario: I tested configs via napalm library from the same host toward same Junos gear, and it success
sh-3.2# cat conf.set
set vlans vlan888 vlan-id 888
-------------------------------
sh-3.2# cat connect_to_junos.py
import napalm
from pprint import pprint as pp
driver = napalm.get_network_driver('junos')
device = driver(hostname='10.220.1.9', username='myuser', password='')
device.open()
device.load_merge_candidate(filename='conf.set')
pp(device.compare_config())
device.commit_config()
device.close()
-------------------------------
sh-3.2# python connect_to_junos.py
'[edit vlans]\n+ vlan888 {\n+ vlan-id 888;\n+ }So it is proof that it isn't a napalm issue
mkhachfeh
commented
3 years ago Today I tested netconf with the rpc's which are generated with salt command, and it worked smoothly:
sh-3.2# ssh mkh@10.220.1.9 -s netconf
<!-- No zombies were killed during the creation of this user interface -->
<!-- user mkh, class j-super-user -->
<nc:hello xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
<nc:capabilities>
<nc:capability>urn:ietf:params:netconf:base:1.0</nc:capability>
<nc:capability>urn:ietf:params:netconf:capability:candidate:1.0</nc:capability>
<nc:capability>urn:ietf:params:netconf:capability:confirmed-commit:1.0</nc:capability>
<nc:capability>urn:ietf:params:netconf:capability:validate:1.0</nc:capability>
<nc:capability>urn:ietf:params:netconf:capability:url:1.0?protocol=http,ftp,file</nc:capability>
<nc:capability>urn:ietf:params:xml:ns:netconf:base:1.0</nc:capability>
<nc:capability>urn:ietf:params:xml:ns:netconf:capability:candidate:1.0</nc:capability>
<nc:capability>urn:ietf:params:xml:ns:netconf:capability:confirmed-commit:1.0</nc:capability>
<nc:capability>urn:ietf:params:xml:ns:netconf:capability:validate:1.0</nc:capability>
<nc:capability>urn:ietf:params:xml:ns:netconf:capability:url:1.0?protocol=http,ftp,file</nc:capability>
<nc:capability>urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring</nc:capability>
<nc:capability>http://xml.juniper.net/netconf/junos/1.0</nc:capability>
<nc:capability>http://xml.juniper.net/dmi/system/1.0</nc:capability>
</nc:capabilities>
<nc:session-id>25758</nc:session-id>
</nc:hello>
]]>]]>
<?xml version="1.0" encoding="UTF-8"?><nc:rpc xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="urn:uuid:44f96beb-9b1d-42e4-aa82-78fe656760bd"><load-configuration format="text" action="replace"><configuration-text>vlans {
vlan888 {
description test-salt;
vlan-id 888;
}
}
</configuration-text></load-configuration></nc:rpc>]]>]]><nc:rpc-reply xmlns:junos="http://xml.juniper.net/junos/18.2R3/junos" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="urn:uuid:44f96beb-9b1d-42e4-aa82-78fe656760bd">
<load-configuration-results format="text" action="replace">
<nc:ok/>
</load-configuration-results>
</nc:rpc-reply>
]]>]]>
<?xml version="1.0" encoding="UTF-8"?><nc:rpc xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="urn:uuid:9323a656-ffc6-4488-9acd-1eb5e6bff4b1"><get-configuration compare="rollback" rollback="0" format="text"/></nc:rpc>]]>]]>
<nc:rpc-reply xmlns:junos="http://xml.juniper.net/junos/18.2R3/junos" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="urn:uuid:9323a656-ffc6-4488-9acd-1eb5e6bff4b1">
<configuration-information compare="rollback" rollback="0" format="text">
<configuration-output>
[edit vlans]
+ vlan888 {
+ description test-salt;
+ vlan-id 888;
+ }
</configuration-output>
</configuration-information>
</nc:rpc-reply>
]]>]]>
<?xml version="1.0" encoding="UTF-8"?><nc:rpc xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="urn:uuid:cec6936f-eb6a-4ed9-b30d-518e727421e8"><commit-configuration/></nc:rpc>]]>]]>
<nc:rpc-reply xmlns:junos="http://xml.juniper.net/junos/18.2R3/junos" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="urn:uuid:cec6936f-eb6a-4ed9-b30d-518e727421e8">
<commit-results>
<routing-engine junos:style="normal">
<name>fpc0</name>
<commit-check-success/>
<commit-success/>
<commit-revision-information>
<new-db-revision>fpc0-1636643668-148</new-db-revision>
<old-db-revision>fpc0-1636643324-147</old-db-revision>
</commit-revision-information>
</routing-engine>
</commit-results>
<nc:ok/>
</nc:rpc-reply>
]]>]]>
exit
<rpc>
<close-session/>
</rpc>So I can ignore that it is netconf problem
mkhachfeh
commented
2 years ago Another update:
I tested the configs using salt minion, not salt-sproxy, and it worked smoothly with no problem.
So seems to me it is a limitation in salt-sproxy only, not on related packages.
Describe the bug Hi All,
I was using salt-sproxy for a while with our Juniper-based network, and all was working fine.
I started to find some problems with the new Junos code we use (18.x)
I can communicate with the device (net.connected, net.cli, grains....etc), but I can't configure anything on it via neither net.cli nor net.load_config/template, the device isn't reporting back any diff, and sees that the new configs are already configured, even if the new set file contains new configs not configured on the device for sure.
And I can see nothing coming back from the device via rpc-reply while debugging the request.
I tested that for multiple Juniper devices with the same code, and all are the same wrong behaviour.
For example: - The working operational scenario:
- The non-working configurational scenario 1, again: vlan888 isn't configured on the device 100%:
- The non-working configurational scenario 2:
Within debug what I see during that is the following:
Versions Report
Just last note that the same set file+ net commands are working for another Junos code different than 18, tested on 20.4 and 15.1 with no similar problem
Wish it is clear, and thanks in advance.