Passive Device Management and Handling (Wired)

passive device (wired) nile's default architecture is built for security it is based on layer 3 and that means we limit the use of broadcast flooding, which is traditionally used to poll for connected wired devices nile switches discover a device on a port based on dhcp packets seen from it once plugged in if a device performs dhcp ip, it is not considered 'passive' since nile is able to learn the device and keep it alive as long as it is connected the definition of 'passive' in nile's architecture is a 'statically ip addressed device' that does not initiate any traffic or dhcp packet upon first connection and remains silent unless solicited by another device or application ⚠️ the assumption is, the passive device is typically using a static ip address passive device management and handling (wired) nile provides tools to not only handle passive wired devices but also to manage them through a centralized access management system these tools also support the discovery of devices that may remain silent during day 1 migration to nile and on an ongoing basis from day 2 forward key features discovery for day 1 migration to nile day 1 migration is simplified through the discovery feature administrators must know the static ip or subnet used by the passive device with a single click on discover , all passive devices in that subnet or ip range are presented for approval ease of management all passive devices are clearly flagged as passive this helps bring order to previously unorganized networks, where it teams may have lost track of devices with static ip addresses after discovery, a list of mac addresses is presented for administrators to approve in bulk the discovery process intelligently excludes devices already using dhcp ip addresses day 2 keep alive nile switches send keepalive probes to devices identified as passive, reducing reliance on broadcast based learning per device discover and wake up if a device appears offline, even though it is still connected, administrators can navigate to the device details page in the nile control center a discover or wake up option is available to recheck and reactivate the device day 1 migration to nile – adding a passive device log in to the nile control center (nile portal) navigate to network setup > access management select add device choose static ip this activates the passive option passive requires static ip to be selected, since passive devices are assumed to use static ip addresses provide the following mac address segment geographical scope ip address (mandatory for passive devices) note organizationally unique identifier (oui) is not supported the full mac address must be provided optionally, use bulk upload to import a csv list of mac addresses to be marked as static ip and passive day 1 migration to nile – auto discovery log in to the nile control center navigate to network setup > access management select the passive device discovery icon in the drawer that opens, specify an ip address, an ip range, or a subnet up to /24 that passive devices are using within the defined geographical scope select scan the nsb initiates auto discovery on switches in that scope and presents a list of mac addresses for review approve the discovered devices once approved, they are automatically marked as static ip and passive if the ip range provided does not match any subnet mapped to configured segments, the discovery tool will generate an error ensure the range matches one of the existing segments the ip addresses for passive devices are populated in the mab (mac authentication bypass) list once they are fully learned by nile switches discovery process day 2 per device discovery tool at times, passive devices may appear offline even though they remain physically connected in this case go to devices in the nile control center select the offline wired device open the device details page use the discover option this triggers a one time auto discovery on the specific switch and port where the device was last connected, using its last known ip address day 2 discovery tool background process feature constraints the nile service block software must be upgraded to a supported version contact customer support to schedule the upgrade only subnets up to /24 in size (a maximum of 254 ip addresses) can be used for initial discovery at one time