Ik denk dat de oorzaak van dit probleem in het niet goed op orde hebben van procedures zit. Dat is dan echt niet alleen voor routers een probleem. Dat zit hem dan in de blinde vlek die achter het ontbreken van de correcte procedure in de eerste plaats zit.

wr er
reload

Is toch niet zo moeilijk?

Dan is die blinde vlek de oorzaak.

Goh, ze hebben weer een stagiair aan een voorspelbaar klusje gezet .

Dat is toch helemaal afhankelijk hoe 'goed' de leverancier dit heeft geimplementeerd, als je je openwrt installeerd word ook een bepaald geheugen met configs niet gewist.
Volgens mij is het beste om eerst foute configuraties op te slaan en daarna pas een reset te doen.

Dit is uiteraard geen representatief onderzoek. Als je tweedehands routers gaat kopen dan krijg je routers van bedrijven die denken "laten we onze oude router verkopen op marktpaats/ebay/whatever" en dat zijn natuurlijk niet de bedrijven waar men dingen in het algemeen goed voor elkaar heeft.

Goh, je kent IOS .

Als je een aangesloten router hebt, en als junior network engineer de taak krijgt om de config te wissen is dit inderdaad wat je doet (op een Cisco IOS device ).

Nu ander scenario : bedrijf(je) heeft router beheer uitbesteed .
Router staat ergens en werkt .
Router wordt geupgrade/vervangen .

De werkende router wordt eruit getrokken, nieuwe erin.
De oude router gaat naar het magazijn.
En wordt dan een keer opgeruimd .

Oeps. Nu moet opeens iemand die magazijn beheer doet bedenken *dat* er een config op zou kunnen staan, en een netwerk engineer vinden, de router op diens buro gooien, en laten wipen .

Snap je dat het _daar_ eerder mis gaat dan dat de engineer die router beheer doet misschien niet zou weten hoe je een config wiped ?

Router wipen terwijl die nog dienst doet is tricky . Het _kan_ (bij cisco) , de write erase wiped de stored config, router werkt door , en bij poweroff is het ding leeg.
Die situatie moet niet heel lang duren als je het bij een vervanging gaat doen, want als de stroom er [eerder] onverwacht af gaat heb je een totale outage .
En - als je beheer goed ingericht hebt - is er een regelmatig proces om wijzigingen in de running config naar startup config te schrijven , om te voorkomen dat een change na een powercycle "zomaar" verdwenen is .
Dus zo'n pro-actieve wipe bij een aanstaande vervanging vergt dan wel veel coordinatie , want anders zet het 'copy run start' script de boel snel weer terug.

Next challenge is natuurlijk dat 'recovery' uit de flash van een "erased" config wellicht wel mogelijk is.

(en er zijn meer merken dan Cisco, allemaal met eigen gedrag omtrent config wipe/restore . )