Des routes sur la passerelle de sortie pour chaque sous-réseau ?
Ca pourrait être ça, mais même si c'était ça, je ne "vois" aucune autre machine des autres sous réseaux, sauf les switches (tous) du VLAN 1
À tout hasard, un lien avec la sysctl net.link.vlan.soft_pad décrite dans vlan(4) ?
C'est juste une idée comme ça.
xavier
Patrick Lamaizière wrote:
À tout hasard, un lien avec la sysctl net.link.vlan.soft_pad décrite dans vlan(4) ?
Effectivement, ça pourrait avoir un rapport, vu que ça route vers le vlan non taggué, et pas les autres.
Je vérifie ça...
Bon, aucun effet. Et comme en lisant man 4 vlan j'ai vu que le support dotQ était émulé dans fxp, et que j'avais une bge sous la main, j'ai essayé aussi. Rien.
Pour info, l'état des interfaces (la table de routage reste celle que j'ai postée hier)
-- Xav In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear.
Patrick Lamaizière <adresse@est.invalid> wrote:
À tout hasard, un lien avec la sysctl net.link.vlan.soft_pad décrite
dans vlan(4) ?
Effectivement, ça pourrait avoir un rapport, vu que ça route vers le vlan non
taggué, et pas les autres.
Je vérifie ça...
Bon, aucun effet. Et comme en lisant man 4 vlan j'ai vu que le support dotQ était
émulé dans fxp, et que j'avais une bge sous la main, j'ai essayé aussi. Rien.
Pour info, l'état des interfaces (la table de routage reste celle que j'ai postée
hier)
À tout hasard, un lien avec la sysctl net.link.vlan.soft_pad décrite dans vlan(4) ?
Effectivement, ça pourrait avoir un rapport, vu que ça route vers le vlan non taggué, et pas les autres.
Je vérifie ça...
Bon, aucun effet. Et comme en lisant man 4 vlan j'ai vu que le support dotQ était émulé dans fxp, et que j'avais une bge sous la main, j'ai essayé aussi. Rien.
Pour info, l'état des interfaces (la table de routage reste celle que j'ai postée hier)
[ ~]# tcpdump -vv -i vlan3 host 172.16.214.102 tcpdump: listening on vlan3, link-type EN10MB (Ethernet), capture size 96 bytes 10:30:41.140953 IP (tos 0x0, ttl 1, id 50332, offset 0, flags [none], proto UDP (17), length 52, bad cksum 0 (->665a)!) 172.16.214.102.50328 > 10.75.2.1.33438: [udp sum ok] UDP, length 24 10:30:46.141358 IP (tos 0x0, ttl 1, id 50333, offset 0, flags [none], proto UDP (17), length 52, bad cksum 0 (->6659)!) 172.16.214.102.50328 > 10.75.2.1.33439: [udp sum ok] UDP, length 24
C'est pas normal les "bad cksum" ?
Cela peut être un artefact de tcpdump avec les interfaces qui font du checksum offload.
Pascal Hambourg
Xavier a écrit :
Pascal Hambourg wrote:
Des routes sur la passerelle de sortie pour chaque sous-réseau ?
Ca pourrait être ça, mais même si c'était ça, je ne "vois" aucune autre machine des autres sous réseaux, sauf les switches (tous) du VLAN 1
Si tu dis que depuis la passerelle tous les réseaux répondent alors la couche liaison est ok et je doute que ce soit un problème de VLAN. Je pense plutôt à un problème de routage IP entre sous-réseaux, comme des routes incorrectes pour le trajet retour vers 172.16.214.0/24.
Tu écris que le VLAN 1 est non taggé, pourtant l'interface de la passerelle dans ce VLAN (vlan0) est bien taggée ? Tu veux dire non taggé entre les switches ?
Des routes sur la passerelle de sortie pour chaque sous-réseau ?
Ca pourrait être ça, mais même si c'était ça, je ne "vois" aucune autre
machine des autres sous réseaux, sauf les switches (tous) du VLAN 1
Si tu dis que depuis la passerelle tous les réseaux répondent alors la
couche liaison est ok et je doute que ce soit un problème de VLAN. Je
pense plutôt à un problème de routage IP entre sous-réseaux, comme des
routes incorrectes pour le trajet retour vers 172.16.214.0/24.
Tu écris que le VLAN 1 est non taggé, pourtant l'interface de la
passerelle dans ce VLAN (vlan0) est bien taggée ? Tu veux dire non taggé
entre les switches ?
Des routes sur la passerelle de sortie pour chaque sous-réseau ?
Ca pourrait être ça, mais même si c'était ça, je ne "vois" aucune autre machine des autres sous réseaux, sauf les switches (tous) du VLAN 1
Si tu dis que depuis la passerelle tous les réseaux répondent alors la couche liaison est ok et je doute que ce soit un problème de VLAN. Je pense plutôt à un problème de routage IP entre sous-réseaux, comme des routes incorrectes pour le trajet retour vers 172.16.214.0/24.
Tu écris que le VLAN 1 est non taggé, pourtant l'interface de la passerelle dans ce VLAN (vlan0) est bien taggée ? Tu veux dire non taggé entre les switches ?
xavier
Pascal Hambourg wrote:
Si tu dis que depuis la passerelle tous les réseaux répondent alors la couche liaison est ok et je doute que ce soit un problème de VLAN. Je pense plutôt à un problème de routage IP entre sous-réseaux, comme des routes incorrectes pour le trajet retour vers 172.16.214.0/24.
Alors, oui, certaines machines ont une autre route par défaut. Mais net.inet.ip.forwarding=1 devrai faire que les paquets émis depuis la passerelle lui reviennent -c'est le cas- et soient retransmis à l'interface qui a initié la connection ?
Tu écris que le VLAN 1 est non taggé, pourtant l'interface de la passerelle dans ce VLAN (vlan0) est bien taggée ? Tu veux dire non taggé entre les switches ?
Je me suis peut-être mal exprimé, ou bien ma connaissance des VLANs est incomplète, mais le VLAN 1 est toujours non taggué, puisque c'est celui par défaut, il me semble ?
-- Xav In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear.
Si tu dis que depuis la passerelle tous les réseaux répondent alors la
couche liaison est ok et je doute que ce soit un problème de VLAN. Je
pense plutôt à un problème de routage IP entre sous-réseaux, comme des
routes incorrectes pour le trajet retour vers 172.16.214.0/24.
Alors, oui, certaines machines ont une autre route par défaut. Mais
net.inet.ip.forwarding=1 devrai faire que les paquets émis depuis la
passerelle lui reviennent -c'est le cas- et soient retransmis à
l'interface qui a initié la connection ?
Tu écris que le VLAN 1 est non taggé, pourtant l'interface de la
passerelle dans ce VLAN (vlan0) est bien taggée ? Tu veux dire non taggé
entre les switches ?
Je me suis peut-être mal exprimé, ou bien ma connaissance des VLANs est
incomplète, mais le VLAN 1 est toujours non taggué, puisque c'est celui
par défaut, il me semble ?
--
Xav
In your pomp and all your glory you're a poorer man than me,
as you lick the boots of death born out of fear.
Si tu dis que depuis la passerelle tous les réseaux répondent alors la couche liaison est ok et je doute que ce soit un problème de VLAN. Je pense plutôt à un problème de routage IP entre sous-réseaux, comme des routes incorrectes pour le trajet retour vers 172.16.214.0/24.
Alors, oui, certaines machines ont une autre route par défaut. Mais net.inet.ip.forwarding=1 devrai faire que les paquets émis depuis la passerelle lui reviennent -c'est le cas- et soient retransmis à l'interface qui a initié la connection ?
Tu écris que le VLAN 1 est non taggé, pourtant l'interface de la passerelle dans ce VLAN (vlan0) est bien taggée ? Tu veux dire non taggé entre les switches ?
Je me suis peut-être mal exprimé, ou bien ma connaissance des VLANs est incomplète, mais le VLAN 1 est toujours non taggué, puisque c'est celui par défaut, il me semble ?
-- Xav In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear.
Pascal Hambourg
Xavier a écrit :
Pascal Hambourg wrote:
Si tu dis que depuis la passerelle tous les réseaux répondent alors la couche liaison est ok et je doute que ce soit un problème de VLAN. Je pense plutôt à un problème de routage IP entre sous-réseaux, comme des routes incorrectes pour le trajet retour vers 172.16.214.0/24.
Alors, oui, certaines machines ont une autre route par défaut.
Et le routeur désigné par cette route par défaut, il sait comment atteindre les autres sous-réseaux via ta passerelle ?
Mais net.inet.ip.forwarding=1 devrai faire que les paquets émis depuis la passerelle lui reviennent
Ah non. Si c'est comme Linux, ça dit juste à la machine de faire suivre les paquets qui ne lui sont pas destinés.
-c'est le cas-
C'est le cas dans tes essais depuis la passerelle parce que les paquets qui sont émis (et non retransmis) par celle-ci ont comme adresse source l'adresse IP de l'interface de la passerelle dans le sous-réseau de destination, et donc la cible n'a aucun mal à répondre en retour puisque les deux adresses sont dans le même sous-réseau. Cela n'implique pas de "routage" (au sens routeur), c'est de la communication directe.
et soient retransmis à l'interface qui a initié la connection ?
Pour ça, il faut que les réponses soient transmises à la passerelle. Dans un premier temps, tu pourrais tester en activant le NAT source (masquerading) sur toutes les interfaces de ta passerelle. Si ça passe, alors ce n'est pas un problème de couche liaison.
Tu écris que le VLAN 1 est non taggé, pourtant l'interface de la passerelle dans ce VLAN (vlan0) est bien taggée ? Tu veux dire non taggé entre les switches ?
Je me suis peut-être mal exprimé, ou bien ma connaissance des VLANs est incomplète, mais le VLAN 1 est toujours non taggué, puisque c'est celui par défaut, il me semble ?
Je ne sais pas, mais en tout cas tu as défini vlan0 comme une interface taggée, comme les autres vlan*.
Si tu dis que depuis la passerelle tous les réseaux répondent alors la
couche liaison est ok et je doute que ce soit un problème de VLAN. Je
pense plutôt à un problème de routage IP entre sous-réseaux, comme des
routes incorrectes pour le trajet retour vers 172.16.214.0/24.
Alors, oui, certaines machines ont une autre route par défaut.
Et le routeur désigné par cette route par défaut, il sait comment
atteindre les autres sous-réseaux via ta passerelle ?
Mais
net.inet.ip.forwarding=1 devrai faire que les paquets émis depuis la
passerelle lui reviennent
Ah non. Si c'est comme Linux, ça dit juste à la machine de faire suivre
les paquets qui ne lui sont pas destinés.
-c'est le cas-
C'est le cas dans tes essais depuis la passerelle parce que les paquets
qui sont émis (et non retransmis) par celle-ci ont comme adresse source
l'adresse IP de l'interface de la passerelle dans le sous-réseau de
destination, et donc la cible n'a aucun mal à répondre en retour puisque
les deux adresses sont dans le même sous-réseau. Cela n'implique pas de
"routage" (au sens routeur), c'est de la communication directe.
et soient retransmis à
l'interface qui a initié la connection ?
Pour ça, il faut que les réponses soient transmises à la passerelle.
Dans un premier temps, tu pourrais tester en activant le NAT source
(masquerading) sur toutes les interfaces de ta passerelle. Si ça passe,
alors ce n'est pas un problème de couche liaison.
Tu écris que le VLAN 1 est non taggé, pourtant l'interface de la
passerelle dans ce VLAN (vlan0) est bien taggée ? Tu veux dire non taggé
entre les switches ?
Je me suis peut-être mal exprimé, ou bien ma connaissance des VLANs est
incomplète, mais le VLAN 1 est toujours non taggué, puisque c'est celui
par défaut, il me semble ?
Je ne sais pas, mais en tout cas tu as défini vlan0 comme une interface
taggée, comme les autres vlan*.
Si tu dis que depuis la passerelle tous les réseaux répondent alors la couche liaison est ok et je doute que ce soit un problème de VLAN. Je pense plutôt à un problème de routage IP entre sous-réseaux, comme des routes incorrectes pour le trajet retour vers 172.16.214.0/24.
Alors, oui, certaines machines ont une autre route par défaut.
Et le routeur désigné par cette route par défaut, il sait comment atteindre les autres sous-réseaux via ta passerelle ?
Mais net.inet.ip.forwarding=1 devrai faire que les paquets émis depuis la passerelle lui reviennent
Ah non. Si c'est comme Linux, ça dit juste à la machine de faire suivre les paquets qui ne lui sont pas destinés.
-c'est le cas-
C'est le cas dans tes essais depuis la passerelle parce que les paquets qui sont émis (et non retransmis) par celle-ci ont comme adresse source l'adresse IP de l'interface de la passerelle dans le sous-réseau de destination, et donc la cible n'a aucun mal à répondre en retour puisque les deux adresses sont dans le même sous-réseau. Cela n'implique pas de "routage" (au sens routeur), c'est de la communication directe.
et soient retransmis à l'interface qui a initié la connection ?
Pour ça, il faut que les réponses soient transmises à la passerelle. Dans un premier temps, tu pourrais tester en activant le NAT source (masquerading) sur toutes les interfaces de ta passerelle. Si ça passe, alors ce n'est pas un problème de couche liaison.
Tu écris que le VLAN 1 est non taggé, pourtant l'interface de la passerelle dans ce VLAN (vlan0) est bien taggée ? Tu veux dire non taggé entre les switches ?
Je me suis peut-être mal exprimé, ou bien ma connaissance des VLANs est incomplète, mais le VLAN 1 est toujours non taggué, puisque c'est celui par défaut, il me semble ?
Je ne sais pas, mais en tout cas tu as défini vlan0 comme une interface taggée, comme les autres vlan*.
xavier
Pascal Hambourg wrote:
C'est le cas dans tes essais depuis la passerelle parce que les paquets qui sont émis (et non retransmis) par celle-ci ont comme adresse source l'adresse IP de l'interface de la passerelle dans le sous-réseau de destination, et donc la cible n'a aucun mal à répondre en retour puisque les deux adresses sont dans le même sous-réseau. Cela n'implique pas de "routage" (au sens routeur), c'est de la communication directe.
Donc, mon routeur ne route pas CQFD...
> et soient retransmis à > l'interface qui a initié la connection ?
Pour ça, il faut que les réponses soient transmises à la passerelle. Dans un premier temps, tu pourrais tester en activant le NAT source (masquerading) sur toutes les interfaces de ta passerelle. Si ça passe, alors ce n'est pas un problème de couche liaison.
Euh... Je procède comment ? Avec PF ? Pour l'instant, mon fichier ne contient que "set skip on [pour toutes les interfaces]"
> Je me suis peut-être mal exprimé, ou bien ma connaissance des VLANs est > incomplète, mais le VLAN 1 est toujours non taggué, puisque c'est celui > par défaut, il me semble ?
Je ne sais pas, mais en tout cas tu as défini vlan0 comme une interface taggée, comme les autres vlan*.
Je ne sais pas, je me suis inspiré de <http://www.supinfo-projects.com/fr/2005/intervlan_freebsd/2/> La seule différence, est que j'ai en face des Nortel, pas des Cisco. Chez Nortel, il n'y a pas la notion de "trunk", plus exactement, ça s'applique au MLT qui n'a rien à voir. Il n'y a pas non plus de mac-address-table (elle ne liste, précisément, que les MLT) qui pourrait m'aider.
-- Xav In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear.
C'est le cas dans tes essais depuis la passerelle parce que les paquets
qui sont émis (et non retransmis) par celle-ci ont comme adresse source
l'adresse IP de l'interface de la passerelle dans le sous-réseau de
destination, et donc la cible n'a aucun mal à répondre en retour puisque
les deux adresses sont dans le même sous-réseau. Cela n'implique pas de
"routage" (au sens routeur), c'est de la communication directe.
Donc, mon routeur ne route pas CQFD...
> et soient retransmis à
> l'interface qui a initié la connection ?
Pour ça, il faut que les réponses soient transmises à la passerelle.
Dans un premier temps, tu pourrais tester en activant le NAT source
(masquerading) sur toutes les interfaces de ta passerelle. Si ça passe,
alors ce n'est pas un problème de couche liaison.
Euh... Je procède comment ? Avec PF ? Pour l'instant, mon fichier ne
contient que "set skip on [pour toutes les interfaces]"
> Je me suis peut-être mal exprimé, ou bien ma connaissance des VLANs est
> incomplète, mais le VLAN 1 est toujours non taggué, puisque c'est celui
> par défaut, il me semble ?
Je ne sais pas, mais en tout cas tu as défini vlan0 comme une interface
taggée, comme les autres vlan*.
Je ne sais pas, je me suis inspiré de
<http://www.supinfo-projects.com/fr/2005/intervlan_freebsd/2/>
La seule différence, est que j'ai en face des Nortel, pas des Cisco.
Chez Nortel, il n'y a pas la notion de "trunk", plus exactement, ça
s'applique au MLT qui n'a rien à voir. Il n'y a pas non plus de
mac-address-table (elle ne liste, précisément, que les MLT) qui pourrait
m'aider.
--
Xav
In your pomp and all your glory you're a poorer man than me,
as you lick the boots of death born out of fear.
C'est le cas dans tes essais depuis la passerelle parce que les paquets qui sont émis (et non retransmis) par celle-ci ont comme adresse source l'adresse IP de l'interface de la passerelle dans le sous-réseau de destination, et donc la cible n'a aucun mal à répondre en retour puisque les deux adresses sont dans le même sous-réseau. Cela n'implique pas de "routage" (au sens routeur), c'est de la communication directe.
Donc, mon routeur ne route pas CQFD...
> et soient retransmis à > l'interface qui a initié la connection ?
Pour ça, il faut que les réponses soient transmises à la passerelle. Dans un premier temps, tu pourrais tester en activant le NAT source (masquerading) sur toutes les interfaces de ta passerelle. Si ça passe, alors ce n'est pas un problème de couche liaison.
Euh... Je procède comment ? Avec PF ? Pour l'instant, mon fichier ne contient que "set skip on [pour toutes les interfaces]"
> Je me suis peut-être mal exprimé, ou bien ma connaissance des VLANs est > incomplète, mais le VLAN 1 est toujours non taggué, puisque c'est celui > par défaut, il me semble ?
Je ne sais pas, mais en tout cas tu as défini vlan0 comme une interface taggée, comme les autres vlan*.
Je ne sais pas, je me suis inspiré de <http://www.supinfo-projects.com/fr/2005/intervlan_freebsd/2/> La seule différence, est que j'ai en face des Nortel, pas des Cisco. Chez Nortel, il n'y a pas la notion de "trunk", plus exactement, ça s'applique au MLT qui n'a rien à voir. Il n'y a pas non plus de mac-address-table (elle ne liste, précisément, que les MLT) qui pourrait m'aider.
-- Xav In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear.
