Débit fortement diminué après routage



  • 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.



  • 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.



  • 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



  • @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.

    1. Nous avons plusieurs lignes internet fibres avec des hauts débit garantis et des serveurs sur le wan pour vérifier entre autre.
    2. 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.
    3. 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é.



  • 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 …)


  • 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.



  • / mode troll On

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

    / mode troll Off

    Ok je sort ^^



  • @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.



  • 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 …



  • @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.



  • 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 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.



  • @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.



  • 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 …



  • @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.



  • 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.



  • @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



  • 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.


  • 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.



  • 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 ^^



  • @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 ^^

    Punaise, comme disais Coluche, quand on n'en sait aussi peu on peut humblement se taire, il est assez penible de lire de telles suppositions (ou est le nat en cascade  ?).
    Alors ce "monsieur" a gentiment dit qu'il avait plusieurs installations de tests et que ce que préconise JDH avait déjà été réalisé. J'ai à priori trouvé l'origine du problème et cela fonctionnait sur une quatrième installation ce qui me permet de debloquer la situation.

    J'ai expliqué ma démarche et voulu (cru naif que j'étais, comme quoi même avec l'âge ;D) gagner du temps pour eviter que l'on me demande éventuellement de refaire ce que j'ai déjà fait ou que je maitrise. Je ne sais pas comment je devais écrire, avec 3 installations de test à la base dont deux sans route "large" . Le thread peut être fermé, ou supprimé.

    PS :  le "monsieur "a plusieurs centaines de routeurs, du mpls, vpls et autre joyeuseté, plus de cent adresses ip  avec des fibres PRO non agregées. On n'est plus à l'époque des liaisons loués  type LS Transpac avec 30 canaux B numeris a gregés pour 1920k et deux canaux D. C'était  il y a 15 ans et je fais des trucs plus sympa. Je suppose que vous aviez de l'humour sans doute en parlant de modem et de ligne numéricale.



  • Tout le monde a bien vu que le post de Bonline n'était pas au niveau !
    Donc il est inutile d'y répondre aussi fermement (et de rappeler pour la n-ième les lignes gérées : cela fait concours de coqs !).

    Puisque "J'ai à priori trouvé l'origine du problème", merci de l'indiquer aux lecteurs (qui ont proposé des pistes) et de clore le sujet.
    Cela rassurera les utilisateurs de VMware …



  • Je suis las…

    Alix, si vous souhaitez partager votre retour d'expérience par rapport à votre problème faites le moi parvenir en MP. C'est le but de ce forum...partager les solutions.

    En attendant je ferme ce thread, car cela va partir je ne sais où....


Locked