open-switch / opx-cps

opx-cps

This repository contains the CPS object library files, and provides a microservice data-centric API allowing applications to communicate with each other between threads, processes, or diverse locations.

• Data model is described through YANG or other constructs
• Applications can use CPS objects with Python, C, C++, and REST services in the opx-cps-REST service
• Applications/threads will register for ownership of CPS objects, while other applications/threads will operate and receive events of the registered CPS objects; applications can also publish objects through the event service

A high-level list of CPS features include:

• Distributed framework for application interaction
• Database-like API (Get, Commit[add,delete,create,modify])
• Publish/subscribe semantics supported

Lookup and binary to text translation and object introspection is also available.

Applications define objects through (optionally YANG-based) object models. These object models are converted into binary (C accessible) object keys and object attributes that can be used in conjunction with the C-based CPS APIs. There are adaptions on top of CPS that allow these objects and APIs to be converted to different languages like Python.

With the object keys and attributes applications can:

• Get a single or get multiple objects
• Perform transactions
  • Create
  • Delete
  • Set
  • Action
• Register and publish object messages

API documentation

The CPS API is documented through Doxygen. To generate CPS Doxygen content, at the top level of your source directory (one level underneath opx-cps), run the opx-cps/doc/cps_gen_doc.sh command.

git clone [email protected]:open-switch/opx-cps.git
cd opx-cps
(cd .. ; sh -x opx-cps/doc/cps_gen_doc.sh )
firefox workspace/cps-api-doc/c-cpp-doc/html/index.html

Packages

• libopx-cps1\_*version*\_*arch*.deb — Utility libraries

• libopx-cps-dev\_*version*\_*arch*.deb — Exported header files

• python-opx-cps\_*version*\_*arch*.deb — Python bindings

• opx-cps\_*version*\_*arch*.deb — Service executables, configuration files, tool scripts

• opx-yang-utils-dev\_*version*\_*arch*.deb — Tools to parse YANG files

See Architecture for more information on the CPS module.

Debugging tools

• cps\_model\_info

• cps\_get\_oid

• cps\_set\_oid

• cps\_trace\_events

• cps\_send\_events

cps_model_info

This tool is useful to get all information about CPS objects on the target. It is used to get the attributes of a specific CPS object, or first-level contents of a given YANG path of the CPS object (as defined in the YANG model).

Usage

cps\_model\_info CPS Object Path as defined in the YANG model

Examples

root@OPX:~# cps_model_info

base-packet
base-pas
base-acl
if
base-qos
base-if-phy

root@OPX:~# cps_model_info base-if-phy

base-if-phy/front-panel-port
        Attribute Type =  list
        Description =  This map contains the front panel ports and the NPU ports associated with with the front panel ports.

Registered to CPS with qualifier:  target

Process Owner:  base_nas_front_panel_ports.py

base-if-phy/hardware-port
        Attribute Type =  list
        Description =  This entity holds the details of which front panel port corresponds to a specific NPU/hardware port. This list is not dynamic and therefore will not change for a single instance of a product.

Registered to CPS with qualifier:  target

Process Owner:  base_nas_front_panel_ports.py

root@OPX:~# cps_model_info base-if-phy/physical

base-if-phy/physical/phy-mode
        Attribute Type =  leaf
        Data Type =  enum
        Description =  Port PHY mode, Ethernet or FC

Registered to CPS with qualifier:  target

Process Owner:  base_nas


base-if-phy/physical/hardware-port-id
        Attribute Type =  leaf
        Data Type =  uint32_t
        Description =  This is the physical hardware port

Registered to CPS with qualifier:  target

Process Owner:  base_nas

cps_get_oid.py

This tool is used to get data from a CPS Object Service provider.

Usage

cps\_get\_oid.py qualifier CPS Object Path as defined in the YANG model

CPS Object Path can be determined from the cps\_model\_info tool.

Qualifier: target/observed/proposed

Examples

