open-switch / opx-cps Goto Github PK
View Code? Open in Web Editor NEWHome Page: https://openswitch.net
Home Page: https://openswitch.net
I create a new interface via CPS, and call cps_utils.printable()
on the changes reported back to me, something like this:
cps.transaction(obj):
changes = [t['change'] for t in obj]
for change in changes:
cps_utils.printable(change)
But I get this error:
Traceback (most recent call last):
File "/opt/metaswitch/pymm/pymm_cps_common.py", line 82, in write
cps_utils.printable(change)
File "/usr/lib/opx/cps_utils.py", line 315, in printable
cps_attr_types_map.printable(obj)
File "/usr/lib/opx/cps_utils.py", line 213, in printable
self.printable_dict(data)
File "/usr/lib/opx/cps_utils.py", line 207, in printable_dict
data[k] = str(self.from_data(k, data[k]))
File "/usr/lib/opx/cps_utils.py", line 148, in from_data
return bytearray_utils.ba_to_value(t, val)
File "/usr/lib/opx/bytearray_utils.py", line 259, in ba_to_value
return ba_to_type[typ](typ, val)
File "/usr/lib/opx/bytearray_utils.py", line 220, in ba_to_int_type
return from_ba(val, t)
File "/usr/lib/opx/bytearray_utils.py", line 98, in from_ba
s = struct.unpack(pack_type_map_from_len[length], ba[0:length])[0]
KeyError: 0
Logging show that the content of changes
is as follows - I don't know which is the problematic value:
2018-01-31 13:06:49,005 UTC INFO changes [{'operation': 'action', 'data': {'base-if-phy/if/interfaces/interface/npu-id': bytearray(b'\x00\x00\x00\x00'), 'dell-if/if/interfaces/interface/duplex': bytearray(b'\x03\x00\x00\x00'), 'dell-if/if/interfaces/interface/phys-address': bytearray(b'08:00:27:c8:2a:3f\x00'), 'base-if-phy/hardware-port/front-panel-port': bytearray(b'\x17\x00\x00\x00'), 'if/interfaces/interface/name': bytearray(b'e101-023-0\x00'), 'dell-base-if-cmn/if/interfaces/interface/if-index': bytearray(b'*\x00\x00\x00'), 'dell-base-if-cmn/set-interface/input/operation': bytearray(b'\x01\x00\x00\x00'), 'if/interfaces/interface/type': bytearray(b'ianaift:ethernetCsmacd\x00'), 'cps/object-group/return-code': bytearray(b'\x00\x00\x00\x00'), 'base-if-phy/hardware-port/subport-id': bytearray(b'\x00\x00\x00\x00'), 'dell-if/if/interfaces/interface/speed': bytearray(b'\x08\x00\x00\x00'), 'base-if-phy/if/interfaces/interface/port-id': bytearray(b'q\x00\x00\x00'), 'base-if-phy/if/interfaces/interface/phy-media': bytearray(b''), 'if/interfaces/interface/enabled': bytearray(b'\x01\x00\x00\x00'), 'base-if-phy/if/interfaces/interface/supported-autoneg': bytearray(b'\x04\x00\x00\x00'), 'dell-if/if/interfaces/interface/negotiation': bytearray(b'\x01\x00\x00\x00')}, 'key': '1.19.1245192.'}]
We did not see this failure on the OPX 2.1 VM, but are seeing it on the 2.2 VM.
The life of a developer feeding yang modelled data into cps and from cps would be significantly easier if cps.type() also reported the actual key fields for lists. Presently it does not.
Creating a LAG interface with a name that does not end in an integer fails and causes opx_nas_daemon to crash.
Note: The same behaviour is true even if we provide a LAG ID using base-if-lag/if/interfaces/interface/id
Expected behaviour:
Create a LAG interface with a number at the end (succeeds):
opxUser@opx221_vm:~$ sudo cps_set_oid.py -qua target -oper action dell-base-if-cmn/set-interface dell-base-if-cmn/set-interface/input/operation=1 if/interfaces/interface/type=ianaift:ieee8023adLag if/interfaces/interface/name=testlag13
Success
Key: 1.19.1245192.
dell-base-if-cmn/if/interfaces/interface/if-index = 40
dell-if/if/interfaces/interface/phys-address = 08:00:27:2d:79:06
base-if-lag/if/interfaces/interface/id = 13
if/interfaces/interface/name = testlag13
if/interfaces/interface/type = ianaift:ieee8023adLag
cps/object-group/return-code = 0
dell-base-if-cmn/set-interface/input/operation = 1
Show opx_nas_daemon still up:
opxUser@opx221_vm:~$ ps -ef | grep nas
root 544 1 0 10:33 ? 00:00:00 /usr/bin/python -u /usr/bin/base-nas-shell.py
root 548 1 0 10:33 ? 00:00:00 /usr/bin/python -u /usr/bin/base_nas_monitor_phy_media.py
root 554 1 0 10:33 ? 00:00:00 /usr/bin/python -u /usr/bin/base_nas_phy_media_config.py
root 555 1 0 10:33 ? 00:00:00 /usr/bin/python -u /usr/bin/base_nas_front_panel_ports.py
root 756 1 0 10:33 ? 00:00:05 /usr/bin/opx_nas_daemon
opxUser 1930 1869 0 10:38 pts/1 00:00:00 grep nas
Create a LAG interface without a number in the name (fails):
opxUser@opx221_vm:~$ sudo cps_set_oid.py -qua target -oper action dell-base-if-cmn/set-interface dell-base-if-cmn/set-interface/input/operation=1 if/interfaces/interface/type=ianaift:ieee8023adLag if/interfaces/interface/name=testlag
opxUser@opx221_vm:~$
# No output indicates failure in cps_set_oid.py
Show opx_nas_daemon is down:
opxUser@opx221_vm:~$ ps -ef | grep nas
root 544 1 0 10:33 ? 00:00:00 /usr/bin/python -u /usr/bin/base-nas-shell.py
root 548 1 0 10:33 ? 00:00:00 /usr/bin/python -u /usr/bin/base_nas_monitor_phy_media.py
root 554 1 0 10:33 ? 00:00:00 /usr/bin/python -u /usr/bin/base_nas_phy_media_config.py
root 555 1 0 10:33 ? 00:00:00 /usr/bin/python -u /usr/bin/base_nas_front_panel_ports.py
The following is the relevant extract from syslog:
Mar 9 10:35:14 opx221_vm opx_nas_daemon[716]: [INTERFACE:NAS-CPS-LAG], Can't get interface control information for testlag
Mar 9 10:35:14 opx221_vm opx_nas_daemon[716]: terminate called after throwing an instance of 'std::out_of_range'
Mar 9 10:35:14 opx221_vm opx_nas_daemon[716]: what(): basic_string::substr: __pos (which is 18446744073709551615) > this->size() (which is 7)
Mar 9 10:35:14 opx221_vm kernel: [ 112.032613] bonding: testlag: Setting MII monitoring interval to 100
Mar 9 10:35:14 opx221_vm python[544]: [DSAPI:CPS IPC], Failed to read the receive header
Mar 9 10:35:14 opx221_vm python[544]: [DSAPI:COMMIT], Failed to commit request at 0 out of 1
Mar 9 10:35:14 opx221_vm python[544]: Failed to commit request
Mar 9 10:35:14 opx221_vm opx_cps_service[528]: [DSAPI:NS], Added registration removed for observed dell-base-if-cmn/if/interfaces-state/interface
Mar 9 10:35:14 opx221_vm opx_cps_service[528]: [DSAPI:NS], Added registration removed for target dell-base-if-cmn/dell-if/clear-counters/input
Mar 9 10:35:14 opx221_vm opx_cps_service[528]: [DSAPI:NS], Added registration removed for target base-if-phy/physical
Mar 9 10:35:14 opx221_vm opx_cps_service[528]: [DSAPI:NS], Added registration removed for target dell-base-if-cmn/dell-if/clear-eee-counters/input
Mar 9 10:35:14 opx221_vm opx_cps_service[528]: [DSAPI:NS], Added registration removed for target dell-base-if-cmn/if/interfaces/interface
Mar 9 10:35:14 opx221_vm opx_cps_service[528]: [DSAPI:NS], Added registration removed for target ni/network-instances
Mar 9 10:35:14 opx221_vm opx_cps_service[528]: [DSAPI:NS], Added registration removed for target ni/if/interfaces/interface
Mar 9 10:35:14 opx221_vm opx_cps_service[528]: [DSAPI:NS], Added registration removed for observed base-switch/switching-entities/switching-entity
Mar 9 10:35:14 opx221_vm python[1775]: [DSAPI:COMMIT], Failed to commit request at 0 out of 1
Mar 9 10:35:14 opx221_vm opx_cps_service[528]: [DSAPI:NS], Added registration removed for target base-switch/switching-entities
Mar 9 10:35:14 opx221_vm opx_cps_service[528]: [DSAPI:NS], Added registration removed for target base-sflow/entry
Mar 9 10:35:14 opx221_vm opx_cps_service[528]: [DSAPI:NS], Added registration removed for target base-switch/set_log
Mar 9 10:35:14 opx221_vm opx_cps_service[528]: [DSAPI:NS], Added registration removed for target base-traffic-hash/entry
Mar 9 10:35:14 opx221_vm opx_cps_service[528]: [DSAPI:NS], Added registration removed for target base-mirror/entry
Mar 9 10:35:14 opx221_vm opx_cps_service[528]: [DSAPI:NS], Added registration removed for target base-switch/switching-entities/switching-entity
Mar 9 10:35:14 opx221_vm opx_cps_service[528]: [DSAPI:NS], Added registration removed for observed dell-base-if-cmn/if/interfaces-state/interface/statistics
Mar 9 10:35:14 opx221_vm opx_cps_service[528]: [DSAPI:NS], Added registration removed for target base-stg/default-stg
Mar 9 10:35:14 opx221_vm opx_cps_service[528]: [DSAPI:NS], Added registration removed for target base-stg/entry
Mar 9 10:35:14 opx221_vm opx_cps_service[528]: [DSAPI:NS], Added registration removed for target base-stg/entry/vlan
Mar 9 10:35:14 opx221_vm opx_cps_service[528]: [DSAPI:NS], Added registration removed for target base-mac/query
Mar 9 10:35:14 opx221_vm opx_cps_service[528]: [DSAPI:NS], Added registration removed for target base-mac/table
Mar 9 10:35:14 opx221_vm opx_cps_service[528]: [DSAPI:NS], Added registration removed for target base-mac/flush
Mar 9 10:35:14 opx221_vm opx_cps_service[528]: [DSAPI:NS], Added registration removed for target base-mac/flush-management
Mar 9 10:35:14 opx221_vm opx_cps_service[528]: [DSAPI:NS], Added registration removed for target base-l2-mcast/cleanup-l2mc-member
Mar 9 10:35:14 opx221_vm opx_cps_service[528]: [DSAPI:NS], Added registration removed for target base-neighbor/if/interfaces-state/interface
Mar 9 10:35:14 opx221_vm opx_cps_service[528]: [DSAPI:NS], Added registration removed for target base-neighbor/base-route/obj/nbr
Mar 9 10:35:14 opx221_vm opx_cps_service[528]: [DSAPI:NS], Added registration removed for target base-route/fib
Mar 9 10:35:14 opx221_vm opx_cps_service[528]: [DSAPI:NS], Added registration removed for target base-route/peer-routing-config
Mar 9 10:35:14 opx221_vm opx_cps_service[528]: [DSAPI:NS], Added registration removed for target base-route/obj/entry
Mar 9 10:35:14 opx221_vm opx_cps_service[528]: [DSAPI:NS], Added registration removed for target base-route/route-nh-operation
Mar 9 10:35:14 opx221_vm opx_cps_service[528]: [DSAPI:NS], Added registration removed for target base-route/ip-unreachables-config
Mar 9 10:35:14 opx221_vm opx_cps_service[528]: [DSAPI:NS], Added registration removed for target base-route/obj/nbr
Mar 9 10:35:14 opx221_vm opx_cps_service[528]: [DSAPI:NS], Added registration removed for target base-route/flush
Mar 9 10:35:14 opx221_vm opx_cps_service[528]: [DSAPI:NS], Added registration removed for target base-route/interface-mode-change
Mar 9 10:35:14 opx221_vm opx_cps_service[528]: [DSAPI:NS], Added registration removed for target base-route/obj
Mar 9 10:35:14 opx221_vm opx_cps_service[528]: [DSAPI:NS], Added registration removed for target base-route/nh-track
Mar 9 10:35:14 opx221_vm opx_cps_service[528]: [DSAPI:NS], Added registration removed for target base-packet/rule
Mar 9 10:35:14 opx221_vm opx_cps_service[528]: [DSAPI:NS], Added registration removed for target base-sflow/socket-address
Mar 9 10:35:14 opx221_vm opx_cps_service[528]: [DSAPI:NS], Added registration removed for target base-acl/clear-acl-entries-for-nh
Mar 9 10:35:14 opx221_vm opx_cps_service[528]: [DSAPI:NS], Added registration removed for target base-udf
Mar 9 10:35:14 opx221_vm opx_cps_service[528]: [DSAPI:NS], Added registration removed for target base-acl
Mar 9 10:35:14 opx221_vm opx_cps_service[528]: [DSAPI:NS], Added registration removed for target base-qos
Mar 9 10:35:14 opx221_vm opx_cps_service[528]: [DSAPI:NS], Added registration removed for target base-if-linux/if/interfaces/interface
Mar 9 10:35:14 opx221_vm systemd[1]: opx-nas.service: main process exited, code=killed, status=6/ABRT
Mar 9 10:35:14 opx221_vm systemd[1]: Unit opx-nas.service entered failed state.
Mar 9 10:35:14 opx221_vm systemd[1]: Triggering OnFailure= dependencies of opx-nas.service.
Mar 9 10:35:14 opx221_vm systemd[1]: Failed to enqueue OnFailure= job: Invalid argument
Mar 9 10:35:14 opx221_vm opx_cps_service[528]: [DSAPI:NS], Added registration removed 1.4.1.
Mar 9 10:35:14 opx221_vm opx_cps_service[528]: [DSAPI:NS], Added registration removed 1.3.
Mar 9 10:35:14 opx221_vm opx_cps_service[528]: [DSAPI:NS], Added registration removed 1.4.2.
Mar 9 10:35:14 opx221_vm opx_cps_service[528]: [DSAPI:NS], Added registration removed 1.4.3.
Mar 9 10:35:19 opx221_vm opx_pas_service[542]: [DSAPI:CPS IPC], not able to connect to owner
Mar 9 10:35:19 opx221_vm opx_pas_service[542]: [DSAPI:NS], Failed to find owner for 1.36.2359341.2359299.2359302.
Mar 9 10:35:19 opx221_vm opx_pas_service[542]: [PAS:dn_remote_temp_sensor_poll], CPS API get failed
Mar 9 10:35:19 opx221_vm opx_pas_service[542]: [PAS:dn_pas_remote_poller_thread], Poll cycle failed
Mar 9 10:35:19 opx221_vm python[545]: Entity ('card', 1) sensor "NPU temp sensor" faulty, oper-status=8, fault-type=3
Mar 9 10:35:24 opx221_vm opx_pas_service[542]: [DSAPI:NS], Failed to find owner for 1.36.2359341.2359299.2359302.
Mar 9 10:35:24 opx221_vm opx_pas_service[542]: [PAS:dn_remote_temp_sensor_poll], CPS API get failed
Mar 9 10:35:24 opx221_vm opx_pas_service[542]: [PAS:dn_pas_remote_poller_thread], Poll cycle failed
ACLs in the base-acl/table
YANG list don't seem to be configurable after they have been created:
opxUser@opx_vm:~$ sudo cps_get_oid.py target base-acl/table id=4
Key: 1.47.3080336.3080284.
base-acl/table/npu-id-list = 0
base-acl/table/id = 4
base-acl/table/stage = 1
base-acl/table/priority = 0
base-acl/table/allowed-match-fields = 1,2,5,6
base-acl/table/size = 0
opxUser@opx_vm:~$ sudo cps_set_oid.py set base-acl/table id=4 priority=1
opxUser@opx_vm:~$ echo $?
0
opxUser@opx_vm:~$ sudo cps_get_oid.py target base-acl/table id=4
Key: 1.47.3080336.3080284.
base-acl/table/npu-id-list = 0
base-acl/table/id = 4
base-acl/table/stage = 1
base-acl/table/priority = 0
base-acl/table/allowed-match-fields = 1,2,5,6
base-acl/table/size = 0
opxUser@opx_vm:~$ sudo cps_set_oid.py set base-acl/table id=4 name=test
opxUser@opx_vm:~$ echo $?
0
opxUser@opx_vm:~$ sudo cps_get_oid.py target base-acl/table id=4
Key: 1.47.3080336.3080284.
base-acl/table/npu-id-list = 0
base-acl/table/id = 4
base-acl/table/stage = 1
base-acl/table/priority = 0
base-acl/table/allowed-match-fields = 1,2,5,6
base-acl/table/size = 0
I have noticed the same behaviour using the CPS python API, with the syslog message: Feb 7 14:44:17 opx_vm opx_nas_daemon[585]: [ACL:NAS-ACL], Operation 3 NOT allowed on Obj
. Is this intended behaviour? If so, is it documented anywhere? Do configuration operations have to be two-stage create/delete operations?
This is on the v2.2 VM.
Setting base-ip/ipv4/enabled does not seem to do anything.
I would expect it to act the same as base-ip/ipv6/enabled.
Also it is absent when querying configuration.
opxUser@opx221_vm:~$ sudo ip addr show dev e101-002-0
14: e101-002-0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 08:00:27:2d:78:a2 brd ff:ff:ff:ff:ff:ff
inet 172.28.128.12/24 scope global e101-002-0
valid_lft forever preferred_lft forever
inet 10.11.12.2/24 scope global e101-002-0
valid_lft forever preferred_lft forever
inet6 fd80:e105:4c24:c3ef::1/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::a00:27ff:fe2d:78a2/64 scope link
valid_lft forever preferred_lft forever
opxUser@opx221_vm:~$ sudo cps_set_oid.py -oper set base-ip/ipv6 name=e101-002-0 enabled=0
Success
Key: 1.22.1441815.1441805.
cps/object-group/return-code = 0
base-ip/ipv6/enabled = 0
base-ip/ipv6/name = e101-002-0
opxUser@opx221_vm:~$ sudo ip addr show dev e101-002-0
14: e101-002-0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 08:00:27:2d:78:a2 brd ff:ff:ff:ff:ff:ff
inet 172.28.128.12/24 scope global e101-002-0
valid_lft forever preferred_lft forever
inet 10.11.12.2/24 scope global e101-002-0
valid_lft forever preferred_lft forever
opxUser@opx221_vm:~$ sudo cps_set_oid.py -oper set base-ip/ipv4 name=e101-002-0 enabled=0
Success
Key: 1.22.1441814.1441812.
base-ip/ipv4/enabled = 0
base-ip/ipv4/name = e101-002-0
cps/object-group/return-code = 0
opxUser@opx221_vm:~$ sudo ip addr show dev e101-002-0
14: e101-002-0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 08:00:27:2d:78:a2 brd ff:ff:ff:ff:ff:ff
inet 172.28.128.12/24 scope global e101-002-0
valid_lft forever preferred_lft forever
inet 10.11.12.2/24 scope global e101-002-0
valid_lft forever preferred_lft forever
opxUser@opx221_vm:~$ sudo cps_get_oid.py base-ip/ipv6 base-ip/ipv6/name=e101-002-0
============1.22.1441815.1441805.==========
base-ip/ipv6/forwarding = 1
base-ip/ipv6/name = e101-002-0
base-ip/ipv6/vrf-id = 0
base-ip/ipv6/autoconf = 1
base-ip/ipv6/enabled = 0 <------------
base-ip/ipv6/ifindex = 14
------------------------------------------------
opxUser@opx221_vm:~$ sudo cps_get_oid.py base-ip/ipv4 base-ip/ipv4/name=e101-002-0
============1.22.1441814.1441812.==========
base-ip/ipv4/vrf-id = 0
base-ip/ipv4/name = e101-002-0
base-ip/ipv4/forwarding = 1
base-ip/ipv4/address/prefix-length = 24
base-ip/ipv4/address/ip = 0a0b0c02
base-ip/ipv4/address/prefix-length = 24
base-ip/ipv4/address/ip = ac1c800c
base-ip/ipv4/ifindex = 14
------------------------------------------------
When I set the admin-state of a VLAN interface using the typical Linux networking utilities, the target value of the if/interfaces/interface/enabled
field does not change when queried through CPS.
Setting if/interfaces/interface/enabled
through CPS does work as expected - e.g. setting enabled=1 causes the interface to come up, and subsequent queries in CPS are correct.
opxUser@opx221_vm:~$ sudo cps_config_vlan.py --add --id 11 --vlantype 1
Success
opxUser@opx221_vm:~$ ip link show dev br11
45: br11: <BROADCAST,MULTICAST,PROMISC> mtu 1500 qdisc noop state DOWN mode DEFAULT group default
link/ether 08:00:27:2d:79:07 brd ff:ff:ff:ff:ff:ff
enabled = 0
opxUser@opx221_vm:~$ sudo cps_get_oid.py dell-base-if-cmn/if/interfaces/interface if/interfaces/interface/name=br11 | grep enabled
if/interfaces/interface/enabled = 0
ip link
. CPS still shows enabled = 0
. This is wrongopxUser@opx221_vm:~$ sudo ip link set dev br11 up
opxUser@opx221_vm:~$ ip link show dev br11
45: br11: <NO-CARRIER,BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default
link/ether 08:00:27:2d:79:07 brd ff:ff:ff:ff:ff:ff
opxUser@opx221_vm:~$
opxUser@opx221_vm:~$ sudo cps_get_oid.py dell-base-if-cmn/if/interfaces/interface if/interfaces/interface/name=br11 | grep enabled
if/interfaces/interface/enabled = 0 <--------
opxUser@opx221_vm:~$ sudo ip link set dev br11 down
opxUser@opx221_vm:~$ ip link show dev br11
45: br11: <BROADCAST,MULTICAST,PROMISC> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default
link/ether 08:00:27:2d:79:07 brd ff:ff:ff:ff:ff:ff
opxUser@opx221_vm:~$
opxUser@opx221_vm:~$ sudo cps_set_oid.py -qua target -oper action dell-base-if-cmn/set-interface dell-base-if-cmn/set-interface/input/operation=3 if/interfaces/interface/name=br11 if/interfaces/interface/enabled=1
Success
Key: 1.19.1245192.
cps/object-group/return-code = 0
dell-base-if-cmn/set-interface/input/operation = 3
if/interfaces/interface/enabled = 1
if/interfaces/interface/name = br11
opxUser@opx221_vm:~$ ip link show dev br11
45: br11: <NO-CARRIER,BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default
link/ether 08:00:27:2d:79:07 brd ff:ff:ff:ff:ff:ff
opxUser@opx221_vm:~$ sudo cps_get_oid.py dell-base-if-cmn/if/interfaces/interface if/interfaces/interface/name=br11 | grep enabled
if/interfaces/interface/enabled = 1
ip link
. Once again, CPS does not update the target configurationopxUser@opx221_vm:~$ sudo ip link set dev br11 down
opxUser@opx221_vm:~$ ip link show dev br11
45: br11: <BROADCAST,MULTICAST,PROMISC> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default
link/ether 08:00:27:2d:79:07 brd ff:ff:ff:ff:ff:ff
opxUser@opx221_vm:~$
opxUser@opx221_vm:~$ sudo cps_get_oid.py dell-base-if-cmn/if/interfaces/interface if/interfaces/interface/name=br11 | grep enabled
if/interfaces/interface/enabled = 1 <-------------
I'm writing application logic to allow a user to configure auto-negotiation on an interface.
I am confused about the usage of the two following fields (from dell-interface.yang):
dell-if/if/interfaces/interface/auto-negotiation
dell-if/if/interfaces/interface/negotiation
Questions
What's the difference between negotiation
and auto-negotiation
?
Why does opx-ethtool configure negotiation
to auto/on/off instead of directly setting auto-negotiation
?
If I should configure negotiation
, this should be included when querying interface configuration using CPS.
Context
I have looked at the opx-ethtool script.
It uses auto-negotiation
for showing interface configuration, but negotiation
for setting interface configuration.
Testing on my OPX 2.2 VM shows the following behaviour:
negotiation = on
causes auto-negotiation = 1
negotiation = auto or off
causes auto-negotiation = 0
cps-get-oid.py dell-base-if-cmn/if/interfaces/interface
includes auto-negotiation
, but not negotiation
:root@OPX:~# sudo cps_get_oid.py dell-base-if-cmn/if/interfaces/interface if/interfaces/interface/name=e101-021-0
============1.19.44.2883617.2883612.2883613.==========
base-if-phy/if/interfaces/interface/npu-id = 0
dell-base-if-cmn/if/interfaces/interface/if-index = 9
dell-if/if/interfaces/interface/phys-address = 34:17:eb:2c:d7:51
dell-if/if/interfaces/interface/speed = 0
base-if-phy/if/interfaces/interface/learn-mode = 3
if/interfaces/interface/name = e101-021-0
dell-if/if/interfaces/interface/duplex = 1
dell-if/if/interfaces/interface/auto-negotiation = 0
if/interfaces/interface/type = ianaift:ethernetCsmacd
dell-if/if/interfaces/interface/fec = 3
dell-if/if/interfaces/interface/mode = 1
base-if-phy/if/interfaces/interface/port-id = 21
dell-if/if/interfaces-state/interface/supported-speed = 3,4,5,6,10,7
dell-if/if/interfaces/interface/mtu = 1532
base-if-phy/if/interfaces/interface/phy-media = 1
if/interfaces/interface/enabled = 1
base-if-phy/if/interfaces/interface/tagging-mode = 3
The typedef base-acl/packet-action-type
doesn't contain a 'reject' packet action, the semantics of which is to drop the packet and send an ICMP destination-unreachable message back to the source.
This is a common ACL action configurable in various other networking applications, including iptables
. Are you planning to support it in CPS?
Feature request
The Event Thread Utilities API allows an application to register a callback to be executed on a CPS event using the cps_api_event_thread_reg
function.
However, it appears that there is no way to remove that registration without terminating the entire event thread with cps_api_event_thread_shutdown
.
Therefore any registered callbacks must exist for the entire lifetime of the event thread. In most cases, this is equivalent to the lifetime of the application.
Is this analysis correct?
If so, is it possible to extend this API to allow an application to remove or un-register a callback against a CPS event?
This would allow an application to dynamically add or remove event handlers at will during the lifetime of the application.
When I configure the speed of an interface (dell-if/if/interfaces/interface/speed
), the transaction succeeds and returns the changed value.
But when I then query the target configuration, it always returns 0 unless the interface is oper-up.
If I successfully apply configuration, I should be able to view that configuration (and confirm it is correct).
Note, I've found the code which performs this query: https://github.com/open-switch/opx-nas-ndi/blob/master/src/nas_ndi_port.c#L700
The codepath for getting dell-if/if/interfaces/interface/speed
is hardcoded to call the above function with check_link = True
, therefore it always returns 0
when the interface is oper-down.
Also, I considered maybe the speed
field is intended to show the negotiated speed for the interface when it is oper-up?
If this is true, then I would expect there to be a separate field used to set the desired speed of the interface.
So:
dell-if/if/interfaces/interface/speed
field?Trace:
# Setting speed succeeds
root@OPX1:~# cps_set_oid.py -qua target -oper action dell-base-if-cmn/set-interface dell-base-if-cmn/set-interface/input/operation=3 if/interfaces/interface/name=e101-001-4 dell-if/if/interfaces/interface/speed=3
Success
Key: 1.19.1245192.
cps/object-group/return-code = 0
dell-if/if/interfaces/interface/speed = 3
dell-base-if-cmn/set-interface/input/operation = 3
if/interfaces/interface/name = e101-001-4
# But speed is still 0
root@OPX1:~# sudo cps_get_oid.py dell-base-if-cmn/if/interfaces/interface if/interfaces/interface/name=e101-001-4
Key: 1.19.44.2883617.2883612.2883613.
base-if-phy/if/interfaces/interface/npu-id = 0
dell-base-if-cmn/if/interfaces/interface/if-index = 40
dell-if/if/interfaces/interface/phys-address = ec:f4:bb:fd:53:80
dell-if/if/interfaces/interface/speed = 0
base-if-phy/if/interfaces/interface/learn-mode = 3
if/interfaces/interface/name = e101-001-4
dell-if/if/interfaces/interface/duplex = 1
dell-if/if/interfaces/interface/auto-negotiation = 0
if/interfaces/interface/type = ianaift:ethernetCsmacd
base-if-phy/if/interfaces/interface/port-id = 28
dell-if/if/interfaces-state/interface/supported-speed = 2,3,4
dell-if/if/interfaces/interface/mtu = 1532
if/interfaces/interface/enabled = 1
# Now oper-up, we see the correct speed
root@OPX1:~# opx-ethtool e101-001-4
Settings for e101-001-4:
Media Type: QSFP 40GBASE CR4
Part Number: 616760003
Serial Number: CN027GG574F8JUC
Qualified: Yes
Administrative State: UP
Operational State: UP
Supported Speed (in Mbps): [100, 1000, 10000]
Auto Negotiation : off
Speed : 10000
Duplex : full
with the following stack:
Traceback (most recent call last):
File "/usr/lib/opx/py/yin_parser.py", line 34, in <module>
yf = yin_model.CPSYangModel(d)
File "/usr/lib/opx/py/yin_model.py", line 155, in __init__
self.model = ctx['file-finder'].load(self.filename)
File "/usr/lib/opx/py/yin_model.py", line 93, in load
return self.get_parsed_yin(yang_file, prefix)
File "/usr/lib/opx/py/yin_model.py", line 57, in get_parsed_yin
_cps_parser.walk()
File "/usr/lib/opx/py/yin_cps.py", line 165, in walk
self.handle_augments(self.root_node, self.module.name() + ':')
File "/usr/lib/opx/py/yin_cps.py", line 243, in handle_augments
_key_model = self.context['loader'].yin_map[self.context['model-names'][__ns]]
KeyError: 'bgp'
We're trying to find the model that's being augmented, but it's the current model and so the data structure isn't yet ready.
I've worked around this by commenting out this line, and instead calling
_cps_parser.handle_augments(_cps_parser.root_node, _cps_parser.module.name() + ':')
from here.
But that seems kinda ugly, probably there's a better way.
I'm trying to establish whether I'm allowed to share with you the yang model on which I found this problem. (I suspect that the answer will be 'no')
When retrieving interface statistics from dell-base-if-cmn/if/interfaces-state/interface/statistics
, we need to provide not only the interface name but also an interface type.
But what's really confusing: we sometimes need to provide an interface type that isn't the real interface type!
Eg:
import cps
import cps_object
import cps_utils
data = {
'if/interfaces-state/interface/name': 'lo',
'if/interfaces-state/interface/type': 'ianaift:softwareLoopback',
}
obj = cps_object.CPSObject(
qual='observed',
module='dell-base-if-cmn/if/interfaces-state/interface/statistics',
data=data,
)
response = []
if cps.get([obj.get()], response):
for entry in response:
cps_utils.print_obj(entry)
This returns just 10 statistics, omitting (among others) those relating to unicast packets.
The same is true if I leave out the interface type from the query.
But the additional statistics are available. To get at them it seems that I must provide the interface type ianaift:ethernetCsmacd
(even though this really is a loopback interface). Then I get lots more statistics, including the ones relating to unicast packets.
I would expect that:
When I query dell-base-if-cmn/if/interfaces-state/interface
, I see all interfaces reported twice.
opx-config-switch
show not working and gives traceback
For my understanding current traceback relates to the /usr/lib/opx/cps_utils.py
as the bytearray_utils
function can't print values of type leaf-list
and failure happened when it tried to print
leaf-list supported-profiles
from switch.xml
root@OPX:/home/admin# opx-config-switch set switch-id=0 mac-age-timer=120
Success
root@OPX:/home/admin# opx-config-switch show
Key: 1.36.2359341.
base-switch/switching-entities/switch-count = 1
Key: 1.36.2359341.2359299.2359302.
base-switch/switching-entities/switching-entity/num-unicast-queues-per-port = 16
base-switch/switching-entities/switching-entity/acl-entry-max-priority = 512
base-switch/switching-entities/switching-entity/bridge-table-size = 65536
base-switch/switching-entities/switching-entity/max-ecmp-entry-per-group = 0
base-switch/switching-entities/switching-entity/ecmp-hash-algorithm = 2
Traceback (most recent call last):
File "/usr/bin/opx-config-switch", line 55, in <module>
options[opt](sys.argv[2:])
File "/usr/bin/opx-config-switch", line 22, in show_switch
nas_switch_utils.show_switch(args)
File "/usr/lib/x86_64-linux-gnu/opx/nas_switch_utils.py", line 58, in show_switch
cps_utils.print_obj
File "/usr/lib/opx/cps_utils.py", line 293, in print_obj
cps_attr_types_map.print_object(obj, log=None)
File "/usr/lib/opx/cps_utils.py", line 187, in print_object
print_methods[module](data)
File "/usr/lib/x86_64-linux-gnu/opx/nas_switch_utils.py", line 65, in print_switch_details
value = cps_object.types.from_data(key,data)
File "/usr/lib/opx/cps_utils.py", line 148, in from_data
return bytearray_utils.ba_to_value(t, val)
File "/usr/lib/opx/bytearray_utils.py", line 259, in ba_to_value
return ba_to_type[typ](typ, val)
File "/usr/lib/opx/bytearray_utils.py", line 199, in ba_to_str_wr
return ba_to_str(val, len(val))
File "/usr/lib/opx/bytearray_utils.py", line 125, in ba_to_str
s = struct.unpack('<' + str(length) + 's', ba[0:length])[0]
struct.error: unpack requires a string argument of length 1
root@OPX:/home/admin#
root@OPX:/home/admin# opx-show-version
OS_NAME="OPX"
OS_VERSION="2.1.0"
PLATFORM="AS7512-32X"
ARCHITECTURE="x86_64"
INTERNAL_BUILD_ID="OpenSwitch blueprint for Cavium 1.0.0"
BUILD_VERSION="2.1.0.1"
I've just updated an OPX 2.3 machine (apt-get update && apt-get upgrade
)
After this update, querying interface configuration by interface type no longer works - it always returns the full list of interfaces. Querying by name or interface-index still works.
Before the update, I could query all configuration for VLAN interfaces, as shown below:
root@OPX:~# sudo cps_get_oid.py dell-base-if-cmn/if/interfaces/interface if/interfaces/interface/type=ianaift:l2vlan
============dell-base-if-cmn/if/interfaces/interface==========
dell-base-if-cmn/if/interfaces/interface/if-index = 37
dell-if/if/interfaces/interface/phys-address = ec:f4:bb:fd:43:c6
if/interfaces/interface/type = ianaift:l2vlan
base-if-vlan/if/interfaces/interface/id = 100
if/interfaces/interface/name = br100
dell-if/if/interfaces/interface/vlan-type = 1
dell-if/if/interfaces/interface/learning-mode = 1
dell-if/if/interfaces/interface/mtu = 1532
if/interfaces/interface/enabled = 0
------------------------------------------------
Now, the same command returns all interfaces of any type:
root@OPX:~# sudo cps_get_oid.py dell-base-if-cmn/if/interfaces/interface if/interfaces/interface/type=ianaift:l2vlan
============dell-base-if-cmn/if/interfaces/interface==========
dell-base-if-cmn/if/interfaces/interface/if-index = 4
if/interfaces/interface/type = base-if:cpu
if/interfaces/interface/name = npu-0
------------------------------------------------
.
.
.
if/interfaces/interface/type = ianaift:ethernetCsmacd
dell-if/if/interfaces/interface/mode = 1
base-if-phy/if/interfaces/interface/port-id = 125
dell-if/if/interfaces-state/interface/supported-speed = 3,4,6
dell-if/if/interfaces/interface/mtu = 1532
base-if-phy/if/interfaces/interface/phy-media = 1
if/interfaces/interface/enabled = 0
base-if-phy/if/interfaces/interface/tagging-mode = 3
------------------------------------------------
dell-base-if-cmn/if/interfaces/interface/if-index = 37
dell-if/if/interfaces/interface/phys-address = ec:f4:bb:fd:53:e6
if/interfaces/interface/type = ianaift:l2vlan
base-if-vlan/if/interfaces/interface/id = 100
if/interfaces/interface/name = br100
dell-if/if/interfaces/interface/vlan-type = 1
dell-if/if/interfaces/interface/learning-mode = 1
dell-if/if/interfaces/interface/mtu = 1532
if/interfaces/interface/enabled = 0
------------------------------------------------
The packages which changed in the update were:
If I query interface-state for a loopback interface, I get nothing:
# cps_get_oid.py observed dell-base-if-cmn/if/interfaces-state/interface if/interfaces-state/interface/name=lo
#
... even though this interface definitely exists:
# cps_get_oid.py observed dell-base-if-cmn/if/interfaces-state/interface | grep lo
if/interfaces-state/interface/name = lo
if/interfaces-state/interface/name = lo
(duplication is per #42).
By-name queries work as expected for ethernet-csmacd interfaces:
# cps_get_oid.py observed dell-base-if-cmn/if/interfaces-state/interface if/interfaces-state/interface/name=e101-004-0
Key: 2.19.44.2883618.2883611.2883586.
dell-if/if/interfaces/interface/phys-address = 08:00:27:d3:6f:cc
if/interfaces-state/interface/speed = 0
if/interfaces-state/interface/admin-status = 2
dell-if/if/interfaces-state/interface/duplex = 1
dell-if/if/interfaces-state/interface/auto-negotiation = 0
if/interfaces-state/interface/if-index = 14
if/interfaces-state/interface/oper-status = 2
dell-if/if/interfaces-state/interface/oui = 6976381
dell-if/if/interfaces-state/interface/fec = 2
dell-if/if/interfaces/interface/mtu = 1532
if/interfaces-state/interface/name = e101-004-0
if/interfaces/interface/enabled = 0
#
Here's an attempt to delete a loopback interface:
$ ip link show lo4
39: lo4: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1632 qdisc noqueue state UNKNOWN mode DEFAULT group default
link/ether 02:a5:ea:e0:b1:a6 brd ff:ff:ff:ff:ff:ff
$ sudo nas_intf_set.py -o delete lo4
delete
lo4
ianaift:ethernetCsmacd
None
None
$ ip link show lo4
39: lo4: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1632 qdisc noqueue state UNKNOWN mode DEFAULT group default
link/ether 02:a5:ea:e0:b1:a6 brd ff:ff:ff:ff:ff:ff
As you can see, it just isn't deleted.
I see this in syslog at the time, which I suppose is a clue:
Jan 24 10:24:25 opx_vm opx_nas_daemon[543]: [INTERFACE:NAS-COM-INT-GET], Get request handler was not registered for obj Category 0 and type 4
Our log shows us setting the MAC address on bnd1
here, to 00:01:02:03:04:05
:
2018-04-19 09:39:14,146 UTC INFO Executing CPS transaction: [{'operation': 'rpc', 'change': {'data': {'dell-if/if/interfaces/interface/phys-address': bytearray(b'00:01:02:03:04:05\x00'), 'if/interfaces/interface/name': bytearray(b'bnd1\x00'), 'if/interfaces/interface/type': bytearray(b'ianaift:ieee8023adLag\x00'), 'dell-if/if/interfaces/interface/mtu': bytearray(b'\xfc\x05\x00\x00'), 'dell-base-if-cmn/set-interface/input/operation': bytearray(b'\x03\x00\x00\x00'), 'if/interfaces/interface/enabled': bytearray(b'\x01\x00\x00\x00')}, 'key': '1.19.1245192.'}}]
But a few minutes later, the target physical address for this interface has changed:
# cps_get_oid.py -qua target dell-base-if-cmn/if/interfaces/interface if/interfaces/interface/name=bnd1
============base-if-lag/if/interfaces/interface==========
dell-if/if/interfaces/interface/phys-address = 00:50:56:92:d3:c1
base-if-lag/if/interfaces/interface/id = 0
base-if-lag/if/interfaces/interface/lag-opaque-data = 01000000000000002c000000000000000100000000000000040000000000000000000000020000000000000008000000000000000000000000000200
if/interfaces/interface/type = ianaift:ieee8023adLag
dell-base-if-cmn/if/interfaces/interface/if-index = 38
if/interfaces/interface/name = bnd1
base-if-lag/if/interfaces/interface/unblock-port-list =
dell-if/if/interfaces/interface/mtu = 1532
if/interfaces/interface/enabled = 1
base-if-lag/if/interfaces/interface/block-port-list =
------------------------------------------------
(and indeed the actual MAC address on this interface is this address, rather than the one we configured).
00:50:56:92:d3:c1
is the autogenerated MAC address for e101-002-0
, which is slave to bnd1
:
# ip link show dev e101-002-0
4: e101-002-0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bnd1 state UP mode DEFAULT group default qlen 1000
link/ether 00:50:56:92:d3:c1 brd ff:ff:ff:ff:ff:ff
alias NAS## 0 29
I suppose this is some sort of window condition - we don't see it always. Usually our configuration sticks.
In what circumstances would CPS discard our configured target physical address?
We are running with the latest OPX packages from the deb http://deb.openswitch.net/ 2.3.0 main opx opx-non-free
repository
I'm using IN_INTF/OUT_INTF for ACL match rules that want to match on an ingress/egress interface, but this match type doesn't work for VLANs or LAGs.
Out of the other match rules, SRC_PORT/DST_PORT don't work:
void nas_acl_table::set_allowed_filter(uint_t) (), Unknown Table Match Field type 34
Feb 23 10:55:45 opx_vm python[14002]: [DSAPI:COMMIT], Failed to commit request at 0 out of 1
And it's not clear how the concepts in the others relate to interface types. How should this be configured in CPS? Or is it not possible?
Regardless of the bridge interface state reported in ip link
, CPS always reports the VLAN bridge interface as down.
if/interfaces-state/interface/oper-status = 1
if/interfaces-state/interface/admin-status = 1
More detailed trace follows:
# VLAN interface is down
opxUser@opx_vm:~$ sudo ip link set dev br100 down
opxUser@opx_vm:~$ ip link show br100
54: br100: <BROADCAST,MULTICAST,PROMISC> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default
link/ether 08:00:27:d3:70:29 brd ff:ff:ff:ff:ff:ff
# CPS reports down
opxUser@opx_vm:~$ sudo cps_get_oid.py observed dell-base-if-cmn/if/interfaces-state/interface
...
if/interfaces-state/interface/admin-status = 1
dell-if/if/interfaces-state/interface/duplex = 1
dell-if/if/interfaces-state/interface/auto-negotiation = 0
if/interfaces-state/interface/if-index = 54
if/interfaces-state/interface/oper-status = 1
dell-if/if/interfaces-state/interface/oui = 6976381
dell-if/if/interfaces-state/interface/fec = 2
dell-if/if/interfaces/interface/mtu = 1532
if/interfaces-state/interface/name = br100
if/interfaces/interface/enabled = 0
# VLAN interface is up
opxUser@opx_vm:~$ sudo ip link set dev br100 up
opxUser@opx_vm:~$ ip link show br100
54: br100: <NO-CARRIER,BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default
link/ether 08:00:27:d3:70:29 brd ff:ff:ff:ff:ff:ff
# CPS still reports down
opxUser@opx_vm:~$ sudo cps_get_oid.py observed dell-base-if-cmn/if/interfaces-state/interface
...
if/interfaces-state/interface/admin-status = 1
dell-if/if/interfaces-state/interface/duplex = 1
dell-if/if/interfaces-state/interface/auto-negotiation = 0
if/interfaces-state/interface/if-index = 54
if/interfaces-state/interface/oper-status = 1
dell-if/if/interfaces-state/interface/oui = 6976381
dell-if/if/interfaces-state/interface/fec = 2
dell-if/if/interfaces/interface/mtu = 1532
if/interfaces-state/interface/name = br100
if/interfaces/interface/enabled = 1
Similar to #41 , but I think it's specific to VLAN interfaces
Missing field is dell-base-if-cmn/if/interfaces/interface/type
However, interestingly, I can query interface configuration by type, and the VLAN interface is returned correctly, but still missing the type field:
opxUser@opx_vm:~$ sudo cps_get_oid.py dell-base-if-cmn/if/interfaces/interface if/interfaces/interface/type=ianaift:l2vlan
Key: 1.19.44.2883617.2883612.2883613.
dell-base-if-cmn/if/interfaces/interface/if-index = 54
dell-if/if/interfaces/interface/phys-address = 08:00:27:d3:70:29
base-if-vlan/if/interfaces/interface/id = 100
if/interfaces/interface/name = br100
dell-if/if/interfaces/interface/vlan-type = 1
dell-if/if/interfaces/interface/learning-mode = 1
dell-if/if/interfaces/interface/mtu = 1532
if/interfaces/interface/enabled = 1
Note: the same query by type for interface state does not return anything, but this may be a separate issue, related to #43
sudo cps_get_oid.py observed dell-base-if-cmn/if/interfaces-state/interface if/interfaces-state/interface/type=ianaift:l2vlan
All standardized representations for ENUM and boolean such as RFC 4717, 7951, etc use the textual representation of ENUMs and booleans.
CPS presently can only understand or generate the numerical for ENUMs and uses 0/1 instead of true/false for booleans. This use of yang modeled data is not interoperable and requires the use of yang models to convert it to an interop form on every operation.
In S4248FB-ON the packet with TTL=1 is not lifted to CPU for proper handling.
The CPS transaction to add a LAG interface to a VLAN interface as a tagged port always fails.
The same transaction for an untagged port succeeds.
The trace below demonstrates this behavior.
Note, I've added some print statements to the OPX utilities cps_config_vlan.py
and cps_config_lag.py
to help troubleshooting.
The diff of these exact changes can be found at the end of this post.
bnd1
br10
bnd1
to br10
as an tagged-port. This failsbnd1
as an untagged-port succeeds.Create LAG interface:
opxUser@opx_vm:~$ sudo cps_config_lag.py --create --lname bnd1
Performing: rpc
With CPS object: {'data': {'if/interfaces/interface/type': bytearray(b'ianaift:ieee8023adLag\x00'), 'dell-base-if-cmn/set-interface/input/operation': bytearray(b'\x01\x00\x00\x00'), 'if/interfaces/interface/name': bytearray(b'bnd1\x00')}, 'key': '1.19.1245192.'}
Success
Returned object: [{'operation': 'rpc', 'change': {'operation': 'action', 'data': {'dell-base-if-cmn/if/interfaces/interface/if-index': bytearray(b'4\x00\x00\x00'), 'dell-if/if/interfaces/interface/phys-address': bytearray(b'08:00:27:c8:2a:5b\x00'), 'if/interfaces/interface/name': bytearray(b'bnd1\x00'), 'if/interfaces/interface/type': bytearray(b'ianaift:ieee8023adLag\x00'), 'cps/object-group/return-code': bytearray(b'\x00\x00\x00\x00'), 'dell-base-if-cmn/set-interface/input/operation': bytearray(b'\x01\x00\x00\x00')}, 'key': '1.19.1245192.'}}]
Create VLAN interface:
opxUser@opx_vm:~$ sudo cps_config_vlan.py --add --id 10 --vlantype 1
Performing: rpc
With CPS object: {'data': {'dell-if/if/interfaces/interface/untagged-ports': [bytearray(b'')], 'dell-if/if/interfaces/interface/vlan-type': bytearray(b'\x01\x00\x00\x00'), 'base-if-vlan/if/interfaces/interface/id': bytearray(b'\n\x00'), 'if/interfaces/interface/type': bytearray(b'ianaift:l2vlan\x00'), 'dell-base-if-cmn/set-interface/input/operation': bytearray(b'\x01\x00\x00\x00')}, 'key': '1.19.1245192.'}
Success
Returned object: [{'operation': 'rpc', 'change': {'operation': 'action', 'data': {'dell-base-if-cmn/if/interfaces/interface/if-index': bytearray(b'5\x00\x00\x00'), 'dell-if/if/interfaces/interface/phys-address': bytearray(b'08:00:27:c8:2a:5c\x00'), 'base-if-vlan/if/interfaces/interface/id': bytearray(b'\n\x00'), 'dell-if/if/interfaces/interface/untagged-ports': [bytearray(b'')], 'if/interfaces/interface/type': bytearray(b'ianaift:l2vlan\x00'), 'cps/object-group/return-code': bytearray(b'\x00\x00\x00\x00'), 'dell-if/if/interfaces/interface/vlan-type': bytearray(b'\x01\x00\x00\x00'), 'dell-base-if-cmn/set-interface/input/operation': bytearray(b'\x01\x00\x00\x00')}, 'key': '1.19.1245192.'}}]
Add LAG interface to VLAN interface as tagged-port:
opxUser@opx_vm:~$ sudo cps_config_vlan.py --addport --name br10 --port bnd1 --tagged
Performing: rpc
With CPS object: {'data': {'dell-base-if-cmn/set-interface/input/operation': bytearray(b'\x03\x00\x00\x00'), 'if/interfaces/interface/name': bytearray(b'br10\x00'), 'dell-if/if/interfaces/interface/tagged-ports': [bytearray(b'bnd1\x00')]}, 'key': '1.19.1245192.'}
Failed <------ !
Returned object: [{'operation': 'rpc', 'change': {'operation': 'action', 'data': {'cps/object-group/return-code': bytearray(b'\x01\x00\x00\x00'), 'dell-base-if-cmn/set-interface/input/operation': bytearray(b'\x03\x00\x00\x00'), 'if/interfaces/interface/name': bytearray(b'br10\x00'), 'dell-if/if/interfaces/interface/tagged-ports': [bytearray(b'bnd1\x00')]}, 'key': '1.19.1245192.'}}]
Starting with a fresh VLAN interface, try and add LAG interface as untagged-port:
opxUser@opx_vm:~$ sudo cps_config_vlan.py --addport --name br10 --port bnd1
Performing: rpc
With CPS object: {'data': {'dell-if/if/interfaces/interface/untagged-ports': [bytearray(b'bnd1\x00')], 'dell-base-if-cmn/set-interface/input/operation': bytearray(b'\x03\x00\x00\x00'), 'if/interfaces/interface/name': bytearray(b'br10\x00')}, 'key': '1.19.1245192.'}
Success <------ !
Returned object: [{'operation': 'rpc', 'change': {'operation': 'action', 'data': {'dell-if/if/interfaces/interface/untagged-ports': [bytearray(b'bnd1\x00')], 'dell-base-if-cmn/set-interface/input/operation': bytearray(b'\x03\x00\x00\x00'), 'if/interfaces/interface/name': bytearray(b'br10\x00'), 'cps/object-group/return-code': bytearray(b'\x00\x00\x00\x00')}, 'key': '1.19.1245192.'}}]
What follows is the trace I added to the OPX configuration utilities
nas_ut_framework.py
$ git diff nas_ut_framework.py
diff --git a/scripts/lib/python/nas_ut_framework.py b/scripts/lib/python/nas_ut_framework.py
index 989175e..8e0d649 100755
--- a/scripts/lib/python/nas_ut_framework.py
+++ b/scripts/lib/python/nas_ut_framework.py
@@ -28,7 +28,7 @@ def commit(obj, op):
return l
print "Failed"
- return False
+ return l
def create(obj):
cps_config_vlan.py
$ git diff cps_config_vlan.py
diff --git a/scripts/bin/cps_config_vlan.py b/scripts/bin/cps_config_vlan.py
index 8b1ed9a..bd81cf8 100755
--- a/scripts/bin/cps_config_vlan.py
+++ b/scripts/bin/cps_config_vlan.py
@@ -38,7 +38,10 @@ def nas_vlan_op(op, data_dict):
return False
obj = cps_object.CPSObject( intf_rpc_key_id, data=data_dict)
op = 'rpc'
- nas_ut.get_cb_method(op)(obj)
+ print("\nPerforming: {}".format(op))
+ print("With CPS object: {}\n".format(obj.get()))
+ print("\nReturned object: {}".format(nas_ut.get_cb_method(op)(obj)))
+
cps_config_lag.py
$ git diff cps_config_lag.py
diff --git a/scripts/bin/cps_config_lag.py b/scripts/bin/cps_config_lag.py
index 42bbeb6..d32de98 100755
--- a/scripts/bin/cps_config_lag.py
+++ b/scripts/bin/cps_config_lag.py
@@ -43,7 +43,9 @@ def nas_lag_op(op, data_dict,commit=True):
op = 'rpc'
obj.add_attr("if/interfaces/interface/type","ianaift:ieee8023adLag")
if commit:
- nas_ut.get_cb_method(op)(obj)
+ print("\nPerforming: {}".format(op))
+ print("With CPS object: {}\n".format(obj.get()))
+ print("\nReturned object: {}".format(nas_ut.get_cb_method(op)(obj)))
else:
return (obj, op)
Configuring a name on an ACL object (the base-acl/table/name
leaf) appears not to work:
opxUser@opx_vm:~$ sudo cps_set_oid.py create base-acl/table id=7 name="test" stage=1 allowed-match-fields=1 priority=7
Success
Key: 1.47.3080336.3080284.
base-acl/table/id = 7
cps/object-group/return-code = 0
base-acl/table/id = 7
0 = test
base-acl/table/stage = 1
base-acl/table/priority = 7
base-acl/table/allowed-match-fields = 1
opxUser@opx_vm:~$ sudo cps_get_oid.py target base-acl/table id=7
Key: 1.47.3080336.3080284.
base-acl/table/npu-id-list = 0
base-acl/table/id = 7
base-acl/table/stage = 1
base-acl/table/priority = 7
base-acl/table/allowed-match-fields = 1
base-acl/table/size = 0
Presumably the 0 = test
line in the create output is relevant for understanding why!
Can also reproduce with CPS python API.
If I attempt to set configuration at base-ip/ipv4
then:
Eg:
# cps_get_oid.py target base-ip/ipv4 name=e101-025-0
Key: 1.22.1441814.1441811.1441808.
base-ip/ipv4/vrf-id = 0
base-ip/ipv4/name = e101-025-0
base-ip/ipv4/forwarding = 1
base-ip/ipv4/ifindex = 36
base-ip/ipv4/enabled = 1
# cps_set_oid.py set base-ip/ipv4 name=e101-025-0 forwarding=0
# cps_get_oid.py target base-ip/ipv4 name=e101-025-0
Key: 1.22.1441814.1441811.1441808.
base-ip/ipv4/vrf-id = 0
base-ip/ipv4/name = e101-025-0
base-ip/ipv4/forwarding = 0
base-ip/ipv4/ifindex = 36
base-ip/ipv4/enabled = 1
Note that cps_set_oid.py
did not report success as it does when transactions succeed, although the configuration was apparently successfully applied.
Attempting to set other fields (eg enabled
) fails altogether - which is better, in a sense!
These lines can result in two different nodes having the same n_path
, causing me much confusion.
I hit this on a model where a node contains both config true;
and container config { ... }
As in #33, I may not be able to share the model on which I discovered this - let me know if you need me to construct an example.
I have a leaf-spine network, where a VLAN is created on the leaf (aka ToR) and server facing interfaces are added as members to the bridge corresponding to this VLAN. An IP address is configured on this bridge to represent the SVI. On server, IP is configured on a physical interface and sending untagged packets to ToR SVI IP is not working. Below are further details
OPX version is
root@rack-1-leaf-1:~# opx-show-version
OS_NAME="OPX"
OS_VERSION="2.2.1"
PLATFORM="S4048-ON"
ARCHITECTURE="x86_64"
INTERNAL_BUILD_ID="OpenSwitch blueprint for Dell 1.0.0"
BUILD_VERSION="2.2.1.0"
BUILD_DATE="2018-02-13T13:48:47-0800"
INSTALL_DATE="2018-02-23T03:31:30+0000"
SYSTEM_UPTIME= 59 minutes
SYSTEM_STATE= running
UPGRADED_PACKAGES=no
ALTERED_PACKAGES=no
Contents of /etc/network/interfaces
file are
root@rack-1-leaf-1:~# cat /etc/network/interfaces
auto eth0
iface eth0 inet static
address 172.16.53.77
netmask 255.255.254.0
gateway 172.16.53.254
broadcast 172.16.53.255
dns-nameservers 8.8.8.8
auto lo
iface lo inet loopback
# BEGIN ANSIBLE MANAGED BLOCK
post-up ip netns add mgmt; sleep 1
post-up ln -s /proc/1/ns/net /var/run/netns/default
post-up ip link set eth0 netns mgmt; sleep 1
post-up ip netns exec mgmt ip link set dev eth0 up
post-up ip netns exec mgmt ip addr add 172.16.53.77/23 dev eth0 broadcast 172.16.53.255
post-up ip netns exec mgmt ip route add default dev eth0 via 172.16.53.254
post-up ip netns exec mgmt /usr/sbin/sshd -o PidFile=/run/sshd-mgmt.pid
# END ANSIBLE MANAGED BLOCK
auto lo
iface lo inet loopback
# This file was generated by AOS. Do not edit by hand.
#
# The loopback interface
auto lo
iface lo inet loopback
address 172.16.0.0/32
# Fabric interfaces
auto e101-049-0
iface e101-049-0
address 172.16.0.19/31
alias facing_spine2:e101-022-0
mtu 9050
auto e101-053-0
iface e101-053-0
address 172.16.0.7/31
alias facing_spine1:e101-012-0
mtu 9050
# L3Edge interfaces
auto e101-006-0
iface e101-006-0
address 172.16.0.32/31
alias facing_sio-router-a
# Unused interfaces
auto e101-015-0
iface e101-015-0
auto e101-016-0
iface e101-016-0
auto e101-017-0
iface e101-017-0
auto e101-018-0
iface e101-018-0
auto e101-019-0
iface e101-019-0
auto e101-020-0
iface e101-020-0
auto e101-025-0
iface e101-025-0
auto e101-028-0
iface e101-028-0
auto e101-029-0
iface e101-029-0
auto e101-039-0
iface e101-039-0
auto e101-047-0
iface e101-047-0
auto e101-048-0
iface e101-048-0
auto e101-050-0
iface e101-050-0
auto e101-051-0
iface e101-051-0
auto e101-052-0
iface e101-052-0
auto e101-054-0
iface e101-054-0
auto e101-001-0
iface e101-001-0
alias to.rack-1-sds1:enp1s0f0
auto e101-002-0
iface e101-002-0
alias to.rack-1-sds9:enp1s0f0
auto e101-003-0
iface e101-003-0
alias to.rack-1-sds32:enp1s0f0
auto e101-004-0
iface e101-004-0
alias to.rack-1-sds33:enp1s0f0
auto e101-005-0
iface e101-005-0
alias to.rack-1-sds34:enp1s0f0
auto e101-007-0
iface e101-007-0
alias to.rack-1-sds22:enp1s0f0
auto e101-008-0
iface e101-008-0
alias to.rack-1-sds20:enp1s0f0
auto e101-009-0
iface e101-009-0
alias to.rack-1-sds2:enp1s0f1
auto e101-010-0
iface e101-010-0
alias to.rack-1-sds23:enp1s0f0
auto e101-011-0
iface e101-011-0
alias to.rack-1-sds19:enp1s0f0
auto e101-012-0
iface e101-012-0
alias to.rack-1-sds21:enp1s0f0
auto e101-013-0
iface e101-013-0
alias to.rack-1-sds18:enp1s0f0
auto e101-014-0
iface e101-014-0
alias to.rack-1-sds17:enp1s0f0
auto e101-021-0
iface e101-021-0
alias to.rack-1-sds5:enp1s0f0
auto e101-022-0
iface e101-022-0
alias to.rack-1-sds8:enp1s0f0
auto e101-023-0
iface e101-023-0
alias to.rack-1-sds3:enp1s0f0
auto e101-024-0
iface e101-024-0
alias to.rack-1-sds4:enp1s0f0
auto e101-026-0
iface e101-026-0
alias to.rack-1-sds6:enp1s0f0
auto e101-027-0
iface e101-027-0
alias to.rack-1-sds7:enp1s0f0
auto e101-030-0
iface e101-030-0
alias to.rack-1-mdm1:enp1s0f0
auto e101-031-0
iface e101-031-0
alias to.rack-1-sds16:enp1s0f0
auto e101-032-0
iface e101-032-0
alias to.rack-1-sds15:enp1s0f0
auto e101-033-0
iface e101-033-0
alias to.rack-1-sds13:enp1s0f0
auto e101-034-0
iface e101-034-0
alias to.rack-1-sds14:enp1s0f0
auto e101-035-0
iface e101-035-0
alias to.rack-1-sds12:enp1s0f0
auto e101-036-0
iface e101-036-0
alias to.rack-1-sds10:enp1s0f0
auto e101-037-0
iface e101-037-0
alias to.rack-1-sds24:enp1s0f0
auto e101-038-0
iface e101-038-0
alias to.rack-1-sds11:enp1s0f0
auto e101-040-0
iface e101-040-0
alias to.rack-1-sds29:enp1s0f0
auto e101-041-0
iface e101-041-0
alias to.rack-1-sds26:enp1s0f0
auto e101-042-0
iface e101-042-0
alias to.rack-1-sds31:enp1s0f0
auto e101-043-0
iface e101-043-0
alias to.rack-1-sds28:enp1s0f0
auto e101-044-0
iface e101-044-0
alias to.rack-1-sds25:enp1s0f0
auto e101-045-0
iface e101-045-0
alias to.rack-1-sds30:enp1s0f0
auto e101-046-0
iface e101-046-0
alias to.rack-1-sds27:enp1s0f0
auto br500
iface br500
address 12.12.10.1/26
bridge_ports e101-024-0.500 e101-044-0.500 e101-001-0 e101-002-0 e101-003-0 e101-004-0 e101-005-0 e101-007-0 e101-008-0 e101-009-0 e101-010-0 e101-011-0 e101-012-0 e101-013-0 e101-014-0 e101-021-0 e101-022-0 e101-023-0 e101-026-0 e101-027-0 e101-030-0 e101-031-0 e101-032-0 e101-033-0 e101-034-0 e101-035-0 e101-036-0 e101-037-0 e101-038-0 e101-040-0 e101-041-0 e101-042-0 e101-043-0 e101-045-0 e101-046-0
bridge_stp on
bridge_bridgeprio 8192
Output of ip addr
on ToR
root@rack-1-leaf-1:~# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet 172.16.0.0/32 scope global lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
5: npu-0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether f2:3b:80:b7:4b:e6 brd ff:ff:ff:ff:ff:ff
6: e101-009-0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br500 state UP group default qlen 1000
link/ether 34:17:eb:f4:65:cd brd ff:ff:ff:ff:ff:ff
7: e101-010-0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br500 state UP group default qlen 1000
link/ether 34:17:eb:f4:65:ce brd ff:ff:ff:ff:ff:ff
8: e101-011-0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br500 state UP group default qlen 1000
link/ether 34:17:eb:f4:65:cf brd ff:ff:ff:ff:ff:ff
9: e101-012-0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br500 state UP group default qlen 1000
link/ether 34:17:eb:f4:65:d0 brd ff:ff:ff:ff:ff:ff
10: e101-013-0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br500 state UP group default qlen 1000
link/ether 34:17:eb:f4:65:d1 brd ff:ff:ff:ff:ff:ff
11: e101-014-0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br500 state UP group default qlen 1000
link/ether 34:17:eb:f4:65:d2 brd ff:ff:ff:ff:ff:ff
12: e101-015-0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
link/ether 34:17:eb:f4:65:d3 brd ff:ff:ff:ff:ff:ff
13: e101-016-0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
link/ether 34:17:eb:f4:65:d4 brd ff:ff:ff:ff:ff:ff
14: e101-017-0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
link/ether 34:17:eb:f4:65:d5 brd ff:ff:ff:ff:ff:ff
15: e101-018-0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
link/ether 34:17:eb:f4:65:d6 brd ff:ff:ff:ff:ff:ff
16: e101-019-0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
link/ether 34:17:eb:f4:65:d7 brd ff:ff:ff:ff:ff:ff
17: e101-020-0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
link/ether 34:17:eb:f4:65:d8 brd ff:ff:ff:ff:ff:ff
18: e101-021-0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br500 state UP group default qlen 1000
link/ether 34:17:eb:f4:65:d9 brd ff:ff:ff:ff:ff:ff
19: e101-022-0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br500 state UP group default qlen 1000
link/ether 34:17:eb:f4:65:da brd ff:ff:ff:ff:ff:ff
20: e101-023-0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br500 state UP group default qlen 1000
link/ether 34:17:eb:f4:65:db brd ff:ff:ff:ff:ff:ff
21: e101-024-0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br500 state UP group default qlen 1000
link/ether 34:17:eb:f4:65:dc brd ff:ff:ff:ff:ff:ff
22: e101-001-0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq master br500 state DOWN group default qlen 1000
link/ether 34:17:eb:f4:65:c5 brd ff:ff:ff:ff:ff:ff
23: e101-002-0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq master br500 state DOWN group default qlen 1000
link/ether 34:17:eb:f4:65:c6 brd ff:ff:ff:ff:ff:ff
24: e101-003-0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq master br500 state DOWN group default qlen 1000
link/ether 34:17:eb:f4:65:c7 brd ff:ff:ff:ff:ff:ff
25: e101-004-0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq master br500 state DOWN group default qlen 1000
link/ether 34:17:eb:f4:65:c8 brd ff:ff:ff:ff:ff:ff
26: e101-005-0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br500 state UP group default qlen 1000
link/ether 34:17:eb:f4:65:c9 brd ff:ff:ff:ff:ff:ff
27: e101-006-0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 34:17:eb:f4:65:ca brd ff:ff:ff:ff:ff:ff
inet 172.16.0.32/31 scope global e101-006-0
valid_lft forever preferred_lft forever
inet6 fe80::3617:ebff:fef4:65ca/64 scope link
valid_lft forever preferred_lft forever
28: e101-007-0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br500 state UP group default qlen 1000
link/ether 34:17:eb:f4:65:cb brd ff:ff:ff:ff:ff:ff
29: e101-008-0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br500 state UP group default qlen 1000
link/ether 34:17:eb:f4:65:cc brd ff:ff:ff:ff:ff:ff
30: e101-025-0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
link/ether 34:17:eb:f4:65:dd brd ff:ff:ff:ff:ff:ff
31: e101-026-0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br500 state UP group default qlen 1000
link/ether 34:17:eb:f4:65:de brd ff:ff:ff:ff:ff:ff
32: e101-027-0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br500 state UP group default qlen 1000
link/ether 34:17:eb:f4:65:df brd ff:ff:ff:ff:ff:ff
33: e101-028-0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
link/ether 34:17:eb:f4:65:e0 brd ff:ff:ff:ff:ff:ff
34: e101-029-0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
link/ether 34:17:eb:f4:65:e1 brd ff:ff:ff:ff:ff:ff
35: e101-030-0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br500 state UP group default qlen 1000
link/ether 34:17:eb:f4:65:e2 brd ff:ff:ff:ff:ff:ff
36: e101-031-0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br500 state UP group default qlen 1000
link/ether 34:17:eb:f4:65:e3 brd ff:ff:ff:ff:ff:ff
37: e101-032-0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br500 state UP group default qlen 1000
link/ether 34:17:eb:f4:65:e4 brd ff:ff:ff:ff:ff:ff
38: e101-033-0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br500 state UP group default qlen 1000
link/ether 34:17:eb:f4:65:e5 brd ff:ff:ff:ff:ff:ff
39: e101-034-0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br500 state UP group default qlen 1000
link/ether 34:17:eb:f4:65:e6 brd ff:ff:ff:ff:ff:ff
40: e101-035-0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br500 state UP group default qlen 1000
link/ether 34:17:eb:f4:65:e7 brd ff:ff:ff:ff:ff:ff
41: e101-036-0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br500 state UP group default qlen 1000
link/ether 34:17:eb:f4:65:e8 brd ff:ff:ff:ff:ff:ff
42: e101-037-0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br500 state UP group default qlen 1000
link/ether 34:17:eb:f4:65:e9 brd ff:ff:ff:ff:ff:ff
43: e101-038-0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br500 state UP group default qlen 1000
link/ether 34:17:eb:f4:65:ea brd ff:ff:ff:ff:ff:ff
44: e101-039-0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
link/ether 34:17:eb:f4:65:eb brd ff:ff:ff:ff:ff:ff
45: e101-040-0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br500 state UP group default qlen 1000
link/ether 34:17:eb:f4:65:ec brd ff:ff:ff:ff:ff:ff
46: e101-041-0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br500 state UP group default qlen 1000
link/ether 34:17:eb:f4:65:ed brd ff:ff:ff:ff:ff:ff
47: e101-042-0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br500 state UP group default qlen 1000
link/ether 34:17:eb:f4:65:ee brd ff:ff:ff:ff:ff:ff
48: e101-043-0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br500 state UP group default qlen 1000
link/ether 34:17:eb:f4:65:ef brd ff:ff:ff:ff:ff:ff
49: e101-044-0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 34:17:eb:f4:65:f0 brd ff:ff:ff:ff:ff:ff
50: e101-045-0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br500 state UP group default qlen 1000
link/ether 34:17:eb:f4:65:f1 brd ff:ff:ff:ff:ff:ff
51: e101-046-0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br500 state UP group default qlen 1000
link/ether 34:17:eb:f4:65:f2 brd ff:ff:ff:ff:ff:ff
52: e101-047-0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
link/ether 34:17:eb:f4:65:f3 brd ff:ff:ff:ff:ff:ff
53: e101-048-0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
link/ether 34:17:eb:f4:65:f4 brd ff:ff:ff:ff:ff:ff
54: e101-054-0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 34:17:eb:f4:66:09 brd ff:ff:ff:ff:ff:ff
inet6 fe80::3617:ebff:fef4:6609/64 scope link
valid_lft forever preferred_lft forever
55: e101-053-0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9050 qdisc mq state UP group default qlen 1000
link/ether 34:17:eb:f4:66:05 brd ff:ff:ff:ff:ff:ff
inet 172.16.0.7/31 scope global e101-053-0
valid_lft forever preferred_lft forever
inet6 fe80::3617:ebff:fef4:6605/64 scope link
valid_lft forever preferred_lft forever
56: e101-050-0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 34:17:eb:f4:65:f9 brd ff:ff:ff:ff:ff:ff
inet6 fe80::3617:ebff:fef4:65f9/64 scope link
valid_lft forever preferred_lft forever
57: e101-049-0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9050 qdisc mq state UP group default qlen 1000
link/ether 34:17:eb:f4:65:f5 brd ff:ff:ff:ff:ff:ff
inet 172.16.0.19/31 scope global e101-049-0
valid_lft forever preferred_lft forever
inet6 fe80::3617:ebff:fef4:65f5/64 scope link
valid_lft forever preferred_lft forever
58: e101-052-0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 34:17:eb:f4:66:01 brd ff:ff:ff:ff:ff:ff
inet6 fe80::3617:ebff:fef4:6601/64 scope link
valid_lft forever preferred_lft forever
59: e101-051-0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 34:17:eb:f4:65:fd brd ff:ff:ff:ff:ff:ff
inet6 fe80::3617:ebff:fef4:65fd/64 scope link
valid_lft forever preferred_lft forever
60: br500: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 34:17:eb:f4:66:8d brd ff:ff:ff:ff:ff:ff
inet 12.12.10.1/26 scope global br500
valid_lft forever preferred_lft forever
inet6 fe80::3617:ebff:fef4:65c5/64 scope link
valid_lft forever preferred_lft forever
61: e101-044-0.500@e101-044-0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br500 state UP group default
link/ether 34:17:eb:f4:65:f0 brd ff:ff:ff:ff:ff:ff
62: e101-024-0.500@e101-024-0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br500 state UP group default
link/ether 34:17:eb:f4:65:dc brd ff:ff:ff:ff:ff:ff
Output of brctl show
root@rack-1-leaf-1:~# brctl show
bridge name bridge id STP enabled interfaces
br500 2000.3417ebf4668d yes e101-001-0
e101-002-0
e101-003-0
e101-004-0
e101-005-0
e101-007-0
e101-008-0
e101-009-0
e101-010-0
e101-011-0
e101-012-0
e101-013-0
e101-014-0
e101-021-0
e101-022-0
e101-023-0
e101-024-0
e101-024-0.500
e101-026-0
e101-027-0
e101-030-0
e101-031-0
e101-032-0
e101-033-0
e101-034-0
e101-035-0
e101-036-0
e101-037-0
e101-038-0
e101-040-0
e101-041-0
e101-042-0
e101-043-0
e101-044-0.500
e101-045-0
e101-046-0
Output of opx-switch-shell 'vlan show'
root@rack-1-leaf-1:~# opx-switch-shell "vlan show"
vlan 1 ports none (0x0000000000000000000000000000000000000000000000000000000000000000), untagged none (0x0000000000000000000000000000000000000000000000000000000000000000) MCAST_FLOOD_UNKNOWN
vlan 500 ports xe0-xe4,xe6-xe13,xe20-xe23,xe25-xe26,xe29-xe37,xe39-xe45 (0x00000000000000000000000000000000000000000000000000007f7fcde07fbe), untagged xe0-xe4,xe6-xe13,xe20-xe23,xe25-xe26,xe29-xe37,xe39-xe42,xe44-xe45 (0x00000000000000000000000000000000000000000000000000006f7fcde07fbe) MCAST_FLOOD_UNKNOWN
vlan 4095 ports xe (0x0000000000000000000000000000000000000000000001fffffffffffffffffe), untagged xe (0x0000000000000000000000000000000000000000000001fffffffffffffffffe) MCAST_FLOOD_UNKNOWN
SAI.0>
Output of cps_config_vlan.py --show
on ToR
root@rack-1-leaf-1:~# cps_config_vlan.py --show
Key: 1.19.44.2883617.2883612.2883613.
dell-base-if-cmn/if/interfaces/interface/if-index = 62
dell-if/if/interfaces/interface/phys-address = 34:17:eb:f4:66:8d
dell-if/if/interfaces/interface/untagged-ports = e101-046-0,e101-007-0,e101-035-0,e101-021-0,e101-036-0,e101-011-0,e101-012-0,e101-037-0,e101-008-0,e101-009-0,e101-034-0,e101-003-0,e101-004-0,e101-005-0,e101-032-0,e101-013-0,e101-045-0,e101-022-0,e101-027-0,e101-014-0,e101-010-0,e101-030-0,e101-023-0,e101-040-0,e101-033-0,e101-041-0,e101-031-0,e101-042-0,e101-001-0,e101-043-0,e101-002-0,e101-026-0,e101-038-0
base-if-vlan/if/interfaces/interface/id = 500
if/interfaces/interface/name = br500
dell-if/if/interfaces/interface/vlan-type = 0
dell-if/if/interfaces/interface/learning-mode = 1
dell-if/if/interfaces/interface/mtu = 1532
if/interfaces/interface/enabled = 0
dell-if/if/interfaces/interface/tagged-ports = e101-024-0,e101-044-0
Output of ip addr
on server
root@rack-1-SDS4:/var/log/aos# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet 10.0.1.4/32 scope global lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 20:47:47:7e:57:34 brd ff:ff:ff:ff:ff:ff
inet 172.16.52.113/23 brd 172.16.53.255 scope global eno1
valid_lft forever preferred_lft forever
inet6 fe80::2247:47ff:fe7e:5734/64 scope link
valid_lft forever preferred_lft forever
3: eno2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 20:47:47:7e:57:36 brd ff:ff:ff:ff:ff:ff
4: enp1s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq portid 000e1e986ce0 state UP group default qlen 1000
link/ether 00:0e:1e:98:6c:e0 brd ff:ff:ff:ff:ff:ff
inet 12.12.10.6/26 scope global enp1s0f0
valid_lft forever preferred_lft forever
5: enp1s0f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq portid 000e1e986ce2 state UP group default qlen 1000
link/ether 00:0e:1e:98:6c:e2 brd ff:ff:ff:ff:ff:ff
inet 12.12.10.70/26 scope global enp1s0f1
valid_lft forever preferred_lft forever
Ping from server to ToR SVI IP
root@rack-1-SDS4:/var/log/aos# ping 12.12.10.1
PING 12.12.10.1 (12.12.10.1) 56(84) bytes of data.
^C
--- 12.12.10.1 ping statistics ---
852 packets transmitted, 0 received, 100% packet loss, time 850999ms
tcpdump from server interface
root@rack-1-SDS4:/var/log/aos# tcpdump -i enp1s0f0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp1s0f0, link-type EN10MB (Ethernet), capture size 262144 bytes
13:27:01.539486 STP 802.1d, Config, Flags [none], bridge-id 2000.34:17:eb:f4:66:8d.8024, length 43
13:27:01.539494 STP 802.1d, Config, Flags [none], bridge-id 2000.34:17:eb:f4:66:8d.8002, length 43
13:27:03.539387 STP 802.1d, Config, Flags [none], bridge-id 2000.34:17:eb:f4:66:8d.8024, length 43
13:27:03.539396 STP 802.1d, Config, Flags [none], bridge-id 2000.34:17:eb:f4:66:8d.8002, length 43
13:27:05.539401 STP 802.1d, Config, Flags [none], bridge-id 2000.34:17:eb:f4:66:8d.8024, length 43
13:27:05.539409 STP 802.1d, Config, Flags [none], bridge-id 2000.34:17:eb:f4:66:8d.8002, length 43
13:27:07.475113 IP 12.12.10.6 > 12.12.10.1: ICMP echo request, id 10519, seq 1, length 64
13:27:07.539487 STP 802.1d, Config, Flags [none], bridge-id 2000.34:17:eb:f4:66:8d.8024, length 43
13:27:07.539512 STP 802.1d, Config, Flags [none], bridge-id 2000.34:17:eb:f4:66:8d.8002, length 43
13:27:08.474889 IP 12.12.10.6 > 12.12.10.1: ICMP echo request, id 10519, seq 2, length 64
13:27:09.289365 LLDP, length 260: Rack-1-Leaf-1
13:27:09.474828 IP 12.12.10.6 > 12.12.10.1: ICMP echo request, id 10519, seq 3, length 64
13:27:09.539262 STP 802.1d, Config, Flags [none], bridge-id 2000.34:17:eb:f4:66:8d.8024, length 43
13:27:09.539275 STP 802.1d, Config, Flags [none], bridge-id 2000.34:17:eb:f4:66:8d.8002, length 43
13:27:10.474864 IP 12.12.10.6 > 12.12.10.1: ICMP echo request, id 10519, seq 4, length 64
13:27:11.474837 IP 12.12.10.6 > 12.12.10.1: ICMP echo request, id 10519, seq 5, length 64
13:27:11.539024 STP 802.1d, Config, Flags [none], bridge-id 2000.34:17:eb:f4:66:8d.8024, length 43
13:27:11.539033 STP 802.1d, Config, Flags [none], bridge-id 2000.34:17:eb:f4:66:8d.8002, length 43
13:27:12.474826 IP 12.12.10.6 > 12.12.10.1: ICMP echo request, id 10519, seq 6, length 64
13:27:13.474777 IP 12.12.10.6 > 12.12.10.1: ICMP echo request, id 10519, seq 7, length 64
13:27:13.539049 STP 802.1d, Config, Flags [none], bridge-id 2000.34:17:eb:f4:66:8d.8024, length 43
13:27:13.539059 STP 802.1d, Config, Flags [none], bridge-id 2000.34:17:eb:f4:66:8d.8002, length 43
13:27:14.474849 IP 12.12.10.6 > 12.12.10.1: ICMP echo request, id 10519, seq 8, length 64
13:27:15.474846 IP 12.12.10.6 > 12.12.10.1: ICMP echo request, id 10519, seq 9, length 64
tcpdump from ToR interface
root@rack-1-leaf-1:~# tcpdump -i e101-024-0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on e101-024-0, link-type EN10MB (Ethernet), capture size 262144 bytes
20:30:21.996393 LLDP, length 260: Rack-1-Leaf-1
20:30:22.250998 STP 802.1d, Config, Flags [none], bridge-id 2000.34:17:eb:f4:66:8d.8024, length 35
20:30:22.251025 STP 802.1d, Config, Flags [none], bridge-id 2000.34:17:eb:f4:66:8d.8002, length 35
20:30:22.700242 LLDP, length 85
20:30:24.250975 STP 802.1d, Config, Flags [none], bridge-id 2000.34:17:eb:f4:66:8d.8024, length 35
20:30:24.251000 STP 802.1d, Config, Flags [none], bridge-id 2000.34:17:eb:f4:66:8d.8002, length 35
20:30:26.250975 STP 802.1d, Config, Flags [none], bridge-id 2000.34:17:eb:f4:66:8d.8024, length 35
20:30:26.251000 STP 802.1d, Config, Flags [none], bridge-id 2000.34:17:eb:f4:66:8d.8002, length 35
20:30:28.250978 STP 802.1d, Config, Flags [none], bridge-id 2000.34:17:eb:f4:66:8d.8024, length 35
20:30:28.251018 STP 802.1d, Config, Flags [none], bridge-id 2000.34:17:eb:f4:66:8d.8002, length 35
20:30:30.250977 STP 802.1d, Config, Flags [none], bridge-id 2000.34:17:eb:f4:66:8d.8024, length 35
20:30:30.251013 STP 802.1d, Config, Flags [none], bridge-id 2000.34:17:eb:f4:66:8d.8002, length 35
20:30:32.250980 STP 802.1d, Config, Flags [none], bridge-id 2000.34:17:eb:f4:66:8d.8024, length 35
20:30:32.251015 STP 802.1d, Config, Flags [none], bridge-id 2000.34:17:eb:f4:66:8d.8002, length 35
20:30:34.251008 STP 802.1d, Config, Flags [none], bridge-id 2000.34:17:eb:f4:66:8d.8024, length 35
20:30:34.251034 STP 802.1d, Config, Flags [none], bridge-id 2000.34:17:eb:f4:66:8d.8002, length 35
20:30:35.298740 LLDP, length 216: rack-1-SDS4
20:30:36.250976 STP 802.1d, Config, Flags [none], bridge-id 2000.34:17:eb:f4:66:8d.8024, length 35
20:30:36.251002 STP 802.1d, Config, Flags [none], bridge-id 2000.34:17:eb:f4:66:8d.8002, length 35
20:30:38.250974 STP 802.1d, Config, Flags [none], bridge-id 2000.34:17:eb:f4:66:8d.8024, length 35
20:30:38.251001 STP 802.1d, Config, Flags [none], bridge-id 2000.34:17:eb:f4:66:8d.8002, length 35
20:30:40.250976 STP 802.1d, Config, Flags [none], bridge-id 2000.34:17:eb:f4:66:8d.8024, length 35
20:30:40.251014 STP 802.1d, Config, Flags [none], bridge-id 2000.34:17:eb:f4:66:8d.8002, length 35
20:30:42.250974 STP 802.1d, Config, Flags [none], bridge-id 2000.34:17:eb:f4:66:8d.8024, length 35
20:30:42.251006 STP 802.1d, Config, Flags [none], bridge-id 2000.34:17:eb:f4:66:8d.8002, length 35
It is a standard expectation for a yang tree that a read at any level will yield the branches under that level.
For example:
if we have a tree of {"if":{"interfaces":[...]}} a read at if will produce the contents of the "if" container and all of its included lists.
In cps it does not - there are several places in the model where the top level container containing interesting lists cannot be read. Specifically - the above example (it is parented in the incorrect location - dell-base-cmn which is in a separate issue).
Dell-base-common augments ietf-interfaces.
The expectation would be that the keys should still be from ietf-interfaces instead of dell-base-common. Not the case.
Additionally, to add to the confusion, while the keys are under dell-base-cmn, the data is still under if/ +/- augmentations.
This makes the whole interface tree non-interoperable versus upstream implementations without remapping and re-parenting it for presentation.
I saw you added VLAN sub-interfaces to the dell-base-interface-common.yang model.
However they don't seem to be accessible at all via CPS.
They are currently a requirement for our ability to configure tagged sub-ports on VLANs.
Am I doing something wrong, or are they unsupported for querying and configuration via CPS?
sample trace:
root@OPX:/usr/bin# ip link add link e101-026-0 name e101-026-0.100 type vlan id 100
root@OPX:/usr/bin# ip link | tail -n 2
44: e101-026-0.100@e101-026-0: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN mode DEFAULT group default
link/ether 34:17:eb:2c:d7:65 brd ff:ff:ff:ff:ff:ff
# Querying by type returns nothing
root@OPX:/usr/bin# sudo cps_get_oid.py dell-base-if-cmn/if/interfaces/interface if/interfaces/interface/type=base-if:vlanSubInterface
# Querying all config or state and searching for "026" only returns results from the original interface
# And viewing the full output confirms the subinterface is not present
root@OPX:/usr/bin# sudo cps_get_oid.py dell-base-if-cmn/if/interfaces/interface | grep 026
if/interfaces/interface/name = e101-026-0
root@OPX:/usr/bin# sudo cps_get_oid.py -qua observed dell-base-if-cmn/if/interfaces-state/interface | grep 026
if/interfaces-state/interface/name = e101-026-0
if/interfaces-state/interface/name = e101-026-0 # (duplicates as per https://github.com/open-switch/opx-cps/issues/42)
I am trying to register a handler in python for a new model.
The model augments if/interfaces/interface:
augment "/if:interfaces/if:interface" {
when "if:type = 'ianaift:l2vlan'";
It is added successfully to the models, everything is recompiled and cps.type() reports the correct information on it.
cps.type("dhcp-agent/if/interfaces/interface")
{'name': 'dhcp-agent/if/interfaces/interface', 'embedded': 'True', 'attribute_type': 'container', 'data_type': 'bin', 'key': '300.44.2883617.2883612.2883613', 'id': '19661025', 'description': ''}
I am testing the object registration for this path using the following simple python snippet:
#!/usr/bin/env python
'''DHCP Agent CPS Registration'''
import cps
import cps_utils
PATH = 'dhcp-agent/if/interfaces/interface'
def test_get(arg):
print "test get invoked with args {}".format(arg)
return True
class DHCPRegistration(object):
'''CPS Registration handler for DHCP'''
def __init__(self):
self.handle = cps.obj_init()
self.callback = {"get".encode('ascii'):test_get, "transaction".encode('ascii'):self.transaction}
cps.obj_register(self.handle, PATH, self.callback)
def get(self, arg):
'''Get Handler'''
print "get invoked with args {}".format(arg)
def transaction(self, arg):
'''Transaction Handler'''
print "transaction invoked with args {}".format(arg)
Trying to upgrade boxes via deb http://deb.openswitch.net/ testing main
:
root@OPX1:~# apt-get dist-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
You might want to run 'apt-get -f install' to correct these.
The following packages have unmet dependencies:
opx-nas-daemon : Depends: libopx-sai
E: Unmet dependencies. Try using -f.
But then:
root@OPX1:~# apt-get -f install
Reading package lists... Done
Building dependency tree
Reading state information... Done
Correcting dependencies... Done
The following extra packages will be installed:
libopx-sai-vm1
The following NEW packages will be installed:
libopx-sai-vm1
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
3 not fully installed or removed.
Need to get 0 B/508 kB of archives.
After this operation, 1705 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = "en_GB.utf8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
(Reading database ... 28293 files and directories currently installed.)
Preparing to unpack .../libopx-sai-vm1_17.1.0+opx4_amd64.deb ...
Unpacking libopx-sai-vm1 (17.1.0+opx4) ...
dpkg: error processing archive /var/cache/apt/archives/libopx-sai-vm1_17.1.0+opx4_amd64.deb (--unpack):
trying to overwrite '/usr/lib/x86_64-linux-gnu/libsai-0.9.6.so.1.0.0', which is also in package libopx-sai-bcm-esw1 21.1.0
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
Errors were encountered while processing:
/var/cache/apt/archives/libopx-sai-vm1_17.1.0+opx4_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
Here's opx-show-version
:
root@OPX1:~# opx-show-version
OS_NAME="OPX"
OS_VERSION="2.1.0"
PLATFORM="S6000-ON"
ARCHITECTURE="x86_64"
INTERNAL_BUILD_ID="OpenSwitch blueprint for Dell 1.0.0"
BUILD_VERSION="2.1.0(0)"
BUILD_DATE="2017-08-04T12:01:19-0700"
INSTALL_DATE="2017-08-17T22:53:49+0000"
SYSTEM_UPTIME= 4 days, 5 hours, 24 minutes
SYSTEM_STATE= degraded
UPGRADED_PACKAGES=no
ALTERED_PACKAGES=no
Please advise.
When I try to configure a LAG Interface object in CPS with blocked-ports
and unblocked-ports
, all of the ports I included in both lists end up in blocked-ports
.
I've worked around this by doing two separate transactions - one to set blocked-ports
, a second for unblocked-ports
.
However, this is still inconsistent with how CPS treats lists of ports.
For example, when configuring VLAN interfaces, CPS will happily configure tagged-ports
and untagged-ports
in a single transaction. LAG interfaces should act in the same way.
Trace:
# Create a lag port
opxUser@opx_vm:~$ sudo cps_config_lag.py --create --lname bnd2
Success
# Give it some member ports
opxUser@opx_vm:~$ sudo cps_config_lag.py --add --lname bnd2 --port e101-021-0,e101-022-0
Success
# So now I have an interface with some member ports (they go into unblocked by default)
opxUser@opx_vm:~$ sudo cps_get_oid.py dell-base-if-cmn/if/interfaces/interface if/interfaces/interface/name=bnd2 | grep port
dell-if/if/interfaces/interface/member-ports/name = e101-021-0
dell-if/if/interfaces/interface/member-ports/name = e101-022-0
base-if-lag/if/interfaces/interface/unblock-port-list = e101-022-0,e101-021-0
base-if-lag/if/interfaces/interface/block-port-list =
# Setting both blocked and unblocked ports seems to succeed
opxUser@opx_vm:~$ sudo cps_set_oid.py -qua target -oper action dell-base-if-cmn/set-interface dell-base-if-cmn/set-interface/input/operation=3 if/interfaces/interface/name=bnd2 if/interfaces/interface/type=ianaift:ieee8023adLag base-if-lag/if/interfaces/interface/block-port-list=e101-022-0 base-if-lag/if/interfaces/interface/unblock-port-list=e101-021-0
Success
Key: 1.19.1245192.
if/interfaces/interface/name = bnd2
if/interfaces/interface/type = ianaift:ieee8023adLag
cps/object-group/return-code = 0
base-if-lag/if/interfaces/interface/unblock-port-list = e101-021-0 <-----
dell-base-if-cmn/set-interface/input/operation = 3
base-if-lag/if/interfaces/interface/block-port-list = e101-022-0 <-----
# But in fact, all ports are found in the "blocked-ports" list
opxUser@opx_vm:~$ sudo cps_get_oid.py dell-base-if-cmn/if/interfaces/interface if/interfaces/interface/name=bnd2 | grep port
dell-if/if/interfaces/interface/member-ports/name = e101-021-0
dell-if/if/interfaces/interface/member-ports/name = e101-022-0
base-if-lag/if/interfaces/interface/unblock-port-list =
base-if-lag/if/interfaces/interface/block-port-list = e101-022-0,e101-021-0 <-------
The standard for a Yang Instance Identifier in yang data is different from the actual model data including YIN. Model grammar specifies:
[prefix:] identifier
That is fine for the model, because there is an implicit guarantee that [prefix:]identifier is locally unique and has local meaning.
Using this notation for data keys has issues for data interop.
While it is possible to map this to netconf and xml/restconf instance identifiers with the assistance of schema it will break for JSON data where the canonical form uses module-name (with optional revision qualifiers) for prefixes.
The model below results in a header file with conflicting definitions for EXAMPLE_FOO_t:
(Of course I hit this on a real model, this is just a reduced testcase).
module example {
namespace "http://example.com";
prefix example;
typedef foo {
type uint32;
}
list foo {
key "bar";
leaf bar {
type uint32;
}
}
}
Compiling the output gives this error:
In file included from opx/example.cpp:4:0:
opx/example.h:42:3: error: conflicting declaration 'typedef enum EXAMPLE_FOO_t EXAMPLE_FOO_t'
} EXAMPLE_FOO_t;
^
opx/example.h:34:18: note: previous declaration as 'typedef uint32_t EXAMPLE_FOO_t'
typedef uint32_t EXAMPLE_FOO_t;
^
As discussed in #51. Here's a session on a 2.2 VM:
opxUser@opx_vm:~$ sudo cps_set_oid.py -qua target -oper action dell-base-if-cmn/set-interface dell-base-if-cmn/set-interface/input/operation=2 if/interfaces/interface/name=e101-002-0
Success
Key: 1.19.1245192.
cps/object-group/return-code = 0
dell-base-if-cmn/set-interface/input/operation = 2
if/interfaces/interface/name = e101-002-0
opxUser@opx_vm:~$
opxUser@opx_vm:~$ sudo cps_set_oid.py -qua target -oper action dell-base-if-cmn/set-interface dell-base-if-cmn/set-interface/input/operation=1 if/interfaces/interface/name=e101-002-0 if/interfaces/interface/type=ianaift:ethernetCsmacd
Success
Key: 1.19.1245192.
dell-base-if-cmn/if/interfaces/interface/if-index = 37
if/interfaces/interface/name = e101-002-0
if/interfaces/interface/type = ianaift:ethernetCsmacd
cps/object-group/return-code = 0
dell-base-if-cmn/set-interface/input/operation = 1
dell-if/if/interfaces/interface/negotiation = 1
opxUser@opx_vm:~$
opxUser@opx_vm:~$ sudo cps_set_oid.py -qua target -oper action dell-base-if-cmn/set-interface dell-base-if-cmn/set-interface/input/operation=2 if/interfaces/interface/name=e101-002-0
opxUser@opx_vm:~$
Notice that the third command - the second attempt to delete the interface - does not succeed.
Are L3ipvlan type interfaces currently supported?
I have been unable to create interfaces of this type:
Note, I'm currently using v2.1
We sometimes see a VM get into a state where attempts to set an IP address on an interface fail.
It's currently unclear exactly what the necessary steps to reproduce this are - I am working on getting a clearer picture of this.
Once in the bad state, attempts to set an IP address via CPS fail. Eg running this script results in us hitting the error branch.
I've seen examples where the opx-pas
service has failed - but restarting it does not resolve the problem.
I've also seen examples where the opx-nas
service makes a series of interesting logs:
root@NST-OPX-TEST-001:~# systemctl -l status opx-nas.service
● opx-nas.service - Network abstraction service
Loaded: loaded (/lib/systemd/system/opx-nas.service; enabled)
Active: active (running) since Mon 2018-02-26 15:13:09 UTC; 46min ago
Process: 645 ExecStartPre=/usr/bin/dn_rules.sh (code=exited, status=0/SUCCESS)
Main PID: 703 (opx_nas_daemon)
CGroup: /system.slice/opx-nas.service
└─703 /usr/bin/opx_nas_daemon
Feb 26 15:59:34 NST-OPX-TEST-001 opx_nas_daemon[703]: [INTERFACE:INTF-C], No npu port attribute found in event object
Feb 26 15:59:34 NST-OPX-TEST-001 opx_nas_daemon[703]: [ev_log_t_SAI_PORT:Switch Id: 0], Attr get for port id 0x1000000000001's attr index 0 attr id 76 failed with err -65536
Feb 26 15:59:34 NST-OPX-TEST-001 opx_nas_daemon[703]: [ev_log_t_SAI_PORT:Switch Id: 0], Attr get for port id 0x1000000000001's attr index 0 attr id 76 failed with err -65536
Feb 26 15:59:34 NST-OPX-TEST-001 opx_nas_daemon[703]: [DSAPI:CPS-EVNT-THREAD], Event processing has been stopped due to negative return from CB observed/dell-base-if-cmn/if/interfaces-state/interface
if/interfaces-state/interface/name : e101-001-0
if/interfaces-state/interface/if-index : 3
if/interfaces-state/interface/admin-status : 1
Feb 26 15:59:34 NST-OPX-TEST-001 opx_nas_daemon[703]: [INTERFACE:INTF-C], No npu port attribute found in event object
Feb 26 15:59:34 NST-OPX-TEST-001 opx_nas_daemon[703]: [INTERFACE:INTF-C], No npu port attribute found in event object
Feb 26 15:59:34 NST-OPX-TEST-001 opx_nas_daemon[703]: [INTERFACE:INTF-C], No npu port attribute found in event object
Feb 26 15:59:34 NST-OPX-TEST-001 opx_nas_daemon[703]: [ev_log_t_SAI_PORT:Switch Id: 0], Attr get for port id 0x1000000000001's attr index 0 attr id 76 failed with err -65536
Feb 26 15:59:34 NST-OPX-TEST-001 opx_nas_daemon[703]: [ev_log_t_SAI_PORT:Switch Id: 0], Attr get for port id 0x1000000000001's attr index 0 attr id 76 failed with err -65536
Feb 26 15:59:34 NST-OPX-TEST-001 opx_nas_daemon[703]: [ev_log_t_SAI_PORT:Switch Id: 0], Attr get for port id 0x1000000000001's attr index 0 attr id 76 failed with err -65536
... but restarting the opx-nas
service does not resolve the issue either.
Rebooting the box does allow IP address configuration to start succeeding again.
Where should we be looking for additional diagnostics to explain what is going on when the configuration fails?
Thanks!
I'm attempting to get state information for VLAN interfaces.
The following fields from dell-if-vlan.yang are absent when querying dell-base-if-cmn/if/interfaces-state/interface
:
dell-if/if/interfaces/interface/untagged-ports
dell-if/if/interfaces/interface/tagged-ports
base-if-vlan/if/interfaces/interface/id
dell-if/if/interfaces/interface/vlan-type
It would certainly be useful to be able to query the state of these absent fields via dell-base-if-cmn/if/interfaces-state/interface
.
I also understand a similar situation is true for LAG interfaces (id, unblock-port-list, block-port-list)
I realise the fields I've listed here actually belong to dell-base-if-cmn/if/interfaces/interface
(not interfaces-state). However there is precedent for exposing useful equivalent interfaces fields in dell-base-if-cmn/if/interfaces-state/interface
, for example we get the following fields from if/interfaces-state
, even though the YANG model defines them under if/interfaces
:
dell-if/if/interfaces/interface/phys-address
dell-if/if/interfaces/interface/mtu
if/interfaces/interface/enabled
Do you intend to support accessing these fields for VLAN and LAG interfaces through the above query?
If not, how should I determine which fields are actually accessible through interfaces-state, if the YANG models alone do not indicate it?
cps_set_oid.py
does not save L2 configuration.
root@OPX:~# opx-show-version
OS_NAME="OPX"
OS_VERSION="2.2"
PLATFORM="S3048-ON"
ARCHITECTURE="x86_64"
INTERNAL_BUILD_ID="OpenSwitch blueprint for Dell 1.0.0"
BUILD_VERSION="2.2.0"
BUILD_DATE="2018-01-26T10:03:01-0800"
INSTALL_DATE="2018-02-20T23:16:15+0000"
SYSTEM_UPTIME= 2 minutes
SYSTEM_STATE= running
UPGRADED_PACKAGES=no
ALTERED_PACKAGES=no
Create and apply a vlan on a UNTAGGED interface
root@OPX:/# cps_config_vlan.py --add --id 1011 --vlantype 1 --port e101-001-0,e101-002-0
Success
Now, verify the configuration with cps_get_oid.py
root@OPX:/# cps_get_oid.py -qua target dell-base-if-cmn/if/interfaces/interface if/interfaces/interface/type=ianaift:l2vlan
============1.19.44.2883617.2883612.2883613.==========
dell-base-if-cmn/if/interfaces/interface/if-index = 56
dell-if/if/interfaces/interface/phys-address = 64:00:6a:aa:bb:cc
dell-if/if/interfaces/interface/untagged-ports = e101-002-0,e101-001-0
base-if-vlan/if/interfaces/interface/id = 1011
if/interfaces/interface/name = br1011
dell-if/if/interfaces/interface/vlan-type = 1
dell-if/if/interfaces/interface/learning-mode = 1
dell-if/if/interfaces/interface/mtu = 1532
if/interfaces/interface/enabled = 0
now, check the L2 connectivity with a device (here, my laptop)
root@OPX:/# opx-switch-shell "l2 show"
SAI.0>
in fact, it seems necessary to shut and no shut vlan and interfaces
root@OPX:/# ifconfig br1011 down
root@OPX:/# ifconfig e101-001-0 down
root@OPX:/# ifconfig e101-002-0 down
root@OPX:/# ifconfig br1011 up
root@OPX:/# ifconfig e101-001-0 up
root@OPX:/# ifconfig e101-002-0 up
root@OPX:/# opx-switch-shell "l2 show"
mac=00:22:20:aa:bb:cc vlan=1011 GPORT=0x1 modid=0 port=1/ge1 Hit
SAI.0>
Now, it seems ok (mac and untagged vlan)
For this test, set an ip address on br1011
root@OPX:/# ifconfig br1011 192.168.0.1 netmask 255.255.255.0
and ping your device
root@OPX:/# ping 192.168.0.2
PING 192.168.0.2 (192.168.0.2) 56(84) bytes of data.
64 bytes from 192.168.0.2: icmp_seq=1 ttl=128 time=0.490 ms
64 bytes from 192.168.0.2: icmp_seq=2 ttl=128 time=0.513 ms
64 bytes from 192.168.0.2: icmp_seq=3 ttl=128 time=0.518 ms
it's ok. you can check the result of an arp -a
command
root@OPX:/# arp -a
? (192.168.0.2) at 00:22:20:aa:bb:cc [ether] on br1011
all is fine, interfaces are configured with vlan 1011 (UNTAGGED) and ping is OK.
now, it's time to commit this "L2" configuration before a reboot.
root@OPX:/# cps_set_oid.py -oper set -db -qua target -commit-event dell-base-if-cmn/if/interfaces/interface switch-id=0
Success
Key: 1.19.44.2883617.2883612.2883613.
0 = 0
Now, reboot the switch and test the cps_get_oid
command
root@OPX:/# cps_get_oid.py -qua target dell-base-if-cmn/if/interfaces/interface if/interfaces/interface/type=ianaift:l2vlan
root@OPX:/#
nothing, all "L2" configuration is lost.
Regardless of the number and state of member ports, CPS doesn't report oper or admin status of LAG interfaces.
LAG interface with no member ports - should be oper-down even if enabled:
root@nst-wbx-demo-005:~# ip link show bnd1
40: bnd1: <NO-CARRIER,BROADCAST,MULTICAST,MASTER,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default
link/ether 00:01:02:03:04:05 brd ff:ff:ff:ff:ff:ff
root@nst-wbx-demo-005:~# cps_get_oid.py -qua observed dell-base-if-cmn/if/interfaces-state/interface | grep -B 4 -A 3 bnd1
------------------------------------------------
dell-if/if/interfaces-state/interface/supported-autoneg = 1
dell-if/if/interfaces/interface/phys-address = 00:01:02:03:04:05
if/interfaces-state/interface/if-index = 40
if/interfaces-state/interface/name = bnd1
dell-if/if/interfaces/interface/mtu = 1532
if/interfaces/interface/enabled = 1
------------------------------------------------
LAG interface with active member ports - should be oper up:
root@nst-wbx-demo-004:~# ip link show dev bnd1
40: bnd1: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default
link/ether 00:01:02:03:04:05 brd ff:ff:ff:ff:ff:ff
root@nst-wbx-demo-004:~# cps_get_oid.py -qua observed dell-base-if-cmn/if/interfaces-state/interface | grep -B 4 -A 3 bnd1
------------------------------------------------
dell-if/if/interfaces-state/interface/supported-autoneg = 1
dell-if/if/interfaces/interface/phys-address = 00:01:02:03:04:05
if/interfaces-state/interface/if-index = 40
if/interfaces-state/interface/name = bnd1
dell-if/if/interfaces/interface/mtu = 1532
if/interfaces/interface/enabled = 1
------------------------------------------------
On the OPX Virtual Machine, supported-speed
is not returned for interfaces.
How can I determine which values for speed can be used for interfaces on virtual machines?
Trace (hardware)
OPX 2.2.0-dev2 on Dell Z9100 - supported-speed is included:
root@OPX:~# sudo cps_get_oid.py dell-base-if-cmn/if/interfaces/interface | grep supported
dell-if/if/interfaces-state/interface/supported-speed = 4
...
dell-if/if/interfaces-state/interface/supported-speed = 3,4,5,6,10,7
dell-if/if/interfaces-state/interface/supported-speed = 3,4,5,6,10,7
root@OPX:~# sudo cps_get_oid.py dell-base-if-cmn/if/interfaces/interface | grep supported
dell-if/if/interfaces-state/interface/supported-speed = 4
...
dell-if/if/interfaces-state/interface/supported-speed = 3,4,5,6,10,7
dell-if/if/interfaces-state/interface/supported-speed = 3,4,5,6,10,7
Trace (VM)
On OPX 2.2.0-dev2 VM - no supported-speed:
opxUser@opx_vm:~$ sudo cps_get_oid.py dell-base-if-cmn/if/interfaces/interface | grep supported | wc -l
0
opxUser@opx_vm:~$ sudo cps_get_oid.py dell-base-if-cmn/if/interfaces/interface | grep supported | wc -l
0
On OPX 2.1.0 VM - no supported-speed:
opxUser@opx_vm:~$ sudo cps_get_oid.py dell-base-if-cmn/if/interfaces/interface | grep supported | wc -l
0
opxUser@opx_vm:~$ sudo cps_get_oid.py observed dell-base-if-cmn/if/interfaces-state/interface | grep supported | wc -l
0
if/interfaces/interface/description
is in ietf-interface.yang
and imported unchanged by the interfaces dell-base-if
model, but the description field doesn't appear to be stored or returned by CPS:
opxUser@opx_vm:~$ sudo cps_get_oid.py target dell-base-if-cmn/if/interfaces/interface if/interfaces/interface/name=e101-001-0
Key: 1.19.44.2883617.2883612.2883613.
base-if-phy/if/interfaces/interface/npu-id = 0
dell-base-if-cmn/if/interfaces/interface/if-index = 11
dell-if/if/interfaces/interface/phys-address = 08:00:27:ce:9a:c6
dell-if/if/interfaces/interface/speed = 6
base-if-phy/if/interfaces/interface/learn-mode = 3
if/interfaces/interface/name = e101-001-0
dell-if/if/interfaces/interface/duplex = 1
dell-if/if/interfaces/interface/auto-negotiation = 0
if/interfaces/interface/type = ianaift:ethernetCsmacd
dell-if/if/interfaces/interface/fec = 2
dell-if/if/interfaces/interface/oui = 6976381
base-if-phy/if/interfaces/interface/port-id = 25
dell-if/if/interfaces/interface/mtu = 1532
if/interfaces/interface/enabled = 1
base-if-phy/if/interfaces/interface/tagging-mode = 3
opxUser@opx_vm:~$ sudo cps_get_oid.py target dell-base-if-cmn/if/interfaces/interface/description if/interfaces/interface/name=e101-001-0
Traceback (most recent call last):
File "/usr/bin/cps_get_oid.py", line 41, in <module>
cur_obj = cps_object.CPSObject(qual=qual,module=e)
File "/usr/lib/opx/cps_object.py", line 73, in __init__
"Invalid Module Name or object doesn't have the key")
ValueError: Invalid Module Name or object doesn't have the key
If I query dell-base-if-cmn/if/interfaces/interface
, loopback interfaces are not reported.
Loopback interfaces are reported at dell-base-if-cmn/if/interfaces-state/interface
, though so far as I can see there's no way of identifying them as such. (Edit - now reported at #41)
Therefore to find loopback interfaces I have no better method than:
I'm using OPX 2.1
Of particular interest to us right now are
dell-base-if-cmn/if/interfaces-state/interface/type
(cf #40)dell-base-if-cmn/if/interfaces/interface/description
(less important but would be nice to have)CPS now pollutes results with data from portions of the tree other than the requested one.
Example:
A request for dell-base-if-cmn/if/interfaces/interface and if/interfaces/interface/name=e101-002-0
root@uml-switch:/exports/src/IN/pycnoporus/python3-inocybe-openswitch/inocybe_openswitch# cps_get_oid.py dell-base-if-cmn/if/interfaces/interface if/interfaces/interface/name=e101-002-0
============dell-base-if-cmn/if/interfaces/interface==========
The data contains dell-if/if/interfaces-state/interface/supported-speed = 3,4
It is not supposed to be there - it is in a different list in the model ietf interfaces model (brought in there by augmentations from dell-if).
I have a model containing an enum like this:
type enumeration {
enum foo { value 2038431744; }
}
But the parser doesn't like it:
Traceback (most recent call last):
File "/usr/lib/opx/py/yin_parser.py", line 34, in <module>
yf = yin_model.CPSYangModel(d)
File "/usr/lib/opx/py/yin_model.py", line 163, in __init__
_modules_[plugin].write()
File "/usr/lib/opx/py/cps_c_lang.py", line 235, in write
self.write_details('header')
File "/usr/lib/opx/py/cps_c_lang.py", line 243, in write_details
class_type.COutputFormat(self.context).show(self.model)
File "/usr/lib/opx/py/cps_h.py", line 338, in show
self.print_enums(model)
File "/usr/lib/opx/py/cps_h.py", line 108, in print_enums
self.show_enum(model,i)
File "/usr/lib/opx/py/cps_h.py", line 80, in show_enum
value = str(history.get_enum(en_name, value, parent=name))
File "/usr/lib/opx/py/object_history.py", line 217, in get_enum
res = self.the_dict[parent].get_value(name, requested)
File "/usr/lib/opx/py/object_history.py", line 46, in get_value
self.add_enum(name, ix)
File "/usr/lib/opx/py/object_history.py", line 32, in add_enum
raise Exception("Invalid id detected " + str(index))
Exception: Invalid id detected 2038431744
... per this line.
So far as I can see the large value is valid: RFC6020 9.6.4.2 says:
The "value" statement, which is optional, is used to associate an integer value with the assigned name for the enum. This integer value MUST be in the range -2147483648 to 2147483647 ...
Can the parser be persuaded to tolerate a wider range of values?
Configuring an ACL entry with a match rule of OUT_INTF does not seem to successfully match packets which exit the router on the specified interface.
Ping B->A in the following setup:
B -------------------> Router ---------------> A
e101-001-0 e101-001-2 e101-001-1 e101-001-0
10.10.14.3 10.10.14.2 10.10.12.2 10.10.12.3
With no ACLs, this works.
With the following config, which should drop egress packets on e101-001-1 on the Router, it still works.
Pinging in the other direction works too. However the tcpdump on the Router only shows packets traversing from B to A.
(Note, other than the ACL configuration below, nothing was changed after reboot
and the system-flow ACL has LOWER priority than the one we configured)
root@OPX:~# cps_get_oid.py base-acl/table
...
------------------------------------------------
base-acl/table/npu-id-list = 0
base-acl/table/id = 73
base-acl/table/stage = 1
base-acl/table/priority = 5
base-acl/table/allowed-match-fields = 5,6,39,40
base-acl/table/name = egress_tester
base-acl/table/size = 0
------------------------------------------------
root@OPX:~# cps_get_oid.py base-acl/entry
...
------------------------------------------------
base-acl/entry/table-name = egress_tester
base-acl/entry/action/PACKET_ACTION_VALUE = 1
base-acl/entry/action/type = 3
base-acl/entry/match/OUT_INTF_VALUE = e101-001-1
base-acl/entry/match/type = 40
base-acl/entry/npu-id-list = 0
base-acl/entry/table-id = 73
base-acl/entry/id = 1
base-acl/entry/priority = 393215
base-acl/entry/name = test
------------------------------------------------
TCPdump from A on e101-001-0 shows lots of these:
17:42:04.326713 IP 10.10.14.3 > 10.10.12.3: ICMP echo request, id 1021, seq 16, length 64
17:42:04.326745 IP 10.10.12.3 > 10.10.14.3: ICMP echo reply, id 1021, seq 16, length 64
Traceroute on A:
root@NST-OPX-TEST-012:~# traceroute 10.10.14.3
traceroute to 10.10.14.3 (10.10.14.3), 30 hops max, 60 byte packets
1 10.10.12.2 (10.10.12.2) 0.494 ms 0.536 ms 0.754 ms
2 10.10.14.3 (10.10.14.3) 0.841 ms 0.813 ms 0.897 ms
tcpdump -i any icmp
on Router on e101-001-1 shows lots of these:
01:45:34.656996 IP 10.10.14.3 > 10.10.12.3: ICMP echo request, id 1021, seq 13, length 64
but none going the other direction… 10.10.12.3 > 10.10.14.4
A:
root@NST-OPX-TEST-012:~# ip addr show e101-001-0
3: e101-001-0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:50:56:92:bb:18 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.1/31 brd 255.255.255.255 scope global e101-001-0
valid_lft forever preferred_lft forever
inet 10.10.12.3/24 scope global e101-001-0
valid_lft forever preferred_lft forever
inet6 fe80::250:56ff:fe92:46a3/64 scope link
valid_lft forever preferred_lft forever
root@NST-OPX-TEST-012:~# ip route
default via 172.17.0.1 dev eth0
10.10.12.0/24 dev e101-001-0 proto kernel scope link src 10.10.12.3
10.10.14.3 via 10.10.12.2 dev e101-001-0
172.17.0.0/18 dev eth0 proto kernel scope link src 172.17.32.11
192.168.0.0/31 dev e101-001-0 proto kernel scope link src 192.168.0.1
Router:
root@OPX:~# ip addr
...
38: e101-001-1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 34:17:eb:2c:d7:01 brd ff:ff:ff:ff:ff:ff
inet 10.10.12.2/24 scope global e101-001-1
valid_lft forever preferred_lft forever
inet6 fdd9:edd5:139c:e7d3::2/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::3617:ebff:fe2c:d701/64 scope link
valid_lft forever preferred_lft forever
39: e101-001-2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 34:17:eb:2c:d7:02 brd ff:ff:ff:ff:ff:ff
inet 10.10.14.2/24 scope global e101-001-2
valid_lft forever preferred_lft forever
inet6 fdd9:edd5:139c:e7d4::2/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::3617:ebff:fe2c:d702/64 scope link
valid_lft forever preferred_lft forever
...
B:
root@NST-OPX-TEST-014:~# ip addr show e101-001-0
3: e101-001-0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:50:56:92:b6:d8 brd ff:ff:ff:ff:ff:ff
inet 10.10.14.3/24 scope global e101-001-0
valid_lft forever preferred_lft forever
inet6 fe80::250:56ff:fe92:b6d8/64 scope link
valid_lft forever preferred_lft forever
root@NST-OPX-TEST-014:~# ip route
default via 172.17.0.1 dev eth0
10.10.12.3 via 10.10.14.2 dev e101-001-0
10.10.14.0/24 dev e101-001-0 proto kernel scope link src 10.10.14.3
172.17.0.0/18 dev eth0 proto kernel scope link src 172.17.32.13
In CPS you expose 3 options for interface duplex mode:
Configuration works as expected for Full and Half, but not for Auto.
Setting duplex = Auto actually results in duplex = Full.
Trace:
# Before
opxUser@opx_vm:~$ sudo cps_get_oid.py dell-base-if-cmn/if/interfaces/interface if/interfaces/interface/name=e101-021-0 | grep duplex
dell-if/if/interfaces/interface/duplex = 2 # "Half"
# Successfully set to Auto - even returns changed value!
opxUser@opx_vm:~$ sudo cps_set_oid.py -qua target -oper action dell-base-if-cmn/set-interface dell-base-if-cmn/set-interface/input/operation=3 if/interfaces/interface/name=e101-021-0 dell-if/if/interfaces/interface/duplex=3
Success
Key: 1.19.1245192.
dell-if/if/interfaces/interface/duplex = 3 # "Auto"
dell-base-if-cmn/set-interface/input/operation = 3
if/interfaces/interface/name = e101-021-0
cps/object-group/return-code = 0
# After - duplex = full (1) not auto (3)
opxUser@opx_vm:~$ sudo cps_get_oid.py dell-base-if-cmn/if/interfaces/interface if/interfaces/interface/name=e101-021-0 | grep duplex
dell-if/if/interfaces/interface/duplex = 1 # "Full"
Cause:
See https://github.com/open-switch/opx-nas-ndi/blob/master/src/nas_ndi_port.c#L1016
Basically, NAS does not honour the Auto option. It always sets duplex = Full instead of Auto.
This means after setting duplex to Auto, subsequent queries still return Full, causing the inconsistency described above.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.