Bon il est tard, alors je vais peut-être raconter des c...., mais bon,
c'est trolldi alors c'est permis :-)
Je précise que je n'ai rien contre les forti.
Mais l'explication ne me convainc pas et donc ça me gratouille...
Le 2018-08-31 00:38, Guillaume Barrot a écrit :
Ouaip.
Michel, tu n'es pas sans savoir qu'un TTL expired during transit = 1
interrupt CPU, car il n'existe pas, à ma connaissance, d'ASIC capable
de
répondre un code retour ICMP.
OK quand c'est le Forti qui expire le TTL.
Mais si j'ai bien compris le souci de Michel, c'est aussi le forwarding
des TTL expired des hops suivants qui pêche.
Et dans ce cas c'est juste du forwarding de paquet ICMP, non ?
En quoi c'est différent du forwarding d'un paquet tcp ou udp, ct'affaire
?
A cause d'une vérif stateful ( que le paquet ICMP repond bien à un
paquet qui venait de chez nous ) ?
Pour moi cett vérife devrait aussi être faite sur le forwarding des
autres paquets...
Donc ça me paraît un peu bizarre comme explication, sauf si évidemment
la vérif 'normale' peut être faite en ASIC et pas la vérif ICMP parce
que trop 'complexe' à matcher pour un ASIC.
En tous cas si c'est ça la vraie explication, je vois pas trop en quoi
rate limiter va aider.
Il y aura toujours le TTL expiré, donc l'interrupt.
En plus ça rajoute des compteurs à maintenir, pour chaque host interne
si on suit la KB Forti, donc conso de mémoire et gestion de
tables/tableaux avec time out (ou juste FIFO et tant pis pour les trop
vieux, on n'est plus à ça près à ce stade).
La seule chose qu'on gagne, c'est effectivement de ne pas générer le
paquet ICMP.
Sauf si le rate limiting est fait en ASIC.
Mais je suppose que l'ASIC est quand même pas tout à fait le même entre
le 30E et le 5000E.
Le cas échéant, n'auraient-ils pas pu profiter du fait de rajouter
quelques millions/milliards de transistors sur la puce pour changer ce
1PPS en une autre valeur (voire permettre de le paramétrer avec un
registre ou une instruction quelconque) ?
Or la CPU, des plus petits Fortinet, c'est un Raspi, mais à qui on
aurait
coupé l'oxygene.
Or le FortiOS est le même sur toute la gamme. CQFD, si tu veux pas que
la
CPU du Fortigate 30E parte en cahuete, tu rates limites, et ça
s'appliquera
quand même sur un Fortigate 5000E qui lui aurait pu tenir 10 Millions
de
PPS en TTL expired.
Désolé, pour moi, le CDFQ ici, c'est un raccourci et il ne fonctionne
pas.
Je pense que le code des FG s'adapte en fonction du modèle.
Ne serait-ce que pour le nombre de VDOMs autorisés par exemple.
A nouveau, en même temps que le code qui contrôle le nombre de VDOMs,
pourquoi ne pas mettre une limite cohérente avec le hard et l'usage qui
en sera vraisemblablement fait ?
Franchement, en plus cette tendance récurrente des supports (oui, tous
dans le même sac) à rien comprendre, à d'abord valider que tu as les
certifs 12000++ avant de commencer à regarder (des fois qu'ils
pourraient éviter de répondre, hein) pour au final te répondre juste un
truc qui ne correspond même pas à la description du problème, c'est
effectivement très énervant...
Et au final, je ne suis même pas sûr que le problème de fond soit
remonté aux ingés Forti par ledit support (peut être de peur que ces
derniers ne leur collent une taloche bien méritée parce que le paramètre
existe déjà et qu'ils n'ont juste pas lu leur doc :-))
Cela dit, peut-être lisent-ils FRNoG et qu'il y aura une nouvelle
fonctionnalités dans le prochain update ?
Allez, bon trolldi à tous et à toutes, moi je pars en week-end !
Bon après, cas vécu sur du 7200/7600 et 6500 Cisco y a quelques années,
et
COPP Obligatoire en rate limite ICMP, justement parce que les
traceroutes
te mettaient la CPU à 100% et que BGP flappait ...
Ceux qui ont eu des GSR en prod comprendront.
Donc si le bout de code en question date en plus de 10 ans ....
T'auras plus vite fait de te pointer au HQ de Fortinet en faisant un
scandale :D
Le jeu. 30 août 2018 à 23:15, Michel Py
<mic...@arneill-py.sacramento.ca.us>
a écrit :
> David Ponzone a écrit :
> Ok t’as un exemple pour illustrer la gravité de la chose ?
De mon ordi (1 source) je peux même pas faire UN tracert vers
l'extérieur
sans que le Fortigate me bouffe entre la moitié et les deux-tiers des
hops
(voir plus bas).
> Parce qu’à part si tu passes ton temps à faire des traceroute
simultanés...
Ce n'est pas le cas.
> Et encore, c’est juste le hop du Forti qui répond des *.
Non c'est plus de la moitié des hops au milieu.
- Ca vient du Fortigate (aucun des autres vendeurs n'ont le problème,
mêmes pas ceux que tout le monde évite).
- Ca vient pas de tracert.exe, WinMTR fait la même chose.
- Quand on fait des pings des hops individuels on a 100%.
- On a enlevé antivirus et autres, mis des règles qui laissent tout
entrer
et tout sortir, pareil.
AMHA c'est un rate-limit à la con dans le style 1 PPS.
Pour l'histoire de fous, voir plus bas.
With Fortigate
|------------------------------------------------------------------------------------------|
| WinMTR statistics
|
| Host - % | Sent | Recv | Best
|
Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| crc30r1.rv.am.necel.com - 0 | 54 | 54 | 0
|
0 | 8 | 0 |
| crt-edge1.rv.am.necel.com - 0 | 54 | 54 | 0
|
0 | 12 | 0 |
| crt-border1-v925.tsisemi.com - 0 | 54 | 54 | 0
|
2 | 74 | 1 |
| No response from host - 100 | 11 | 0 | 0
|
0 | 0 | 0 |
| No response from host - 100 | 11 | 0 | 0
|
0 | 0 | 0 |
| No response from host - 100 | 11 | 0 | 0
|
0 | 0 | 0 |
| No response from host - 100 | 11 | 0 | 0
|
0 | 0 | 0 |
| No response from host - 100 | 11 | 0 | 0
|
0 | 0 | 0 |
| No response from host - 100 | 11 | 0 | 0
|
0 | 0 | 0 |
| prs-bb4-link.telia.net - 14 | 37 | 32 | 170
|
171 | 182 | 170 |
| prs-b5-link.telia.net - 0 | 55 | 55 | 146
|
147 | 157 | 146 |
| No response from host - 100 | 11 | 0 | 0
|
0 | 0 | 0 |
| No response from host - 100 | 11 | 0 | 0
|
0 | 0 | 0 |
| No response from host - 100 | 11 | 0 | 0
|
0 | 0 | 0 |
| No response from host - 100 | 11 | 0 | 0
|
0 | 0 | 0 |
| No response from host - 100 | 11 | 0 | 0
|
0 | 0 | 0 |
| craftix.gasmi.net - 0 | 55 | 55 | 152
|
153 | 154 | 153 |
|________________________________________________|______|______|______|______|______|______|
Without Fortigate or with another brand :
|------------------------------------------------------------------------------------------|
| WinMTR statistics
|
| Host - % | Sent | Recv | Best
|
Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| crc30-63.rv.am.necel.com - 0 | 51 | 51 | 0
|
0 | 12 | 1 |
| crt-edge1.rv.am.necel.com - 0 | 51 | 51 | 0
|
0 | 13 | 0 |
| crt-border1-v925.tsisemi.com - 0 | 51 | 51 | 0
|
1 | 40 | 1 |
| 241.dsl6660136.sub-29.surewest.net - 0 | 51 | 51 | 1
|
1 | 13 | 1 |
| 204.154.217.20 - 0 | 51 | 51 | 2
|
2 | 14 | 2 |
| 204.154.217.245 - 0 | 51 | 51 | 2
|
2 | 14 | 2 |
| 204.154.217.196 - 0 | 51 | 51 | 2
|
4 | 41 | 2 |
| sjo-b21-link.telia.net - 0 | 51 | 51 | 6
|
9 | 16 | 11 |
| nyk-bb4-link.telia.net - 0 | 51 | 51 | 75
|
75 | 77 | 76 |
| prs-bb4-link.telia.net - 0 | 51 | 51 | 143
|
143 | 158 | 143 |
| prs-b5-link.telia.net - 0 | 51 | 51 | 146
|
146 | 158 | 146 |
| lostoasis-ic-310624-prs-b5.c.telia.net - 0 | 51 | 51 | 147
|
147 | 158 | 147 |
| No response from host - 100 | 11 | 0 | 0
|
0 | 0 | 0 |
| No response from host - 100 | 11 | 0 | 0
|
0 | 0 | 0 |
| No response from host - 100 | 11 | 0 | 0
|
0 | 0 | 0 |
| sdv-plurimedia.customers-sfr-str.ielo.net - 0 | 51 | 51 | 152
|
153 | 158 | 153 |
| craftix.gasmi.net - 0 | 51 | 51 | 152
|
152 | 153 | 153 |
|________________________________________________|______|______|______|______|______|______|
> Oliver Varenne a écrit :
> A mon avis, (Michel confirmera ou infirmera), le problème n'est pas tant
la gravité de la chose, mais
> surement le fait qu'il a du passer plusieurs heures/jours à chercher
pourquoi il avait des "*" comme
> tu dis, pour se rendre compte qu'il a perdu beaucoup de temps sur une
connerie... Et le pire dans ce
> genre de cas, c'est que quand la connerie est désactivable via une
option, tu te dis "j'ai appris quelque
> chose", mais quand c'est imposé, tu te sens vraiment floué par des
décisions qui semblent arbitraires.
Je sais même pas combien d'heures/hommes on a perdu avec cette
connerie
mais c'est en centaines. J'ai un ingé et un fournisseur qui se sont
cassé
la tête pendant des jours à chercher un problème là ou il n'y était
pas,
parce qu'ils ont fait trop confiance au tracert et qu'ils se sont pas
rendus compte que le Fortigate bouffait la ligne du hop qu'ils étaient
en
train de troubleshooter. Quand on a enlevé le Fortigate et obtenu un
traceroute qui marchait çà leur a immédiatement montré ou était le
problème.
> Soyons honnêtes, dans ce genre de cas ça devrait être sous forme
d'option:
> - limiter les paquets à 1 par seconde pour protéger blablablablabla :
oui/non
Oui, mais en plus 1 PPS en 2018 c'est débile. Ils auraient mis 10 PPS
je
m'en serais pas aperçu, et 100 PPS çà aurait pas tué leur machin non
plus.
Plomber les outils de l'ingé qui cherche un problème, c'est grave. Me
faire perdre encore plus de temps pour essayer de m'expliquer que
c'est pas
leur faute, c'est pire. Payer des vrais gros sous en plus du temps
perdu
pour avoir le privilège de tous ces emmerdements, faut être con. J'ai
été
con, mea culpa, je le referai plus.
Michel.
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
