The CAN-BUS controller is configured by adding a few overlay lines to /boot/config.txt and then configuring the network interfaces file

Here are the two sections that need adding

/boot/config.txt

dtparam=spi=on
dtoverlay=spi0-hw-cs
dtoverlay=mcp2515-can1,oscillator=16000000,interrupt=26
dtoverlay=mcp2515-can0,oscillator=16000000,interrupt=25

Note : Please add these lines in the order shown, there's conjecture that the order impacts the OS configuration

/etc/network/interfaces

############### CAN BUS CONFIG ###########################
auto can0
iface can0 inet manual
    pre-up ip link set $IFACE type can bitrate 500000 listen-only off
    up /sbin/ifconfig $IFACE up
    down /sbin/ifconfig $IFACE down

auto can1
iface can1 inet manual
    pre-up ip link set $IFACE type can bitrate 500000 listen-only off
    up /sbin/ifconfig $IFACE up
    down /sbin/ifconfig $IFACE down
############### CAN BUS CONFIG ###########################

The above could also be placed in /etc/network/interfaces.d/can

With these changes in place reboot the unit and check the config as below

The CAN-DUO card features a hardware modification which forces all interrupts to be synchronous rather than asynchronous as a work-around for a bug in the MCP2515 kernel driver (Raspbian Kernel 4.9.41 or earlier) which presents when 2 or more controllers are active and using edge triggered interrupts (rather than level triggered) this often results in one of the channels hanging after a short period due to the edge being missed and ends up being left in limbo. This hardware fix has been tested over long periods under high load without problem and provides a neat hardware work-around to save any modification to the OS.  This bug has been fixed as of Raspbian Kernel version 4.9.75+ and if required an alternative build of the card is availble without this hardware work-around modification (this uses R1/R2 0R0 links instead of U10).

See below example showing the sytem running in a throughput test using cangen :