On 01/21/2019 10:19 PM, Ali Dormiani via USRP-users wrote:
So each port on the server/host must be on a different subnet?

192.168.1...
192.168.2...

and so on?

Also when you define NIC do you mean each individual port or the chip/card itself?

In other words, is our Intel x520-DA2 (card with 2-SFP+ ports) one NIC or two?

Thanks for the fast responses everyone.
For the purposes of IP addressing, it's two.









On Mon, Jan 21, 2019 at 4:08 PM Marcus D. Leech via USRP-users <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> wrote:

    On 01/21/2019 05:39 PM, Ali Dormiani via USRP-users wrote:
    * sorry typo

    Each of my N310's SFP+0 ports is configured as follows:

    MTU: 8000

    Address: 192.168.20.5x/24

    On Mon, Jan 21, 2019 at 2:37 PM Ali Dormiani
    <sdorm...@eng.ucsd.edu <mailto:sdorm...@eng.ucsd.edu>> wrote:

        Hello everyone,

        I am having a strange (new) problem where my host machine can
        not detect more than one USRP at a time. I recently
        re-installed everything to update all devices to 3.13.1.0.

        Each of my N310's SFP+0 ports is configured as follows:

        MTU: 8000

        Address: 192.168.5x/24

        Where x is the device number I have assigned (1-9).

        What is bizarre is if two N310's are connected to the host,
        only one shows up in uhd_find_devices.

        Each N310 connects fine on its own. Just plug and play. But
        attaching more than one to the server breaks things.

        The server is manually configured with a different static ip
        for each SFP+ port:

        192.168.20.2y

        Where y is the port number (0-6).

        Everything (SD file system, host install, FPGA, ixgbe driver)
        is up to date. I can do whatever I want if only one device is
        attached (SSH, UHD commands, GNU radio, device_probe).


        I'm not sure what to do about this as individually all of
        them work perfectly. Any ideas?

        Thank you for your time,

        Ali


    Having two NICs on your server living on the same subnet
    (192.168.20) is likely to not work because that's not how the IP
    routing machinery works in
      most host operating systems--the routing machinery will use the
    first port it finds that "matches" the desired destination address
    subnet.



    _______________________________________________
    USRP-users mailing list
    USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
    http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com



_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Reply via email to