Fehler / Feature Request: Tagging bei verketteten FW-Regeln

[Koppelfeld]

Moin!
Wie hier schon diskutiert, ist eine QoS-Regel
"from ANY, to ANY, DSCP EF, ACCEPT"
recht problematisch - wird aber leider von LANCOM so empfohlen.

Dr. Einstein meinte sinngemäß, "Kein Problem, verkette die Regeln".

Doof jetzt: Das in der ursprünglichen Regel definierte Routing Tag, in diesem Falle die 0, kann mit einer nachfolgenden Regel nicht mehr verändert werden -- d.h., im vorliegenden Beispiel habe ich das 'policy-based routing' faktisch abgeschaltet.

Wie wäre es:
Die LETZTE Regel setzt das angegebene Tag...

[backslash]

Hi Koppelfeld,

Wie wäre es:
Die LETZTE Regel setzt das angegebene Tag...

auch damit wirst du Leute unglücklich machen.... es hat schon einen Grund warum die "spezifischste" Regel - also die erste - das Tag setzt. Um allen gerecht zu werden, müßte man das eigentlich schaltbar machen - aber selbst dann wirst du wahrscheinlich noch eine Kombination finden, bei der es mal die erste und die letzte Regel ist, die das Tag setzen soll...

Gruß
Backslash

[Koppelfeld]

Die LETZTE Regel setzt das angegebene Tag...

auch damit wirst du Leute unglücklich machen....

Damit habe ich immer gut leben können.

Aber ich kann die Argumentation natürlich nachvollziehen.

Es paßt auch ins Firewallkonzept:
Je spezifischer eine Regel, desto höher ist sie priorisiert.

Bloß wenn man, schön nach Art der Scholastiker, zuerst die praemissa maior definiert und dann, eine Ebene darunter, diverse praemissae minores (mit unterschiedlichen Routing-Zielen), dann klappt das nicht mehr.

es hat schon einen Grund warum die "spezifischste" Regel - also die erste - das Tag setzt.

Und wenn man folgendes implementiert:
"Jede Firewallregel darf das Routing-Tag setzen, sofern es noch Null ist"?

Gut, dann wird es sehr esoterisch. Aber es kommt nahe daran, was der späte C.S. Peirce mit 'Abduktion' gemeint haben mag.

[Dr.Einstein]

Hallo Koppelfeld,

kannst du mal dein Regelwerk zeigen, was du erreichen möchtest? Vielleicht gibt es ja eine alternative Möglichkeit. Ansonsten stimme ich backslash zu, das momentane Verhalten wird aktiv genutzt.

Gruß Dr.Einstein

[Koppelfeld]

Moin Dr. Einstein,

kannst du mal dein Regelwerk zeigen, was du erreichen möchtest? Vielleicht gibt es ja eine alternative Möglichkeit.

Gut, daß Du das nochmal abgefragt hast.

In der konkreten Situation hatte ich, mit Prio 30:
From ANY - To ANY - ACCEPT + %dEF %Qcds110 für DSCP EF - Weitere Regeln beachten.

Das war es dann GLOBAL mit 'policy based routing'.

Um die Sache zu lösen, ignoriere ich gerade die DSCP - Kacke, welche sowieso extrem unzuverlässig ist (QSC zum Beispiel setzt EF nur, wenn auch der Internetzugang von QSC kommt - ein Schelm, wer böses dabei denkt.
Stattdessen fasse ich UDP und die bekannten Hosts und Netze.
Problem natürlich: Jetzt triggern auch SIP und RTCP eine Datenstromreservierung.

Wie wäre es denn: Routing Tag "-1" i einer Firewallregel heißt: "Leave unchanged"?