de logica fout was al te denken dat een cisco proxy server een firewall is.

Tja dit is altijd een risico bij de manier van configuratie opslag die Cisco gebruikt...

In feite werkt het zo als bij MS-DOS... bij boot wordt er altijd een AUTOEXEC.BAT uitgevoerd (in dit geval je saved config) met commands erin die je ook zelf op de prompt kunt intikken.
Als je de running config saved dan wordt er een nieuwe "AUTOEXEC.BAT" gegenereerd die de huidige configuratie beschrijft. Maar die test je in feite pas bij de eerstvolgende boot. En als er foutjes gemaakt worden zoals de volgorde van onderling afhankelijke commando's (die heel complex kan zijn) dan gaat het gewoon mis.

Ik krijg de indruk dat veel andere merken "onderliggend" de configuratie apart opslaan in een of andere database, en dat die tekstversie er dan alleen is voor het documenteren en extern opslaan van de configuratie, niet voor boot.
Ik ben bij andere spullen ook wel tegen dit soort bugs aangelopen maar die zag je dan pas als je de tekst config in een lege router plakte, terwijl een reboot wel gewoon goed werkte.

What 'echte' Cisco devices (IOS routers, ook ASA fw) is dat de configuratie allerlei kernel/OS datastructuren, en eventueel chips/assics programmeert .
Dat is ook de reden waarom 'show running-config' zo lang duurt - de tekst-configuratie wordt ge(her)genereerd uit allerlei interne structuren.
('database' is daar het woord niet voor ).

Je kunt het meer vergelijken met
echo 1 >/proc/sys/net/ipv4/ip_forward

, en de 'show run' met "echo "echo `cat /proc/sys/net/ipv4/ip_forward` "
Het is dus niet de tekst file van de opgeslagen configuratie tijdens gebruik telkens geraadpleegd wordt.

(Uiteindelijk is dat vrij analoog met allerlei Unix daemons , die je typisch een SIGHUP moet sturen om de config te laten her-interpreteren na een wijziging ). Ook dingen als het procfs , of de sysctl bij startup moet je een script actief opnieuw laten draaien .

Blijkbaar was het mogelijk een config te creeren die bij 'vers' uitvoeren niet leverde wat erin stond.

Nee dat bedoel ik ook niet, "tijdens gebruik", maar wel "tijdens boot"!
Net als bij jouw voorbeeld: als je in dat draaiende Linux systeem even op de prompt intikt "echo 0 >/proc/sys/net/ipv4/ip_forward" dan heb je wel de routing uitgeschakeld, maar als je dat systeem dan reboot dan staat die weer aan (of staat weer zoals ie daarvoor stond) omdat er ergens in sysctl.conf een regel "net.ipv4.ip_forward=1" staat en tijdens het booten die regels in die file weer worden ingesteld in het draaiende systeem.

Zo werkt dat bij Cisco ook, met als verschil dat er niet zoals bij Linux talloze van dat soort files rondhangen op het systeem, maar dat alles in die ene bewaarde "running config" file staat, die bij boot weer wordt "uitgevoerd" als ware het een AUTOEXEC.BAT.

Dus als de logic for "write mem" (of "show running-config") niet de juiste tekstweergave van de op dat moment actieve config geeft, dan ben je (pas) bij de volgende reboot het haasje. En dat lijkt hier het geval te zijn: de tekst versie van de config heeft de verkeerde volgorde, waardoor een commando wat naar een "groep" verwijst eerder in de tekst staat dan de definitie van die groep. En daardoor wordt dat commando rejected met "groep bestaat niet".

Wat ik wil zeggen is dat dit in veel andere devices niet zo werkt, omdat bij een boot niet de simpele tekstfile als bron gebruikt wordt voor het herbouwen van de actieve configuratie van de software, maar een interne weergave (database of wat jij het ook wilt noemen) waarin de onderlinge afhankelijkheden minder kritisch zijn voor de opstartvolgorde.

Natuurlijk .

Wat IOS doet bij 'show run' is het uitlezen/genereren van z'n "startup script" , en "copy run start" (of "write mem") is dus het eerst genereren van een tekst-representatie , en die daarna opslaan in "het" startup script.

Omdat het systeem het genereren doet gaat dat (bijna) altijd foutvrij, in tegenstelling tot admins die live de state veranderen en daarna met "vi /etc/sysconf.conf" nog even de startup file editen .

Hier zat er blijkbaar een bug in het genereren van de tekst-representatie van de live config.



Ah,ik had niet naar de details van de bug gekeken - een acl referen voordat die gedefinieerd is gaat natuurlijk mis.

De (text) config file moet inderdaad zodanig ge(her)geneerd worden dat de interne state van het systeem bij een reboot weer hersteld wordt.
En dependencies zoals het eerst definieren van een acl of groep voordat eraan gerefereerd kan worden is het soort bug dat kan gebeuren.

Een vergelijkbare (user/operator) fout zou je hebben op Unix systemen wanneer de admin na wat testwerk een daemon "met de hand" start , en bijvoorbeeld de config file uit de current directory laat komen, maar in het opstart script geen directory pad meegeeft . Of handmatig wat environment variabelen heeft staan/gezet die niet ook in de opstart scripten staan.


Welke "veel andere devices" heb je in gedachten ?

Eén van de prettige eigenschappen van de meeste netwerk devices (iig degenen die ik onder handen gehad heb) is nu juist _dat_ er een enkele tekst-config file representatie waarin alles zit wat voor backup/restore nodig is van het device .
Als je dat vergelijkt met de hoeveel data/config files die je moet meenemen om "een" server functioneel te herbouwen is dat reusachtig.

IOS (en IOS-XR) zijn tekst, JunOS is dat ook,Arista aimgh tekst - welke doel je op ?

Misschien dat sommige config formaten makkelijker zijn voor de apparaat-parser om zonder groot bug-risico "altijd consistent" te krijgen - maar ik zie niet waarom enig device helemaal immuun zou zijn voor bug waarin de actieve configuratie niet goed terecht komt in de "opgeslagen" configuratie - en daar bij een eerstvolgende boot over struikelt of functionaliteit mist .
(Junos dat een stel braces vergeet te schrijven ? )
Klassiek IOS is dan in zoverre moeilijk(er) voor de parser/generator dat volgorde een rol speelt en de config parsing blijkbaar iedere regel stuk voor stuk uitvoert .

Maar bedenk dat (haast) ieder soort systeem bij config (backups) een _representatie_ van de inhoud/state maakt , en zelden een kale dump van rauwe data .
Database dumps krijg (en wil ) je vaak ook als een serie van SQL statements die de tables ,structuur en inhoud representeren - en "herbouwen" , en zijn gewoonlijk geen snapshot van de onderliggende datafiles waarin de database gebouwd is.

En zowel het 'dump' programma als het "terugladen" ervan kunnen bugs hebben .