root@OPX:~# cps_get_oid.py target base-if-phy/physical hardware-port-id=125

Key: 1.17.1114163.1114115.1114116.
base-if-phy/physical/breakout-capabilities = 4,2,4
base-if-phy/physical/fanout-mode = 4
base-if-phy/physical/npu-id = 0
base-if-phy/physical/hardware-port-list = 125,126,127,128
base-if-phy/physical/hardware-port-id = 125
base-if-phy/physical/speed = 6
base-if-phy/physical/supported-speed = 3,4,6
base-if-phy/physical/port-id = 125
base-if-phy/physical/phy-media = 1
base-if-phy/physical/front-panel-number = 25
base-if-phy/physical/loopback = 0
root@OPX:~#

cps_set_oid.py

This tool is used to do transactions on a given CPS object.

Usage

cps\_set\_oid.py qualifier operation CPS Object Path as defined in the YANG model CPS Object attr=value

CPS Object Path and its attributes can be determined from the cps\_model\_info tool.

Qualifier: target/observed/proposed

Operation: create/set/delete

Examples

root@OPX:/usr/bin# cps_set_oid.py target create base-if-phy/physical hardware-port-id=26 admin-state=2

cps_trace_events.py

This tool is used to subscribe/listen for CPS events on the target.

Usage

cps\_trace\_events.py qualifier CPS Object Path as defined in the YANG model

CPS Object Path can be determined from the cps\_model\_info tool.

Examples

root@OPX:~# cps_trace_events.py observed dell-base-if-cmn/if/interfaces-state/interface
Key : 2.19.44.2883618.2883611.2883586.
 Registering for observed dell-base-if-cmn/if/interfaces-state/interface
1.2.131094.131075.
Key: 1.2.131094.131075.
cps/connection-entry/ip = 127.0.0.1:6379
cps/connection-entry/connection-state = 1
cps/connection-entry/group = 127.0.0.1:6379


2.19.44.2883618.2883611.2883586.
Key: 2.19.44.2883618.2883611.2883586.
if/interfaces-state/interface/name = e101-025-0
if/interfaces-state/interface/if-index = 41
if/interfaces-state/interface/admin-status = 2

cps_send_event.py

This tool is used to publish/send CPS events on the target.

Usage

cps\_send\_event.py operation qualifier CPS Object Path as defined in the YANG model CPS Object attr=value

CPS Object Path and its attributes can be determined from the cps\_model\_info tool.

Qualifier: target/observed/proposed

Operation: create/set/delete

Examples

root@OPX:/usr/bin# cps_send_event.py create observed  dell-base-if-cmn/if/interfaces-state/interface  if/interfaces-state/interface/name=e101-007-0 if/interfaces-state/interface/oper-status=2

© 2018 OpenSwitch project. All information is contributed to and made available by OPX under the Creative Commons Attribution 4.0 International License (available at http://creativecommons.org/licenses/by/4.0/).

opx-cps's Issues

Incompatible ENUM and boolean representations

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.

CPS does not report interface type for VLAN interfaces

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

CPS doesn't store interface description

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

Can't attach ACL to VLAN interface

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?

base-ip/ipv4/enabled missing from query and does not work

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.

Reproduce

• Start with an oper-up interface with IPv4 and IPv6 addresses

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

• Disable IPv6, and the IPv6 addresses are removed (as expected)

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

• Disable IPv4, and the transaction succeeds, but nothing changes - it still has IPv4 addresses

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

• Query IPv6 configuration - base-ip/ipv6/enabled is present

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
------------------------------------------------

• Query IPv4 configuration - base-ip/ipv4/enabled is not present

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
------------------------------------------------

configuration of base-ip/ipv4 is flakey at best

If I attempt to set configuration at base-ip/ipv4 then:

• the transaction always appears to fail
• sometimes the change I'm making sticks anyway

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!

Configuring an interface's duplex mode to "Auto" actually sets it to "Full".

In CPS you expose 3 options for interface duplex mode:

• Full
• Half
• Auto

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.

Support for VLAN Sub-interface

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)

