Categories
Knowledge Support Support exacqVision Server Categories

How multiple adapters on the same network are expected to behave

Summary

If you configure a Windows-based computer that has more than one network adapter on the same physical network and protocol subnet, you may experience unexpected results. This article describes the expected behavior of this kind of nonstandard configuration. 

More Information

Consider the following scenario:

  • You have a working computer that has Windows installed.
  • Two network adapters are connected to the same physical network or hub.
  • TCP/IP is installed as the network protocol.
  • The adapter addresses on the same subnet are 192.168.0.1 and 192.168.0.2.
  • A client on the network uses the address 192.168.0.119.

In this scenario, you may expect the two adapters on the same physical network and protocol subnet to perform load balancing. However, by definition, only one adapter may communicate on the network at a time in the Ethernet network topology. Therefore, both adapters cannot be transmitting at the same time and must wait if another device on the network is transmitting. Additionally, broadcast messages must be handled by each adapter because both are listening on the same network. This configuration requires significant overhead, excluding any protocol-related issues. This configuration does not offer a good method for providing a redundant network adapter for the same network. 

Note Windows Server 2012 includes a new feature call SMB Multichannel. SMB Multichannel is part of the SMB 3.0 protocol and lets servers use multiple network connections at the same time. For more information about SMB Multichannel, visit The basics of SMB Multichannel, a feature of Windows Server 2012 and SMB 3.0.

Note Windows Server 2012 servers cannot use multiple network connections at the same time if the network is configured by using CSMA/CD.

Assume that the server has to send a packet by using the TCP/IP protocol to a client whose address is 192.168.0.119. This address is located on the local subnet. Therefore, a gateway does not have to be used to reach the client. The protocol stack uses the first route that it finds in the local routing table. Typically, this is the first adapter that was installed. In this case, that adapter is 192.168.0.1. If the transmission fails, later retries may use the same adapter according to the entry that is found in the routing table. 

If the network cable for the 192.168.0.1 adapter fails, this does not necessarily cause the route to be removed from the routing table. Therefore, the second adapter still may not be used. 

Another thing to consider is that some network applications bind to specific adapters in the system. If a network application were to bind to the second adapter specifically, application-related traffic that was received from clients on the first adapter might be ignored by the application. This might be caused by NetBIOS name registration on the network. Additionally, if the adapter to which the application is bound fails, the application may fail if it does not use the other adapter.  

Usually, unless applications specifically demand it, this kind of configuration is not helpful. Some manufacturers make fault-tolerant network adapters to guard against a single point of failure. These adapters enable two adapters to be included on the same server but enable only one adapter to be used at a time. If the primary adapter fails, the driver deactivates the first card and enables the second by using the same address configuration. The result is a fairly seamless transition to the alternative adapter. This is the preferred method to guard against a single network adapter as a single point of failure.

Microsoft article link

https://support.microsoft.com/en-us/topic/how-multiple-adapters-on-the-same-network-are-expected-to-behave-e21cb201-2ae1-462a-1f47-1f2307a4d47a

Categories
Knowledge Support Support Categories Products exacqVision Integrations

iSCSI CONSIDERATIONS WITH LINUX RECORDERS

iSCSI CONSIDERATIONS WITH LINUX RECORDERS

Also Note:

https://crm.exacq.com/kb/?crc=42338 == recovering corrupt iSCSI configuration in Linux (open-iscsi issue). This can also solve the occasionally-observed problem of deleting a portal, restarting service, and observing the portal was not actually deleted after all.

Alternatively, you can also:

sudo services edvrserver stop
sudo apt-get purge open-iscsi
sudo apt-get install open-iscsi
sudo services edvrserver start

exacqVision Linux-based recorders since Ubuntu version 8.04 support using extended storage with S-Series. However, please do note the following:

Ubuntu 8.04


iSCSI tools may not already be installed. You may need to install the open-iscsi package, then restart the edvrserver service.
* Only the ext3 filesystem type is supported. This means that you cannot format or mount a partition larger than 2TB. You must take care when configuring your S-Series, to specify sufficient number of partitions, such that each one is within the 2TB size limit. For a large installation, this can require that your recorder be configured to connect to a larger number of iSCSI targets, which you may find inconvenient.

