ASA Update und kein Ende

11/03/2016 6:52 pm Lutz Donnerhacke

Der Bug mit fragmentieren IPSec Paketen in der ASA war ja laut genug durch die Presse gegangen. Aber nicht alle Systeme lassen sich so einfach aktualisieren.

Wo's klappt und wo nicht

Kein Problem stellen die Failover-Systeme da, die noch in der 8er Reihe verharren. Der Update des erfolgt ganz planmäßig

  • Software auf Standby-Gerät spielen
  • Standby booten
  • Failover tiggern
  • Testen, ob alles geht
  • Software auf (nun anderes) Standby-Gerät spielen
  • (anderes) Standby booten

Kunde merkt davon gar nichts. Das war machbar, sobald die neue Firmware zur Verfügung stand.

Schwieriger wurde es bei Geräten, für die keine Software mehr existiert (PIX) oder noch die neue Software nicht korrekt funktionierte (CSCuy28710).

Als Notlösung wurde dort die ACL auf der Control-Plane so gesetzt, dass UDP/500 und UDP/4500 nicht mehr schaden konnten:

object-group service ike-udp
 service-object udp destination eq isakmp
 service-object udp destination eq 4500
!
object-group network ike-peers
 network-object host b.c.d.e
!
access-list to_cpu extended permit object-group ike-udp object-group ike-peers any
access-list to_cpu extended deny object-group ike-udp any any log warnings
access-list to_cpu extended permit ip any any log warnings
!
access-group to_cpu in interface outside control-plane

In der Object-group iks-peers stehen die bekannten Gegenstellen, die noch VPN-Tunnel aufbauen dürfen. Das skaliert natürlich nicht besonders gut für VPN-Einwahl, reicht aber für alles aus, was nur Lan2Lan-Tunnel hat. In jedem Fall nimmt es Druck aus dem Problem.

Schrittweiser Upgrade

Cisco empfiehlt bestimmte Versionenpfade einzuhalten, um automatische Übernahmen der alten Konfigurationen zu ermöglichen. Da das Ergebnis dieser Übernahmen meist zu schrecklich ist, um es so zu lassen, ziehe ich es vor, eine minimale Konfiguration zum Upgrade zu verwenden. Diese lässt auch größere Sprünge zu, solange nur die IP Konfiguration der Interfaces und der SSH Zugang erhalten bleiben.

Beim Versuch von 9.1(1) auf 9.1(7) zu springen, scheitert das an der Fehlermeldung

asa# copy /noconfirm tftp://2001:db8::67/asa917-smp-k8.bin flash:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
No Cfg structure found in downloaded image file 

Diese Meldung kommt also, bevor das Image aufs Flash geschrieben werden soll. Da er das Image nicht in den Flash legt, kann er auch nicht davon booten.

Dieses Problem ist aber wohl dokumentiert, man muss eben einen bestimmten Upgrade-Pfad einhalten.

asa# copy /noconfirm tftp://2001:db8::67/asa912-smp-k8.bin flash:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
No Cfg structure found in downloaded image file

Was jetzt? Das ist genau das Image, das verwendet werden soll, um diesen Fehler nicht zu bekommen. Auch andere Versuche mit neueren Images führen zu keinem Erfolg: Das aktuell laufende System weigert sich, ein neues Image abzuspeichern! Der Fehler ist seit gestern auch bei Cisco bekannt: CSCuh25271

Aber Moment mal: Das aktuell laufende Image?

Was wäre denn, wenn ich das Image einfach so laden würde. Also irgendwie in die Box reinmogeln (per USB?) und dann davon booten. Das sollte doch gehen?!

Konkreter gefragt: Was wäre, wenn das aktuell laufende Image nicht da wäre? Dann würde sich auch niemand darüber aufregen, dass irgendwelche Strukturen fehlen. Oder etwa doch?

Wenn kein laufendes Image da ist, fällt man auf den ROMMON zurück. Aber den kann man beim Booten auch direkt aufrufen und dann ein Image vom TFTP laden und starten.

Gesagt getan: Es funktioniert.

Einfach so. Und dann kann man auch alle anderen Images aufs Flash installieren.

Avatar
Jörn Raffel 21/09/2017 2:57 pm
Perfekt! Vielen Dank, hat mir gerade meinen Tag gerettet ;-)

https://www.cisco.com/public/technotes/smbsa/en/us/remote/5500_image_rcvry.pdf

Total 1 comments

Post a comment

Related content