L3ipvlan support

Are L3ipvlan type interfaces currently supported?

I have been unable to create interfaces of this type:

• I modified the vlan configuration script in the opx-nas-interface repository (https://github.com/open-switch/opx-nas-interface/blob/master/scripts/bin/cps_config_vlan.py) to use l3ipvlan type interfaces instead of l2vlan.
• This caused the transaction to fail and no interface to come up.
• I can create l2vlan type interfaces as expected

Note, I'm currently using v2.1

when querying interface state by name, only ethernet-csmacd interfaces are returned

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
# 

No 'reject' packet action on ACL action fields

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?

upgrade failing - packages fighting over /usr/lib/x86_64-linux-gnu/libsai-0.9.6.so.1.0.0

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.

Interface state is reported in duplicate

When I query dell-base-if-cmn/if/interfaces-state/interface, I see all interfaces reported twice.

Setting VLAN interface admin state via Netlink does not propagate to CPS

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.

Reproduction

• Create a VLAN interface. It's admin-down when it's created

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

• CPS shows 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

• Bring it up using ip link. CPS still shows enabled = 0. This is wrong

opxUser@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    <--------

• Bring it down again, and instead bring it up using CPS

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

• This time CPS shows the correct value

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

• Finally, bring it down using ip link. Once again, CPS does not update the target configuration

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_get_oid.py dell-base-if-cmn/if/interfaces/interface if/interfaces/interface/name=br11 | grep enabled
if/interfaces/interface/enabled = 1      <-------------

Can't delete loopback interface

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

I imagine that this is related to #40 and #43?

Tree structure generated by CPS does not match the model

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.

Can only delete and create an interface once - opx-nas service crashes and does not restart

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.

Can't perform "set" operation on ACL object

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.

Insufficient information reported by cps.type()

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.

Oper status not reported on LAG interfaces

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
------------------------------------------------

Creating LAG interface without a number in its name causes opx_nas_daemon to crash

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:

• opx_nas_daemon should not crash because of a bad interface name
• If a number is required at the end of the interface name, this should be documented somewhere (probably the YANG model)

Reproduction

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

Diags

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

supported-speed not present for interfaces on OPX VM

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

Server (untagged) unable to ping SVI gateway hosted of ToR

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

Not able to remove registration added with cps_api_event_thread_reg

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.

yang parser generates conflicting typedefs

The model below results in a header file with conflicting definitions for EXAMPLE_FOO_t:

• a typedef corresponding to the input typedef
• an enum corresponding to the list definition

(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;
                  ^

Query interface configuration by type broken

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:

• opx-nas-linux (5.11.0+opx3 -> 5.11.0+opx4)
• opx-nas-acl (2.4.0_opx2 -> 2.4.0+opx3)
• libopx-nas-acl1 (2.4.0_opx2 -> 2.4.0+opx3)
• libopx-sai-bcm-esw1 (21.1.0+opx2 -> 21.1.0+opx4)
• opx-bcm-lkm (2.1.0 -> 2.1.2)
• libopx-nas-interface1 (5.10.1+opx8 -> 5.10.1+opx11)
• opx-nas-common (6.1.0+opx2 -> 6.1.0+opx3)
• libopx-nas-linux1 (5.11.0+opx3 -> 5.11.0+opx4)
• opx-platform-config-dell-s6000 (1.4.1 -> 1.4.2)
• opx-dell-s6000 (1.4.1 -> 1.4.2)
• opx-nas-interface (5.10.1+opx8 -> 5.10.1+opx11)
• libopx-nas-common1 (6.1.0+opx2 -> 6.1.0+opx3)

ACL match on OUT_INTF fails.

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.

Test setup:

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.

Configuration:

(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
------------------------------------------------

Trace:

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

IP addr and route configuration:

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

Loopback interface configuration is not reported

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:

• query both of the above
• look for interfaces that are in state but not configuration
• guess that those are loopback interfaces
• hope for the best

I'm using OPX 2.1

Gaps in Yang tree

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).

Cannot add LAG interface to VLAN interface as tagged port

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.

Repro

Summary

• Create a LAG interface bnd1
• Create a VLAN interface br10
• Add bnd1 to br10 as an tagged-port. This fails
• Doing the same thing, but adding bnd1 as an untagged-port succeeds.

Trace

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.'}}]

trace changes

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)

Problem with ACL names

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.

CPS gets into a state where IP addresses cannot be configured

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!

configured speed only shown when interface is oper-up

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:

• What is the intended use of the dell-if/if/interfaces/interface/speed field?
• If I set this field to a value (seting the desired speed of the interface), how can I reliably view that configuration?

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

Result pollution in latest CPS

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==========

base-if-phy/if/interfaces/interface/npu-id = 0
dell-base-if-cmn/if/interfaces/interface/if-index = 4
dell-if/if/interfaces/interface/phys-address = 90:b1:1c:f4:ef:a1
dell-if/if/interfaces/interface/speed = 0
if/interfaces/interface/enabled = 0
base-if-phy/if/interfaces/interface/learn-mode = 3
if/interfaces/interface/name = e101-002-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/tx-idle-time = 23040
dell-if/if/interfaces/interface/oui = 6976381
dell-if/if/interfaces/interface/tx-wake-time = 23040
dell-if/if/interfaces/interface/mode = 1
base-if-phy/if/interfaces/interface/port-id = 2
dell-if/if/interfaces-state/interface/supported-speed = 3,4
dell-if/if/interfaces/interface/mtu = 1532
base-if-phy/if/interfaces/interface/phy-media = 2
dell-if/if/interfaces/interface/fec = 2
base-if-phy/if/interfaces/interface/tagging-mode = 3
dell-if/if/interfaces/interface/eee = 0

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).

