FWSM Software Unterschiede u. Empfehlung

[delly]

Hallo!

Ich nutze dieses tolle Forum eine zeitlang bereits offline und weiß die vielen Tipps und Lösungen von den Profis sehr zu schätzen !!
Nun habe ich selber ein Anliegen und hoffe, mir wird geholfen...

Auf einem FWSM läuft aktuell die Software-Version 3.2(10) und es wird ein Update auf 4.x geplant. Gibt es grundsätzliche Unterschied zwischen 4.0 und 4.1? Und hat jemand Erfahrungen mit verschieden Version (gute oder schlechte...)? Sollte man lieber auf der 3'er Schiene bleiben und auf die 3.2(22) gehen?
In der Umgebung geht die Stabilität vor irgendwelchen neuen Features. Ich weiß nicht so recht, wie man vorgehen sollte, um eine stabile Version zu "erwischen" und hoffe das Forum kann mir dabei behilflich sein.

Vielen Dank schon einmal vorab für jeden Tipp !!

Robby

[Otaku19]

wir haben 3.2.5 und 4.0.5. Da alles klappt wird da auch nix mehr upgedatet da so und so bald ein ASA Modul statt den lahmen FWSMs eingebaut werden wird interessiert mich das nicht weiter. Dann hab ich auch endlich am Modul den packettracer

[delly]

Danke für deine Antwort !

Ich möchte die Anzahl möglicher ACL auf einer Context erhöhen. Per Default sind 12 Partitions angelegt und hat je Partition 10633 max. mögliche ACL's zur Verfügung. Nun kann man anscheinend die max. Anzahl möglicher ACL's erhöhen, in dem man die Anzahl der Partitions verringert. Die insg. 170K werden dann anstatt 12 z.B. auf 6 Partitions aufgeteilt.
Hat man dann automatisch eine größere Anzahl möglicher ACL's oder muss noch was tun?

context# sh np 3 acl coun
---------------- CLS Rule MAX Counts ----------------
CLS Filter MAX : 425
CLS Fixup MAX : 1417
CLS Est Ctl Rule MAX : 70
CLS Est Data Rule MAX : 70
CLS AAA Rule MAX : 992
CLS Console Rule MAX : 283
CLS Policy NAT Rule MAX : 283
CLS ACL Rule MAX : 10633

Erhöht sich dieser Wert dann automatisch? (Nach speichern und reload)

Hat das schon mal jemand gemacht?

Guter Links dazu: https://supportforums.cisco.com/docs/DOC-13189

Könntest Du schauen, welche max. Anzahl bei Deiner 4.0.5 Software angezeigt wird? (bei Default 12 Partitionen...)

Delly

[Otaku19]

Das lass mal lieber sein die Zahlen sind ja sicher wirklich ziehenden ACEs...also die Zeilen wo die hitcounts drin stehen bzw die Anzahl die an Zeilen die rauskommen wenn man sh access-list brief (gibts erst ab einer bestimmten release) sieht.
Wir haben keine contexte, alles ist in einer Firewall drin und bei 30k Einträge ist das Ding schon recht mühsam zu bedienen. Jedesmal wenn man eine acl hinzufügt kann es da schon gut 3-4min dauern bis die dann auch zieht. Wenn dann wer anderer was machen will kann es dann durchaus sein das derjenige nicht mal in den config mode kommt -.-

Den befehl setze ich morgen mal ab,aber wie gesagt, das FWSM ist eien alte Gurke, die mag das nicht so gerne wenn da zigtausend acls drauf sind...aber ich kann mir schon gut vorstellen wie deine Situation ist, es werden ständig neue rules gemacht, keiner überlegt sich im voraus ob man nciht gleich Netze,object oder ranges gscheit durchdenkt bevor man was requestet. Und gelöscht werdne darf sowieso nie irgendwas.

Schon mal ne Auswertung gemacht wie viele der Zeilen hitcnt=0 sind ? Also ich schlacker bei unserer Firewall nur noch mit den Ohren wenn ich das sehe

[delly]

Hi

das ist das Problem. Ich sehe eine Menge Zeilen mit hitcnt=0. Weil die ACL's aber verschachtelt sind mit opject groups und service groups, wäre es ein Megaaufwand, diese raus zu sortieren...

Siehst Du die Reduzierung der Partitionanzahl kritisch oder die anschließende Zuordnung der Contexte zu den Partitions? Oder sogar beides?

Bin auf Dein Testergebnis gespannt.
Und vielen Dank !!

[Otaku19]

ich müsste noch ne tree_id angeben, aber da nur bei 0 sinnvolle Sachen stehen,denke ich mal das die passen:

FWSM Firewall Version 3.2(5):
CLS ACL Rule MAX : 74188
FWSM Firewall Version 4.0(5)
CLS ACL Rule MAX : 100567

witzig das nur durch eien neuere FWSM Version die maximum Anzahl gleich um 30k erhöht wird. Wobei die abolute Anzahl schon ein merkwürdiger Wert ist.


Anyway, ich halte es für kritisch das man so viele unnötige rules hat, ich kenne dein Dilemma.
Schritt 1: counter zurücksetzen und sagen wir ne Woche warten
Schritt 2: alle ACL (also das was konfiguriert wurde) deren ACEs (was dann schlussendlich draus wird) hitcnt=0 sind werden mal rausgefilter und ein review durchgeführt. Man schaut also obs die beteiligten Kisten noch gibt, muss nachfragen,...sehr mühsam.
Schritt 3: LÖSCHEN, kein warten, auf keinen Fall inactive setzen. WEG DAMIT. Änderungen natürlich dokumentieren
Schritt 4: Dafür sorgen das nicht wieder so ein Tohuwabohu entsteht, sprich bevor man blind alles reinkonfiguriert erst mal überdenek wie mans besser machen könnte. Auch hier ist der Zeitaufwand sehr hoch. Netze statt einzelne hosts in object,ranges statt einzelner Ports. Wenn man mal ein wenig mehr freischaltet als notwendig ist das so gut wie immer zu verschmerzen.

Die Probleme werden nämlich immer schlimmer, der Zeitaufwand ist für das ganze leider sehr hoch. Aber wenn sich Server,Applikationsleute oder sonst jemand aufregt hilft nur eines: Ab zu jemanden der die Kosten im Auge und was zu sagen hat, denn das Argument: Cisco ist teuer, falls wir mal den FW Hersteller wechseln müssen/wollen ist es defakto unmöglich das ruleset 1:1 zu übernehmen und mit weit mehr Arbeit verbunden als regelmässige reviews zu machen.