"Unable to reach device" error
Article ID: 273601
Updated On:
Products
Issue/Introduction
Customer is moving from a VMware based Management Center to run Management Center as an application on ISG platform.
Migrated most proxies, CAS etc. with no problems.
All ISG running on different hardware can be connected to ISG MC with no problems.
But when connecting to the ISG that run on the same ISG as the MC the "Unable to reach device" error is received.
Also, pings to the local ISG, from the MC and all other "external" ISGs work.
Resolution
About Inter-Application Networking on ISG, please refer to the below.
Applications deployed on ISG can inter-network only in the following configurations:
Note:
These configurations apply to applications of the same type (such as multiple ProxySG applications) and differing types (such as ProxySG and Content Analysis applications).
- Applications running on the same ISG host that are sharing the same physical interface
- Applications running on the same ISG host that are not sharing the same physical interface
- Applications running on different ISG hosts
- Applications running on two or more physical NICs that are bonded by LACP
Same Host and Same Physical Interface:
For applications running on the same ISG host that are sharing the same physical interface, note that:
- A link on the physical interface is required, even if traffic is not exiting the physical interface. A link can be achieved by plugging in a network cable from the interface to a networking switch or other piece of networking equipment.
- Network packets between the applications never leave the appliance.
Same Host and Different Physical Interface
For applications running on the same ISG host that are not sharing the same physical interface, note that upstream network components (such as with a switch) routes or forwards network packets.
Different Hosts
For applications running on different ISG hosts, note that upstream network components (such as with a switch) routes or forwards network packets.
Physical NICs that are bonded by LACP
For applications in a LAG configuration, note that:
- All applications in the LAG or that are to be added to it must be in a Stopped or Created state before changing the configuration.
- Physical interfaces that are part of the LAG are presented to the application as not available (down).
- The command (config)# lag exists to manage LACP deployments.
- The maximum number of LAGs allowed is 8.
In the following diagram, the physical interfaces 2:2 and 2:3 form the LAG 0. LAG 0 is presented to applications as interface 9:0 and interfaces 2:2 and 2:3 are presented as down to applications and should not be configured by applications.
About Configuring LAGs
The system first boots with 8 placeholders for LAGs. When you add the first interface to a LAG, the LAG is created and you can add or remove interfaces to the LAG one at a time. You can also remove all interfaces at once. If you remove the last interface from the LAG, the LAG is deleted.
The LAG is presented to the application as interface 9:X, where X can be a value of 0–7 and represents the LAG group. For example, if you assign interfaces to LAG group 2, the aggregated interface for that group is 9:2.
Note:
When deploying ProxySG applications with versions of SGOS prior to 6.7.5.10 (in the 6.7.x stream) or 7.2.6.1 (in the 7.2.x stream) or 7.3.2.1 (in the 7.3.x stream), the ICW will not show the LAG interface. You must configure an interface in the ICW and later configure an interface to be associated with the LAG. For those versions of SGOS, the show interface all command does not show the 9:X interface. You will have to configure the interface 9:X explicitly using that interface name. For example, if you want to present 9:4 to the applications, you will have to explicitly configure 9:4 for LAG ID 4.
Ref. docs.:
Feedback