parser barfs on enums with large values

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?

Intended use of negotiation/auto-negotiation

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:

• Setting negotiation = on causes auto-negotiation = 1
• Setting negotiation = auto or off causes auto-negotiation = 0
• The information in 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

Need to provide a bogus interface type when retrieving interface statistics

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:

• The API should not require an interface type at all when getting statistics. (The name identifies the interface: surely CPS knows the interface type?)
• if the interface type really must be provided, then the correct type to provide should be the actual type of the interface

can't save L2 configuration with cps_set_oid.py

cps_set_oid.py does not save L2 configuration.

my setup

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

Reproduce

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.

yang parser fails to disambiguate nodes

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.

'Key Error: 0' in cps_utils.printable()

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.

Compatibility issues in using prefix instead of module name

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.

Object registration in python succeeds, but handlers are never invoked

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)

1. cps.obj_register returns True which according to the code in the cps api means registration is OK
2. Neither the bound methods (in the object) or the simple function test_get are invoked for any transactions coming via CPS.
3. CPS returns transaction successful for transactions targeted at dhcp-agent/if/interfaces/interface (f.e. set). The method is not invoked and the data is lost along the way
4. Prior to registering an handler obj_stats() returns None. After registering an object it reports the same information for any path so the available debug info is not particularly informative.

opx-config-switch show command is failing.

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"

CPS does not report all fields from YANG models

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)

Can't configure LAG blocked/unblocked ports at once

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   <-------

VLAN interface state oper-status and admin-status always "down"

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

Content of vlan interfaces state

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?

Packet with TTL=1 is not handled properly in S4248FB-ON

In S4248FB-ON the packet with TTL=1 is not lifted to CPU for proper handling.

Setting physical address on LAG interface doesn't always stick

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

yang parser fails if model augments its own nodes

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')

• If 'yes' then I'll attach it.
• Else, if you need me to create a sample file that reproduces this, then please say so.