* Formatting takes significantly longer with ext3. A 1 TB partition can take approximately 15 minutes to prepare, and a 2 TB partition is expected to take much longer. Granted, this only matters when configuring a target the first time, but if you don’t expect this slow performance, it can falsely imply a problem.
* Systems have been observed to attempt formatting and mounting targets larger than 2 TB, even though these cannot work. In such a situation, the client will indicate “bad mount”, with logs resembling:

TM=14:48:48;LV=25;PI=390000;TX=/usr/local/exacq/server/scripts/iscsiprep.py addportal -portaladdr 10.16.1.106 -portalport 3260

TM=14:48:52;LV=25;PI=390000;TX=Updated iSCSI target (iqn.exacqstorage:disk1.vol6.68-05-ca-1e-0f-fc) for portal (10.16.1.106:3260) in configuration.

TM=14:48:59;LV=25;PI=390000;TX=/usr/local/exacq/server/scripts/iscsiprep.py enabletarget -iqn iqn.exacqstorage:disk1.vol6.68-05-ca-1e-0f-fc -portaladdr 10.16.1.106 -portalport 3260

TM=14:48:59;LV=25;PI=390000;TX=No prep to be done for LUN 1 for iqn.exacqstorage:disk1.vol6.68-05-ca-1e-0f-fc (diskindex 0, diskname /dev/sdb)

TM=14:48:59;LV=25;PI=390000;TX=Configuring UUID (UUID=a1db15d4-3679-42b3-9f34-4c72c049d0c3) – created mount point (/mnt/edvr/1).

TM=14:48:59;LV=50;PI=390000;TX=iSCSI target (iqn.exacqstorage:disk1.vol6.68-05-ca-1e-0f-fc) partition (1:1) mount point (/mnt/edvr/1/) – mount error 8192.

TM=14:48:59;LV=25;PI=50000;TX=Drive /mnt/edvr/1/ (ID 1) discovered via iSCSI.

If you were to execute dmesg | tail you might also see a message resembling EXT3-fs: sdb1: couldn’t mount because of unsupported optional features (240).
Your best solution here is to remove the portal from your recorder, go back and reconfigure your number of S-Series partitions, reprovision one for this recorder, then add the same portal again.

Ubuntu 10.04

* iSCSI tools may not already be installed. You may need to install both the open-iscsi and open-iscsi-utils packages, then restart the edvrserver service.
* Because the ext4 filesystem type is supported in Ubuntu 10.04, target preparation will complete much more quickly.
* With the ext4 filesystem type, you may connect to partitions up to 16 TB in size. This will help to reduce the total number of partitions necessary for a large installation.

Ubuntu 12.04 and newer, 32-bit

* All necessary iSCSI tools should be pre-installed.
* Otherwise, experience will mimic Ubuntu 10.04.

Ubuntu 12.04 and newer, 64-bit

* If your S-Series is using a 64-bit operating system, it will allow you to specify fewer partitions, because 64-bit Ubuntu can support partitions much larger than 16 TB.
* If you attempt to connect a 32-bit recorder, it is expected to subpartition the target in order than all partitions are within a 16 TB size limit.
* If you attempt to connect a 64-bit recorder, it is expected to connect to the single, large partition as-is.

Categories
Knowledge Support Support Categories Products exacqVision Integrations

Illustra discovery for Pro and Essentials issues with dual nic as well as Una systems

Inconsistent results. Web interface not showing all details, firmware, model, etc. Doesn’t always find Pro cameras even though static IP addressed. Also found 610LT’s twice and added them twice.

Workaround suggested

For Dual nic systems:
For dual nic systems with duplicated results, either disable one of the nic’s or make sure that they are not set to the same subnet.

For Una:
With UNA the camera HAS to be factory defaulted to be discover-able (this is a requirement for UNA to work). Either that or the camera has to be set to dhcp with dhcp support on the una ports. If the camera is set to static and is on a different subnet we may not be able to discover it.