packet delivery after link down event

[EdProulx29132]

How is packet delivery to devices on a port affected by a momentary link down event? Must device re-discovery be initiated all over? Or is packet routing unaffected if the link down event was momentary?

[Richard Burts]

I am not clear what this question is really trying to ask. And not clear what kind of device discovery is involved. Is it simply arp obtaining the mac address of the device? Or is it something more complex? But in either case if the port/interface has registered a link down event then I would expect that any information that Cisco would have about that device would have been discarded and when there is link up event that it would need to discover whatever information is associated with that device. 

[EdProulx29132]

I did not want to go through a massive description of my application, but in a nutshell: I have a device for which the IP packet delivery is supported by a "switch". To upgrade my device, it goes through a hard reset to launch into BOOT mode, requests an IP, then firmware transfer can take place. The issue arises with the hard reset: the physical link goes down momentarily and is quickly restored once running BOOT, then the IP request is made through the normal arp/dns/dhcp mechanism. Up until now, with the use of "dumb" switches, the process is seamless.

The new application I am developing requires the use of a managed switch/router (such as the Cisco SF350 class) that can be queried for information, example: which device MACs are serviced over which ports. I developed my application using a non-Cisco managed switch, but that momentary link down/up causes communication issues preventing device firmware upgrade. Hence the question when using a Cisco class of "managed, smart switch/router": is there a configuration parameter (OSPF for example) that would maintain routing information and lessen the impact of such a "momentary link down/up" event?

[Richard Burts]

Thank you for the clarification. I believe that what you are describing may be the behavior of many switch ports when they participate in Spanning Tree. When a port has been down and transitions to the up state it goes through the stages of listening, then learning, before it becomes active in the forwarding state. And that does sometimes impact devices that want/need to communicate quickly after entering the up state. A solution on many Cisco switches is to configure the port with the portfast parameter. I am not clear if this is an option on the SF350 switches.