Débit fortement diminué après routage

alix

Bonjour,

J'ai mis en place une version pfsense (dernière version 2.1.4) sur un esx avec assez de ressources pour être tranquille pendant les tests.

J'ai une curiosité quand je suis du coté LAN. Si je suis dans le sous réseau qui se trouve directement sur la patte Lan, le débit internet est parfait et conforme à l'offr'e du FAI.

Si je suis sur un sous réseau, le débit est divisé par 4/5. Le routage est en statique pour l'instant et pfsense sait ou renvoyer les sous réseaux via le bon next hop. Le phénomè est donc lié à priori au fait de passer des routeurs. Est-ce que quelqu'un aurait déjà rencontré le phénomène ?

Poste client dans le même LAN que la patte Local de PFsense
ex : @WAN –-PF---@LAN(172.16.0.254/24)<--------------->PC client (172.16.0.1/24) => débit internet OK

Poste client dans un LAN différent de la patte Local de PFsense
ex : @WAN ---PF---@LAN(172.16.0.254/24) <--------------->(@1:172.16.0.253/24)----routeur----(@2:172.16.1.0.254/24)<-----------------PC client(172.16.1.1/24) => débit internet divisé par 4/5
route statique sur PF 172.16.0.0/16 vers 172.16.0.253

Merci d'avance pour ceux ou celles qui auraient un début de piste, je sèche pour l'instant.

Tatave

Salut salut

Premièrement , quels sont vous mesures et mode de mesures pour affirmer vos dires ?
Deuxièmement, vous êtes sur du mode virtualisé les mesures que vous aurez seront automatiquement faussé vis à vis d'un montage sur une machine physique.
Troisièmement, dans le cadre d'une virtualisation, personnellement je test des fonctionnalités et non les débits.

Cordialement.

baalserv

Bonsoir

Supprimer la route statique car en l'état elle ne sert à rien si ce n'est à créer un éventuel problème de route ''retour''
(en prime elle est fausse^^)

pour info : (copier/coller du texte de la page d'ajout de route statique de pf)

'' Note: Do not enter static routes for networks assigned on any interface of this firewall. Static routes are only used for networks reachable via a different router, and not reachable via your default gateway.''

Cordialement

alix

@Tatave:

Salut salut

Premièrement , quels sont vous mesures et mode de mesures pour affirmer vos dires ?
Deuxièmement, vous êtes sur du mode virtualisé les mesures que vous aurez seront automatiquement faussé vis à vis d'un montage sur une machine physique.
Troisièmement, dans le cadre d'une virtualisation, personnellement je test des fonctionnalités et non les débits.

Cordialement.

Bonjour.

Nous avons plusieurs lignes internet fibres avec des hauts débit garantis et des serveurs sur le wan pour vérifier entre autre.
oui et non, connaissez vous les switch virtuels Cisco/HP sur vmware ? comment pouvez-vous prétendre qu'elle seront faussés sans connaître mon installation et mon architecture. De plus l'avantage des ESX pro est d'appeler directement les adresses hardware pour justement améliorer les performances et être proche de la machine pure(overhead très faible). D'autres part, nos serveurs ESX sont taillés pour bien plus et pfsense ne genère pas grand chose en charge.
nous avons des installations checkpoint en vmware depuis pas mal de temps et supporté par le constructeur en ESXi 5.5. personnellement, je test tout ce que je peux.

Je te remercie de réponde mais cela ne m'aide pas vraiment dans ma problématique. Pour me présenter un peu, je connais bien openbsd(surtout)et freebsd depuis une dizaine d'année et je réalisais tout à la main ou avec des programmes maisons. C'est la première fois que j'essaye une version avec une ihm pour faire un firewall : c'est plus accessible pour des collaborateurs non habitué à la cli et je trouve en cela que PFsense est bien pensé.

jdh

Point 1 :
La virtualisation (type 1) induit nécessairement une latence, plus ou moins, importante versus un firewall sur un hardware physique.
En effet, dans une virtualisation (type 1), il y a émulation de périphériques d'une part, et gestion de la virtualisation réseau d'autre part.
(Je ne connais pas dans la pratique les switchs virtuels Cisco Nexus, mais je comprends qu'il s'agit de fournir l'OS des switchs Cisco à l'intérieur de VMware, ce qui peut améliorer la perf du code VMware d'origine.)
Toutefois, VMware est connu pour réduire au maximum cette "latence de virtualisation".

Point 2 :
Je reste perplexe sur le routage choisi :

le lan du firewall est 172.16.0.x/24
le réseau distant est 172.16.1.x/24
le routeur entre les 2 est 172.16.0.253 / 172.16.1.254 (j'ai corrigé !)
la route est 172.16.x.x/16 via le routeur : le réseau indiqué englobe le lan du firewall !!
(Si on mesure la performance, il faut regarder très précisément les petites erreurs …)

ccnet

Commençons peut par supprimer cette route statique dont je confirme l'inutilité si ce n'est la nocivité. Et voyons ce qui se passe.

baalserv

/ mode troll On

Après Alice au pays des merveilles voiçi Alix sur la route des merveilles

/ mode troll Off

Ok je sort ^^

alix

@baalserv:

Bonsoir

Supprimer la route statique car en l'état elle ne sert à rien si ce n'est à créer un éventuel problème de route ''retour''
(en prime elle est fausse^^)

pour info : (copier/coller du texte de la page d'ajout de route statique de pf)

'' Note: Do not enter static routes for networks assigned on any interface of this firewall. Static routes are only used for networks reachable via a different router, and not reachable via your default gateway.''

Cordialement

Bonjour,

Merci pour ton retour ! Pour info, mon explication est un exemple pour résumé ma problématique. Et j'ai quand même du mal à comprendre pourquoi celui-ci serait faux ?

ex : @WAN –-PF---@LAN(172.16.0.254/24) <--------------->(@1:172.16.0.253/24)----routeur----(@2:172.16.1.0.254/24)<-----------------PC client(172.16.1.1/24) => débit internet divisé par 4/5
route statique sur PF 172.16.0.0/16 vers 172.16.0.253

Dans l'exemple, les masques sont différents : le sous réseau local est en 172.16.0.0/24. Par contre après tu as derrière un autre réseau en 172.16.1.0/24. du coup la route statique permet de l'atteindre et tous en 172.16.X.0/24 (ou moins selon les sous réseaux). dans le routage, on regarde d'abord les connected route, ensuite les static routes et ensuite selon les protocoles comme ospf/eigrp et leur valeur(genre ospf=110) et le poid de la route. Cette exemple est correcte, même si il est moins souple au cas ou il y aurait un sous réseau 172.16.X.0 sur un autre routeur. Et dans ce cas on jouera sur la métric. Sinon il faut utiliser des igp. mais quagga n'est pas toujours top selon les besoins. En attendant, dans ma situation, cela n'est pas le cas et je constate le phénomène de manière quantifiable et reproductible sur deux installations.

jdh

Concernant la route, j'explique clairement que cette route est inadéquate !

De toute façon, il est très simple de corriger cette route et de regarder si cela change quelque chose.
C'est même tellement simple que je commence à douter du sérieux de l'analyse …

alix

@jdh:

Point 1 :
La virtualisation (type 1) induit nécessairement une latence, plus ou moins, importante versus un firewall sur un hardware physique.
En effet, dans une virtualisation (type 1), il y a émulation de périphériques d'une part, et gestion de la virtualisation réseau d'autre part.
(Je ne connais pas dans la pratique les switchs virtuels Cisco Nexus, mais je comprends qu'il s'agit de fournir l'OS des switchs Cisco à l'intérieur de VMware, ce qui peut améliorer la perf du code VMware d'origine.)
Toutefois, VMware est connu pour réduire au maximum cette "latence de virtualisation".

Point 2 :
Je reste perplexe sur le routage choisi :

le lan du firewall est 172.16.0.x/24

le réseau distant est 172.16.1.x/24

le routeur entre les 2 est 172.16.0.253 / 172.16.1.254 (j'ai corrigé !)

la route est 172.16.x.x/16 via le routeur : le réseau indiqué englobe le lan du firewall !!
(Si on mesure la performance, il faut regarder très précisément les petites erreurs …)

Bonjour. Merci pour le retour,

P1) j'ai juste expliqué un petit peu une partie de mon infra, ce n'est pas un débat sur la virtualisation et ce n''est pas ce qui explique la chute d'une fibre de 200mb/s à 20mbs. Nous avons des liaisons vmware en 10G par liens et franchement, la latence est très faible et existe pour tout equipement actif traversé. Elle est -très-légèrement plus elevé sur vmware.

P2) merci pour la correction, effectivement, il y avait un 0 de trop ;D. Pour le reseau, c'est un exemple tapé en ligne pour illustrer le phénomène, mais il est bien plus complexe et différent : je doute qu'expliquer un réseau avec des centaines de routeurs est un quelconque interet. J'ai deux autres installations tests ou les réseaux routés ne se superpose pas( des sous classes A et B) et j'ai le même phénomène sur ces installations.

@ccnet:

Commençons peut par supprimer cette route statique dont je confirme l'inutilité si ce n'est la nocivité. Et voyons ce qui se passe.

Je suis désolé, mais vous manquez de connaissance réseaux pour balancer une chose pareil. je vous conseil les CCNA, les docs HP, ou autre littérature bien fourni et de regarder attentivement la différence entre une static route et une connected route et l'implémentation des algo de routage. Idéalement, vous prenez deux/trois routeur Cisco ou MSR, ou/et avec des Linux, vous montez un petit ospf et observez le résultat et l'annonce des routes et le routage prix en compte au lieu de lancer une contrevérité pareil. C'est un peu comme les débutants qui pensent que des vlans différents ne peuvent pas communiquer entre eux en niveau 2.

ccnet

Ce n'est pas ce que j'i affirmé. Pfsense et conçu pour fonctionner sans route statique ajoutée pour les réseaux connectés à ses interfaces. Rien d'autre.

jdh

Vous ne répondez pas à la remarque essentielle :
la route désigne un réseau via un routeur, or le réseau indiqué englobe le LAN !

Rectifiez cet état de fait, peut-être que les éléments changeront …
Il me semble, intuitivement, que cela peut-être un problème de transfert de paquet ...

Merci de restez sur des faits.
Un jargon technique peut-être intéressant, mais il en faut plus pour nous impressionner.
Sur ce forum, le nombre de "posts" (et la teneur) est une indication valable d'expertise pratique.

alix

@ccnet:

Ce n'est pas ce que j'i affirmé. Pfsense et conçu pour fonctionner sans route statique ajoutée pour les réseaux connectés à ses interfaces. Rien d'autre.

Vous avez "confirmer que c'était inutile. primo c'était un exemple et dans le cas d'un des tests, c'est que tout simplement, il y a des dizaines de routes. Je n'ai pas mis quagga pour ces tests et dans le cas de ce test la, j'ai englobé pour éviter la saisie fastidieuse surtout quand cela n'impact en rien : une route statique aura minimum une métrique de 1/1 et une connected de 1/0. Le risque est uniquement si l'interface tombe et de router un réseau inutilement. Mais comme c'est sur l'interface, les autres réseaux ne seront pas routés et le lan non plus donc il ne se passera rien. En terme d'esthetique, je le concéde, sur un igp, il y aura deux routes pour un réseau particulier mais qui arriveront sur le même routeur (pfsense ici) et qui routera correctement. J'accepte volontiers mes erreurs et tout le reste (j'aurai du surtout mettre un exemple illustrant un réseau non superposé, vous butez dessus), mais j'ai toujours du mal quand on est aussi affirmatif sans argumenter d'autant plus que c'est faux.

jdh

Qu'est ce que ça vous coute de faire ce qu'on vous suggère (au lieu d'ergoter) ?

Quelque soit le système, il est très clair que créer une route qui englobe le LAN peut être une erreur !
C'est d'autant plus douteux que le débit depuis le LAN est correct …

alix

@jdh:

Vous ne répondez pas à la remarque essentielle :
la route désigne un réseau via un routeur, or le réseau indiqué englobe le LAN !

Rectifiez cet état de fait, peut-être que les éléments changeront …
Il me semble, intuitivement, que cela peut-être un problème de transfert de paquet ...

Merci de restez sur des faits.
Un jargon technique peut-être intéressant, mais il en faut plus pour nous impressionner.
Sur ce forum, le nombre de "posts" (et la teneur) est une indication valable d'expertise pratique.

Je l'ai déjà dit précedemment, j'ai plusieurs installations de tests pfsense (3) et une seule à son réseau qui engloble son réseau local pour différentes raisons techniques, mais ne parlons plus de cette installation, cela gène trop la compréhension et mon exemple est pour le coup mauvais, méa culpa. Dans les faits et sur les trois installations, j'observe le phénomène et ce dès que je passe un saut ou plus derrière l'interface lan. Dès que je ne suis plus sur le lan, mais dans un autre réseau, les perfs tombent.

NB : Pour ce qui est d'impressionner, j'ai passé l'age depuis longtemps .Le but est que mon message soit compris le mieux possible pour éventuellement en dégager une nouvelle piste que je n'ai pas exploré. J'ai cru bon alors de préciser un peu certains éléments en croyant économiser du temps à d'éventuel contributeurs et éviter la dispersion. J'essaye de rester sur les faits et de me restreindre à ceux-ci. Hors, on met de suite en doute la qualité de l'analyse (pourquoi pas), on parle de vmware(avec une chute de 180Mb/s ?) et de latence, de nocivité et d'inutilité de réseau et la j'ai un peu - beaucoup- de mal surtout quand on ne connait pas l'archi en face ni la personne et ses compétences et ce n'est pas le but sur un forum se voulant technique. Je ne desepère pas de trouver malgré tout et chaque information est bonne à prendre et explorer.

jdh

C'est la seule piste évidente, alors raison de plus pour évacuer cette hypothèse.

En ce qui me concerne, j'éviterai de créer une route 'incorrecte' : pfSense n'est pas un routeur : il ne doit avoir, sur ce sujet précis, aucun subterfuge pour s'adapter à une écriture 'paresseuse' (comme un OS de routeur spécialisé) que le routage basic de la stack FreeBsd !

Au lieu de raconter votre vie, évacuer l'hypothèse et tester.

Merci, pour moi, c'est stop si la situation n'est pas testée correctement sans route erronée.

alix

@jdh:

Qu'est ce que ça vous coute de faire ce qu'on vous suggère (au lieu d'ergoter) ?

Quelque soit le système, il est très clair que créer une route qui englobe le LAN peut être une erreur !
C'est d'autant plus douteux que le débit depuis le LAN est correct …

Je n'ergote pas. Je l'ai fait dès le départ sur deux installations sur 3 merci me lire correctement, une seule est dans ce cas et j'ai eux l'idée très mauvaise de taper un exemple illustrant ce cas (Punaise, je m'en mordrais presque les doigts ;D).

Oubliez l'exemple du départ, vous bloquez tous dessus et j'ai fais mon méa culpa.

quand j'ai (c'est un exemple encore)

@WAN
|
[PF v2.1.4 sur ESX]
|
@LAN(172.16.0.254/24)
|
| -LAN 172.16.0.0/24 (debit OK)
|
@S0:172.16.0.253/24)
|
[routeur quelconque]
|
@S1:10.0.0.254/24)
|
|- PC client(10.0.0.1/24) => débit internet divisé par 4/5

route statique sur [PF] -> 10.0.0.0/24 gw 172.16.0.253

le débit chute; quelque soit le sous réseau. En dehors du Lan les performances sont très loin de l'optimum

jdh

Concernant le problèmes de routes, plutôt que de vous entêter, plutôt que d'écrire des routes "trop larges", plutôt que d'invoquer ospf, igp, et autres, il serait judicieux d'écrire les seules routes nécessaire et correctes, et ainsi d'éviter de braquer les lecteurs !

Concernant votre problème de perf différente, je constate que

pour un PC connecté au LAN, et pour du trafic PC <-> WAN, la perf est correcte,
pour un PC connecté à un réseau relié au LAN via un routeur ET une route (correcte) indiquée dans la section System > Routing > onglet Routes, et pour du trafic PC <-> WAN, la perf est très inférieure.

De facto, il y a 3 sources possibles de problèmes :

une perf insuffisante (ou des pertes de paquets) au niveau du routeur : tests à faire entre un PC dans le LAN et un PC dans le réseau routé
une route mal écrite dans System > Routing
un fonctionnement anormal de routage de pfSense
L'ordre est du plus probable au moins probable.

Juve

Ho ho ho,

Thread animé que voici !

Je vous suggère de faire, si ce n'est deja fait, le test proposé par jdh. A savoir test du débit au travers du routeur.

Bonline

slt a tous !

je veux pas faire mon casse bonbon, mais moi quand j ai un ralentissement et que je traverse du NAT, surtout si il est en cascade, j aime bien faire des contre tests un peu partout pour verifier d'ou peut bien venir le goulot

ca coute quoi de faire des verifs sur toutes et depuis toutes les interfaces?

de plus, j aimerai bien savoir sur quoi il se base pour ses tests, c est du HTTP?

par ailleurs, c est quoi ces lignes WAN ? loadbalancées? le routage est il bien bon dans routing / group, avec des tiers 1 sur chaque sortie, et avec des tiers 1, 2, 3 etc pour le traffic securisé ? histoire d'eviter que le trafic securisé soit balancé en cours de session..

par ailleurs, quelle est la boucle locale de ces liens "fibre" ?

il nous parle de "plusieurs lignes dédiées fibre"
ce a quoi je réponds: quand je prends du dédié, j en prends qu'une avec le débit quil me faut.

combien vous pariez qu'on est sur de la fibre de grand public ?
pire encore, sur des modems groupés numéricable ?

concernant NC, moi je veux bien! sur certains sites, j'aggrege des modems numéricable ya pas de probleme ca multiplie par X le débit, mais bon on doit bien savoir que rien n'est garanti, de plus, ca va pour 4-5 modems, mais ca sert plus a rien apres, car souvent on est sur une poche de 8 VD, donc poche de 400Mbits

en gros: avec 5 modems NC il va au mieux tirer sur du 200/10 (chacun) un global de 400 (8VD de 50) et de 50 en UP (sur 2 VD de 30mbits)

et ca ce n'est que du théorique.
donc si ce monsieur additionne les débits théoriques des fichiers de config de ses modems sans se soucier de la collecte, il se fiche bien les doigts dans l'oeil

(exemple : j ai 5 modems qui me donnent chacun 200 Mbits, donc => je veux avoir le giga)
REVE.. comment aurait il 1000 sur un réseau mutualisé de 400 …

et ca ca vaut pour tout, même sur un lien fibre optique relié en passif a un noeud..
bref

que ce monsieur nous dise donc, comment il réalise ses tests, et sur quel réseau il se trouve, car vu ce que je lis, j ai pas l impression d avoir une fibre nérim 1G ou 10G d'utilisée sur ces tests, mais plus des accès isolés cascadés et donc tous soumis a un goulot de collecte commun.

je dis peut etre que des conneries, corrigez moi ^^