Mon serveur frontal possède deux interfaces Ethernet/IP vers le
réseau Internet avec les adresse X.Y.Z.69(eth3) et X.Y.Z.70(eth0)
eth3 est une interface d'administration (X.Y.Z.69/28).
eth0 possède l'adresse X.Y.Z.70/28
Les routes par défaut sont :
Root gershwin:[~] > route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
X.Y.Z.64 * 255.255.255.240 U 0 0 0 eth3
X.Y.Z.64 * 255.255.255.240 U 0 0 0 eth0
localnet * 255.255.255.0 U 0 0 0 eth2
heartbeat * 255.255.255.0 U 0 0 0 eth1
default purcell.systell 0.0.0.0 UG 0 0 0 eth3
Un truc me chagrine : que je fasse un ssh sur X.Y.Z.69 ou X.Y.Z.70,
à chaque fois, je me retrouve sur eth3.
Pire, lorsque je fais un
ping sur 213.215.42.70, je vois eth3 me répondre (alors qu'en toute
logique, eth0 devrait répondre) _même si_ (et j'insiste sur le même
si) eth0 est down !
Toute remarque sera la bienvenue, parce que là, il y a un truc que
je ne comprends pas.
Mon serveur frontal possède deux interfaces Ethernet/IP vers le
réseau Internet avec les adresse X.Y.Z.69(eth3) et X.Y.Z.70(eth0)
eth3 est une interface d'administration (X.Y.Z.69/28).
eth0 possède l'adresse X.Y.Z.70/28
Les routes par défaut sont :
Root gershwin:[~] > route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
X.Y.Z.64 * 255.255.255.240 U 0 0 0 eth3
X.Y.Z.64 * 255.255.255.240 U 0 0 0 eth0
localnet * 255.255.255.0 U 0 0 0 eth2
heartbeat * 255.255.255.0 U 0 0 0 eth1
default purcell.systell 0.0.0.0 UG 0 0 0 eth3
Un truc me chagrine : que je fasse un ssh sur X.Y.Z.69 ou X.Y.Z.70,
à chaque fois, je me retrouve sur eth3.
Pire, lorsque je fais un
ping sur 213.215.42.70, je vois eth3 me répondre (alors qu'en toute
logique, eth0 devrait répondre) _même si_ (et j'insiste sur le même
si) eth0 est down !
Toute remarque sera la bienvenue, parce que là, il y a un truc que
je ne comprends pas.
Mon serveur frontal possède deux interfaces Ethernet/IP vers le
réseau Internet avec les adresse X.Y.Z.69(eth3) et X.Y.Z.70(eth0)
eth3 est une interface d'administration (X.Y.Z.69/28).
eth0 possède l'adresse X.Y.Z.70/28
Les routes par défaut sont :
Root gershwin:[~] > route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
X.Y.Z.64 * 255.255.255.240 U 0 0 0 eth3
X.Y.Z.64 * 255.255.255.240 U 0 0 0 eth0
localnet * 255.255.255.0 U 0 0 0 eth2
heartbeat * 255.255.255.0 U 0 0 0 eth1
default purcell.systell 0.0.0.0 UG 0 0 0 eth3
Un truc me chagrine : que je fasse un ssh sur X.Y.Z.69 ou X.Y.Z.70,
à chaque fois, je me retrouve sur eth3.
Pire, lorsque je fais un
ping sur 213.215.42.70, je vois eth3 me répondre (alors qu'en toute
logique, eth0 devrait répondre) _même si_ (et j'insiste sur le même
si) eth0 est down !
Toute remarque sera la bienvenue, parce que là, il y a un truc que
je ne comprends pas.
C'est tout simple. Pour le routage de Linux, les adresses locales
n'appartiennent pas spécifiquement à une interface particulière mais
globalement à la machine elle-même.
[...]
Quant au fait que le trafic sorte toujours par eth3, tu vois que tu as
deux routes contradictoires vers X.Y.Z.64/28. Une seule est utilisée, en
pratique la dernière créée. Quant aux destinations extérieures, tu vois
que la route par défaut passe explicitement par eth3, donc rien d'anormal.
C'est tout simple. Pour le routage de Linux, les adresses locales
n'appartiennent pas spécifiquement à une interface particulière mais
globalement à la machine elle-même.
[...]
Quant au fait que le trafic sorte toujours par eth3, tu vois que tu as
deux routes contradictoires vers X.Y.Z.64/28. Une seule est utilisée, en
pratique la dernière créée. Quant aux destinations extérieures, tu vois
que la route par défaut passe explicitement par eth3, donc rien d'anormal.
C'est tout simple. Pour le routage de Linux, les adresses locales
n'appartiennent pas spécifiquement à une interface particulière mais
globalement à la machine elle-même.
[...]
Quant au fait que le trafic sorte toujours par eth3, tu vois que tu as
deux routes contradictoires vers X.Y.Z.64/28. Une seule est utilisée, en
pratique la dernière créée. Quant aux destinations extérieures, tu vois
que la route par défaut passe explicitement par eth3, donc rien d'anormal.
Salut,
[...]Mon serveur frontal possède deux interfaces Ethernet/IP vers le
réseau Internet avec les adresse X.Y.Z.69(eth3) et X.Y.Z.70(eth0)
Y a-t-il une raison particulière d'avoir deux interfaces connectées au
même LAN ? Si c'est pour la bande passante ou la redondance, il vaudrait
mieux faire de l'aggrégation de liens.
eth3 est une interface d'administration (X.Y.Z.69/28).
eth0 possède l'adresse X.Y.Z.70/28
Les routes par défaut sont :
Root gershwin:[~] > route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
X.Y.Z.64 * 255.255.255.240 U 0 0 0 eth3
X.Y.Z.64 * 255.255.255.240 U 0 0 0 eth0
localnet * 255.255.255.0 U 0 0 0 eth2
heartbeat * 255.255.255.0 U 0 0 0 eth1
default purcell.systell 0.0.0.0 UG 0 0 0 eth3
Un truc me chagrine : que je fasse un ssh sur X.Y.Z.69 ou X.Y.Z.70,
à chaque fois, je me retrouve sur eth3.
Comment ça, "sur eth3" ? Tu veux dire que le trafic entre toujours par
eth3 ?
Pire, lorsque je fais un
ping sur 213.215.42.70, je vois eth3 me répondre (alors qu'en toute
logique, eth0 devrait répondre) _même si_ (et j'insiste sur le même
si) eth0 est down !
213.215.42.70, c'est X.Y.Z.70 ?
Toute remarque sera la bienvenue, parce que là, il y a un truc que
je ne comprends pas.
C'est tout simple. Pour le routage de Linux, les adresses locales
n'appartiennent pas spécifiquement à une interface particulière mais
globalement à la machine elle-même.
Pour le trafic entrant, par défaut les deux interfaces répondent aux
requêtes ARP pour n'importe quelle adresse locale. L'émetteur de la
requête ARP utilisera l'adresse MAC de la première réponse reçue. En
gros la plus rapide gagne. Il y a quelques paramètres dans
/proc/sys/net/ipv4/*/conf/ permettant de modifier ce comportement.
Quant au fait que le trafic sorte toujours par eth3, tu vois que tu as
deux routes contradictoires vers X.Y.Z.64/28. Une seule est utilisée, en
pratique la dernière créée. Quant aux destinations extérieures, tu vois
que la route par défaut passe explicitement par eth3, donc rien d'anormal.
Salut,
[...]
Mon serveur frontal possède deux interfaces Ethernet/IP vers le
réseau Internet avec les adresse X.Y.Z.69(eth3) et X.Y.Z.70(eth0)
Y a-t-il une raison particulière d'avoir deux interfaces connectées au
même LAN ? Si c'est pour la bande passante ou la redondance, il vaudrait
mieux faire de l'aggrégation de liens.
eth3 est une interface d'administration (X.Y.Z.69/28).
eth0 possède l'adresse X.Y.Z.70/28
Les routes par défaut sont :
Root gershwin:[~] > route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
X.Y.Z.64 * 255.255.255.240 U 0 0 0 eth3
X.Y.Z.64 * 255.255.255.240 U 0 0 0 eth0
localnet * 255.255.255.0 U 0 0 0 eth2
heartbeat * 255.255.255.0 U 0 0 0 eth1
default purcell.systell 0.0.0.0 UG 0 0 0 eth3
Un truc me chagrine : que je fasse un ssh sur X.Y.Z.69 ou X.Y.Z.70,
à chaque fois, je me retrouve sur eth3.
Comment ça, "sur eth3" ? Tu veux dire que le trafic entre toujours par
eth3 ?
Pire, lorsque je fais un
ping sur 213.215.42.70, je vois eth3 me répondre (alors qu'en toute
logique, eth0 devrait répondre) _même si_ (et j'insiste sur le même
si) eth0 est down !
213.215.42.70, c'est X.Y.Z.70 ?
Toute remarque sera la bienvenue, parce que là, il y a un truc que
je ne comprends pas.
C'est tout simple. Pour le routage de Linux, les adresses locales
n'appartiennent pas spécifiquement à une interface particulière mais
globalement à la machine elle-même.
Pour le trafic entrant, par défaut les deux interfaces répondent aux
requêtes ARP pour n'importe quelle adresse locale. L'émetteur de la
requête ARP utilisera l'adresse MAC de la première réponse reçue. En
gros la plus rapide gagne. Il y a quelques paramètres dans
/proc/sys/net/ipv4/*/conf/ permettant de modifier ce comportement.
Quant au fait que le trafic sorte toujours par eth3, tu vois que tu as
deux routes contradictoires vers X.Y.Z.64/28. Une seule est utilisée, en
pratique la dernière créée. Quant aux destinations extérieures, tu vois
que la route par défaut passe explicitement par eth3, donc rien d'anormal.
Salut,
[...]Mon serveur frontal possède deux interfaces Ethernet/IP vers le
réseau Internet avec les adresse X.Y.Z.69(eth3) et X.Y.Z.70(eth0)
Y a-t-il une raison particulière d'avoir deux interfaces connectées au
même LAN ? Si c'est pour la bande passante ou la redondance, il vaudrait
mieux faire de l'aggrégation de liens.
eth3 est une interface d'administration (X.Y.Z.69/28).
eth0 possède l'adresse X.Y.Z.70/28
Les routes par défaut sont :
Root gershwin:[~] > route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
X.Y.Z.64 * 255.255.255.240 U 0 0 0 eth3
X.Y.Z.64 * 255.255.255.240 U 0 0 0 eth0
localnet * 255.255.255.0 U 0 0 0 eth2
heartbeat * 255.255.255.0 U 0 0 0 eth1
default purcell.systell 0.0.0.0 UG 0 0 0 eth3
Un truc me chagrine : que je fasse un ssh sur X.Y.Z.69 ou X.Y.Z.70,
à chaque fois, je me retrouve sur eth3.
Comment ça, "sur eth3" ? Tu veux dire que le trafic entre toujours par
eth3 ?
Pire, lorsque je fais un
ping sur 213.215.42.70, je vois eth3 me répondre (alors qu'en toute
logique, eth0 devrait répondre) _même si_ (et j'insiste sur le même
si) eth0 est down !
213.215.42.70, c'est X.Y.Z.70 ?
Toute remarque sera la bienvenue, parce que là, il y a un truc que
je ne comprends pas.
C'est tout simple. Pour le routage de Linux, les adresses locales
n'appartiennent pas spécifiquement à une interface particulière mais
globalement à la machine elle-même.
Pour le trafic entrant, par défaut les deux interfaces répondent aux
requêtes ARP pour n'importe quelle adresse locale. L'émetteur de la
requête ARP utilisera l'adresse MAC de la première réponse reçue. En
gros la plus rapide gagne. Il y a quelques paramètres dans
/proc/sys/net/ipv4/*/conf/ permettant de modifier ce comportement.
Quant au fait que le trafic sorte toujours par eth3, tu vois que tu as
deux routes contradictoires vers X.Y.Z.64/28. Une seule est utilisée, en
pratique la dernière créée. Quant aux destinations extérieures, tu vois
que la route par défaut passe explicitement par eth3, donc rien d'anormal.
Le 06-10-2007, à propos de
Re: [Linux] Deux interfaces sur le même LAN,
Pascal Hambourg écrivait dans fr.comp.reseaux.ip :Salut,
[...]Mon serveur frontal possède deux interfaces Ethernet/IP vers le
réseau Internet avec les adresse X.Y.Z.69(eth3) et X.Y.Z.70(eth0)
Y a-t-il une raison particulière d'avoir deux interfaces connectées au
même LAN ? Si c'est pour la bande passante ou la redondance, il vaudrait
mieux faire de l'aggrégation de liens.
Il y a une raison particulière qui n'est pas de la redondance :
sur eth0 je fais de la QoS poussée pour les clusters alors que eth3
est une interface d'administration.eth3 est une interface d'administration (X.Y.Z.69/28).
eth0 possède l'adresse X.Y.Z.70/28
Les routes par défaut sont :
Root gershwin:[~] > route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
X.Y.Z.64 * 255.255.255.240 U 0 0 0 eth3
X.Y.Z.64 * 255.255.255.240 U 0 0 0 eth0
localnet * 255.255.255.0 U 0 0 0 eth2
heartbeat * 255.255.255.0 U 0 0 0 eth1
default purcell.systell 0.0.0.0 UG 0 0 0 eth3
Un truc me chagrine : que je fasse un ssh sur X.Y.Z.69 ou X.Y.Z.70,
à chaque fois, je me retrouve sur eth3.
Comment ça, "sur eth3" ? Tu veux dire que le trafic entre toujours par
eth3 ?
Oui. Un tcpdump me montre que 213.215.42.69 et 70 tapent _toujours_
sur eth3 (213.215.42.69).Pire, lorsque je fais un
ping sur 213.215.42.70, je vois eth3 me répondre (alors qu'en toute
logique, eth0 devrait répondre) _même si_ (et j'insiste sur le même
si) eth0 est down !
213.215.42.70, c'est X.Y.Z.70 ?
Oui ;-)Toute remarque sera la bienvenue, parce que là, il y a un truc que
je ne comprends pas.
C'est tout simple. Pour le routage de Linux, les adresses locales
n'appartiennent pas spécifiquement à une interface particulière mais
globalement à la machine elle-même.
Pour le trafic entrant, par défaut les deux interfaces répondent aux
requêtes ARP pour n'importe quelle adresse locale. L'émetteur de la
requête ARP utilisera l'adresse MAC de la première réponse reçue. En
gros la plus rapide gagne. Il y a quelques paramètres dans
/proc/sys/net/ipv4/*/conf/ permettant de modifier ce comportement.
Quant au fait que le trafic sorte toujours par eth3, tu vois que tu as
deux routes contradictoires vers X.Y.Z.64/28. Une seule est utilisée, en
pratique la dernière créée. Quant aux destinations extérieures, tu vois
que la route par défaut passe explicitement par eth3, donc rien d'anormal.
Et doc ? Je ne vois pas trop comment débrouiller le truc :-(
Le 06-10-2007, à propos de
Re: [Linux] Deux interfaces sur le même LAN,
Pascal Hambourg écrivait dans fr.comp.reseaux.ip :
Salut,
[...]
Mon serveur frontal possède deux interfaces Ethernet/IP vers le
réseau Internet avec les adresse X.Y.Z.69(eth3) et X.Y.Z.70(eth0)
Y a-t-il une raison particulière d'avoir deux interfaces connectées au
même LAN ? Si c'est pour la bande passante ou la redondance, il vaudrait
mieux faire de l'aggrégation de liens.
Il y a une raison particulière qui n'est pas de la redondance :
sur eth0 je fais de la QoS poussée pour les clusters alors que eth3
est une interface d'administration.
eth3 est une interface d'administration (X.Y.Z.69/28).
eth0 possède l'adresse X.Y.Z.70/28
Les routes par défaut sont :
Root gershwin:[~] > route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
X.Y.Z.64 * 255.255.255.240 U 0 0 0 eth3
X.Y.Z.64 * 255.255.255.240 U 0 0 0 eth0
localnet * 255.255.255.0 U 0 0 0 eth2
heartbeat * 255.255.255.0 U 0 0 0 eth1
default purcell.systell 0.0.0.0 UG 0 0 0 eth3
Un truc me chagrine : que je fasse un ssh sur X.Y.Z.69 ou X.Y.Z.70,
à chaque fois, je me retrouve sur eth3.
Comment ça, "sur eth3" ? Tu veux dire que le trafic entre toujours par
eth3 ?
Oui. Un tcpdump me montre que 213.215.42.69 et 70 tapent _toujours_
sur eth3 (213.215.42.69).
Pire, lorsque je fais un
ping sur 213.215.42.70, je vois eth3 me répondre (alors qu'en toute
logique, eth0 devrait répondre) _même si_ (et j'insiste sur le même
si) eth0 est down !
213.215.42.70, c'est X.Y.Z.70 ?
Oui ;-)
Toute remarque sera la bienvenue, parce que là, il y a un truc que
je ne comprends pas.
C'est tout simple. Pour le routage de Linux, les adresses locales
n'appartiennent pas spécifiquement à une interface particulière mais
globalement à la machine elle-même.
Pour le trafic entrant, par défaut les deux interfaces répondent aux
requêtes ARP pour n'importe quelle adresse locale. L'émetteur de la
requête ARP utilisera l'adresse MAC de la première réponse reçue. En
gros la plus rapide gagne. Il y a quelques paramètres dans
/proc/sys/net/ipv4/*/conf/ permettant de modifier ce comportement.
Quant au fait que le trafic sorte toujours par eth3, tu vois que tu as
deux routes contradictoires vers X.Y.Z.64/28. Une seule est utilisée, en
pratique la dernière créée. Quant aux destinations extérieures, tu vois
que la route par défaut passe explicitement par eth3, donc rien d'anormal.
Et doc ? Je ne vois pas trop comment débrouiller le truc :-(
Le 06-10-2007, à propos de
Re: [Linux] Deux interfaces sur le même LAN,
Pascal Hambourg écrivait dans fr.comp.reseaux.ip :Salut,
[...]Mon serveur frontal possède deux interfaces Ethernet/IP vers le
réseau Internet avec les adresse X.Y.Z.69(eth3) et X.Y.Z.70(eth0)
Y a-t-il une raison particulière d'avoir deux interfaces connectées au
même LAN ? Si c'est pour la bande passante ou la redondance, il vaudrait
mieux faire de l'aggrégation de liens.
Il y a une raison particulière qui n'est pas de la redondance :
sur eth0 je fais de la QoS poussée pour les clusters alors que eth3
est une interface d'administration.eth3 est une interface d'administration (X.Y.Z.69/28).
eth0 possède l'adresse X.Y.Z.70/28
Les routes par défaut sont :
Root gershwin:[~] > route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
X.Y.Z.64 * 255.255.255.240 U 0 0 0 eth3
X.Y.Z.64 * 255.255.255.240 U 0 0 0 eth0
localnet * 255.255.255.0 U 0 0 0 eth2
heartbeat * 255.255.255.0 U 0 0 0 eth1
default purcell.systell 0.0.0.0 UG 0 0 0 eth3
Un truc me chagrine : que je fasse un ssh sur X.Y.Z.69 ou X.Y.Z.70,
à chaque fois, je me retrouve sur eth3.
Comment ça, "sur eth3" ? Tu veux dire que le trafic entre toujours par
eth3 ?
Oui. Un tcpdump me montre que 213.215.42.69 et 70 tapent _toujours_
sur eth3 (213.215.42.69).Pire, lorsque je fais un
ping sur 213.215.42.70, je vois eth3 me répondre (alors qu'en toute
logique, eth0 devrait répondre) _même si_ (et j'insiste sur le même
si) eth0 est down !
213.215.42.70, c'est X.Y.Z.70 ?
Oui ;-)Toute remarque sera la bienvenue, parce que là, il y a un truc que
je ne comprends pas.
C'est tout simple. Pour le routage de Linux, les adresses locales
n'appartiennent pas spécifiquement à une interface particulière mais
globalement à la machine elle-même.
Pour le trafic entrant, par défaut les deux interfaces répondent aux
requêtes ARP pour n'importe quelle adresse locale. L'émetteur de la
requête ARP utilisera l'adresse MAC de la première réponse reçue. En
gros la plus rapide gagne. Il y a quelques paramètres dans
/proc/sys/net/ipv4/*/conf/ permettant de modifier ce comportement.
Quant au fait que le trafic sorte toujours par eth3, tu vois que tu as
deux routes contradictoires vers X.Y.Z.64/28. Une seule est utilisée, en
pratique la dernière créée. Quant aux destinations extérieures, tu vois
que la route par défaut passe explicitement par eth3, donc rien d'anormal.
Et doc ? Je ne vois pas trop comment débrouiller le truc :-(
Et doc ? Je ne vois pas trop comment débrouiller le truc :-(
Je voulais dire "et donc" ? Les routes sortantes sont gérées par
iproute2 avec un fwmark bien positionné, donc je pense que cela doit
aller.
Maintenant, je ne vois pas comment bricoler dans les options ipv4
pour obtenir ce que je veux (d'autant plus que je n'arrive pas à
trouver de la doc sur le sujet...).
Et doc ? Je ne vois pas trop comment débrouiller le truc :-(
Je voulais dire "et donc" ? Les routes sortantes sont gérées par
iproute2 avec un fwmark bien positionné, donc je pense que cela doit
aller.
Maintenant, je ne vois pas comment bricoler dans les options ipv4
pour obtenir ce que je veux (d'autant plus que je n'arrive pas à
trouver de la doc sur le sujet...).
Et doc ? Je ne vois pas trop comment débrouiller le truc :-(
Je voulais dire "et donc" ? Les routes sortantes sont gérées par
iproute2 avec un fwmark bien positionné, donc je pense que cela doit
aller.
Maintenant, je ne vois pas comment bricoler dans les options ipv4
pour obtenir ce que je veux (d'autant plus que je n'arrive pas à
trouver de la doc sur le sujet...).
Et doc ? Je ne vois pas trop comment débrouiller le truc :-(
Tu veux quoi exactement ? J'ai bien une petite idée, mais je préfère te
laisser l'exprimer.
Je voulais dire "et donc" ? Les routes sortantes sont gérées par
iproute2 avec un fwmark bien positionné, donc je pense que cela doit
aller.
Ah, si en plus tu nous caches des choses... Envoie !
Maintenant, je ne vois pas comment bricoler dans les options ipv4
pour obtenir ce que je veux (d'autant plus que je n'arrive pas à
trouver de la doc sur le sujet...).
Voir la première question.
Et doc ? Je ne vois pas trop comment débrouiller le truc :-(
Tu veux quoi exactement ? J'ai bien une petite idée, mais je préfère te
laisser l'exprimer.
Je voulais dire "et donc" ? Les routes sortantes sont gérées par
iproute2 avec un fwmark bien positionné, donc je pense que cela doit
aller.
Ah, si en plus tu nous caches des choses... Envoie !
Maintenant, je ne vois pas comment bricoler dans les options ipv4
pour obtenir ce que je veux (d'autant plus que je n'arrive pas à
trouver de la doc sur le sujet...).
Voir la première question.
Et doc ? Je ne vois pas trop comment débrouiller le truc :-(
Tu veux quoi exactement ? J'ai bien une petite idée, mais je préfère te
laisser l'exprimer.
Je voulais dire "et donc" ? Les routes sortantes sont gérées par
iproute2 avec un fwmark bien positionné, donc je pense que cela doit
aller.
Ah, si en plus tu nous caches des choses... Envoie !
Maintenant, je ne vois pas comment bricoler dans les options ipv4
pour obtenir ce que je veux (d'autant plus que je n'arrive pas à
trouver de la doc sur le sujet...).
Voir la première question.
Le 06-10-2007, à propos de
Re: [Linux] Deux interfaces sur le même LAN,
Pascal Hambourg écrivait dans fr.comp.reseaux.ip :Et doc ? Je ne vois pas trop comment débrouiller le truc :-(
Tu veux quoi exactement ? J'ai bien une petite idée, mais je préfère te
laisser l'exprimer.
eth3 (213.215.42.69) pour le trafic à destination de mon serveur frontal
(donc ssh, dns, tous ces trucs...).
eth0 (213.215.42.70) et ses alias pour le trafix à destination des
clusters, le serveur frontal ne faisant que du NAT à destination de ces
clusters et de la QoS (limitation de trafic en fonction des ports et des
adresses).
Root gershwin:[/etc/iproute2] > echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter
Root gershwin:[/etc/iproute2] > ip route show
213.215.42.64/28 dev eth0 proto kernel scope link src 213.215.42.70
213.215.42.64/28 dev eth3 proto kernel scope link src 213.215.42.69
192.168.1.0/24 dev eth2 proto kernel scope link src 192.168.1.254
192.168.0.0/24 dev eth1 proto kernel scope link src 192.168.0.1
default via 213.215.42.65 dev eth3
Root gershwin:[/etc/iproute2] > ip rule show
0: from all lookup local
101: from 213.215.42.70 lookup public_traffic
102: from all fwmark 0x1 lookup public_traffic
32766: from all lookup main
32767: from all lookup default
Le 06-10-2007, à propos de
Re: [Linux] Deux interfaces sur le même LAN,
Pascal Hambourg écrivait dans fr.comp.reseaux.ip :
Et doc ? Je ne vois pas trop comment débrouiller le truc :-(
Tu veux quoi exactement ? J'ai bien une petite idée, mais je préfère te
laisser l'exprimer.
eth3 (213.215.42.69) pour le trafic à destination de mon serveur frontal
(donc ssh, dns, tous ces trucs...).
eth0 (213.215.42.70) et ses alias pour le trafix à destination des
clusters, le serveur frontal ne faisant que du NAT à destination de ces
clusters et de la QoS (limitation de trafic en fonction des ports et des
adresses).
Root gershwin:[/etc/iproute2] > echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter
Root gershwin:[/etc/iproute2] > ip route show
213.215.42.64/28 dev eth0 proto kernel scope link src 213.215.42.70
213.215.42.64/28 dev eth3 proto kernel scope link src 213.215.42.69
192.168.1.0/24 dev eth2 proto kernel scope link src 192.168.1.254
192.168.0.0/24 dev eth1 proto kernel scope link src 192.168.0.1
default via 213.215.42.65 dev eth3
Root gershwin:[/etc/iproute2] > ip rule show
0: from all lookup local
101: from 213.215.42.70 lookup public_traffic
102: from all fwmark 0x1 lookup public_traffic
32766: from all lookup main
32767: from all lookup default
Le 06-10-2007, à propos de
Re: [Linux] Deux interfaces sur le même LAN,
Pascal Hambourg écrivait dans fr.comp.reseaux.ip :Et doc ? Je ne vois pas trop comment débrouiller le truc :-(
Tu veux quoi exactement ? J'ai bien une petite idée, mais je préfère te
laisser l'exprimer.
eth3 (213.215.42.69) pour le trafic à destination de mon serveur frontal
(donc ssh, dns, tous ces trucs...).
eth0 (213.215.42.70) et ses alias pour le trafix à destination des
clusters, le serveur frontal ne faisant que du NAT à destination de ces
clusters et de la QoS (limitation de trafic en fonction des ports et des
adresses).
Root gershwin:[/etc/iproute2] > echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter
Root gershwin:[/etc/iproute2] > ip route show
213.215.42.64/28 dev eth0 proto kernel scope link src 213.215.42.70
213.215.42.64/28 dev eth3 proto kernel scope link src 213.215.42.69
192.168.1.0/24 dev eth2 proto kernel scope link src 192.168.1.254
192.168.0.0/24 dev eth1 proto kernel scope link src 192.168.0.1
default via 213.215.42.65 dev eth3
Root gershwin:[/etc/iproute2] > ip rule show
0: from all lookup local
101: from 213.215.42.70 lookup public_traffic
102: from all fwmark 0x1 lookup public_traffic
32766: from all lookup main
32767: from all lookup default
Le 06-10-2007, à propos de
Re: [Linux] Deux interfaces sur le même LAN,
Pascal Hambourg écrivait dans fr.comp.reseaux.ip :Et doc ? Je ne vois pas trop comment débrouiller le truc :-(
Tu veux quoi exactement ? J'ai bien une petite idée, mais je préfère te
laisser l'exprimer.
eth3 (213.215.42.69) pour le trafic à destination de mon serveur frontal
(donc ssh, dns, tous ces trucs...).
eth0 (213.215.42.70) et ses alias pour le trafix à destination des
clusters, le serveur frontal ne faisant que du NAT à destination de ces
clusters et de la QoS (limitation de trafic en fonction des ports et des
adresses).
Si je reformule,
1) Trafic reçu :
- destiné à 213.215.42.70 -> doit être reçu sur eth0
- destiné à 213.215.42.69 -> doit être reçu sur eth3
2) Trafic émis :
- source 213.215.42.70 -> doit être émis sur eth0
- source 213.215.42.69 -> doit être émis sur eth3
J'ai bon ?
Root gershwin:[/etc/iproute2] > echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter
La précaution classique.Root gershwin:[/etc/iproute2] > ip route show
213.215.42.64/28 dev eth0 proto kernel scope link src 213.215.42.70
213.215.42.64/28 dev eth3 proto kernel scope link src 213.215.42.69
192.168.1.0/24 dev eth2 proto kernel scope link src 192.168.1.254
192.168.0.0/24 dev eth1 proto kernel scope link src 192.168.0.1
default via 213.215.42.65 dev eth3
Ça ne montre que le contenu de la table 'main', que tu avais déjà fourni
avec le résultat de la commande 'route'.Root gershwin:[/etc/iproute2] > ip rule show
0: from all lookup local
101: from 213.215.42.70 lookup public_traffic
102: from all fwmark 0x1 lookup public_traffic
32766: from all lookup main
32767: from all lookup default
Le contenu de la table 'public_traffic' aurait été bienvenu. Je suppose
que son but est d'envoyer par eth0. Que signifie la marque 0x1 ? Elle
marque les paquets provenant des clusters ?
Pour le 1), il faut regarder du côté du paramètre du noyau
/proc/sys/net/ipv4/conf/*/arp_ignore pour faire en sorte que seule
l'interface ayant l'adresse demandée réponde aux requêtes ARP. La valeur
1 devrait convenir. La description se trouve dans le fichier
networking/ip-sysctl.txt de la documentation du noyau, elle-même située
dans le répertoire Documentation/ des sources du noyau.
Pour le 2), je suppose que les règles 101 et 102 devraient se charger
d'envoyer sur eth0 ce qui doit l'être, mais j'ai besoin d'en savoir plus
sur ton routage avancé.
Le 06-10-2007, à propos de
Re: [Linux] Deux interfaces sur le même LAN,
Pascal Hambourg écrivait dans fr.comp.reseaux.ip :
Et doc ? Je ne vois pas trop comment débrouiller le truc :-(
Tu veux quoi exactement ? J'ai bien une petite idée, mais je préfère te
laisser l'exprimer.
eth3 (213.215.42.69) pour le trafic à destination de mon serveur frontal
(donc ssh, dns, tous ces trucs...).
eth0 (213.215.42.70) et ses alias pour le trafix à destination des
clusters, le serveur frontal ne faisant que du NAT à destination de ces
clusters et de la QoS (limitation de trafic en fonction des ports et des
adresses).
Si je reformule,
1) Trafic reçu :
- destiné à 213.215.42.70 -> doit être reçu sur eth0
- destiné à 213.215.42.69 -> doit être reçu sur eth3
2) Trafic émis :
- source 213.215.42.70 -> doit être émis sur eth0
- source 213.215.42.69 -> doit être émis sur eth3
J'ai bon ?
Root gershwin:[/etc/iproute2] > echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter
La précaution classique.
Root gershwin:[/etc/iproute2] > ip route show
213.215.42.64/28 dev eth0 proto kernel scope link src 213.215.42.70
213.215.42.64/28 dev eth3 proto kernel scope link src 213.215.42.69
192.168.1.0/24 dev eth2 proto kernel scope link src 192.168.1.254
192.168.0.0/24 dev eth1 proto kernel scope link src 192.168.0.1
default via 213.215.42.65 dev eth3
Ça ne montre que le contenu de la table 'main', que tu avais déjà fourni
avec le résultat de la commande 'route'.
Root gershwin:[/etc/iproute2] > ip rule show
0: from all lookup local
101: from 213.215.42.70 lookup public_traffic
102: from all fwmark 0x1 lookup public_traffic
32766: from all lookup main
32767: from all lookup default
Le contenu de la table 'public_traffic' aurait été bienvenu. Je suppose
que son but est d'envoyer par eth0. Que signifie la marque 0x1 ? Elle
marque les paquets provenant des clusters ?
Pour le 1), il faut regarder du côté du paramètre du noyau
/proc/sys/net/ipv4/conf/*/arp_ignore pour faire en sorte que seule
l'interface ayant l'adresse demandée réponde aux requêtes ARP. La valeur
1 devrait convenir. La description se trouve dans le fichier
networking/ip-sysctl.txt de la documentation du noyau, elle-même située
dans le répertoire Documentation/ des sources du noyau.
Pour le 2), je suppose que les règles 101 et 102 devraient se charger
d'envoyer sur eth0 ce qui doit l'être, mais j'ai besoin d'en savoir plus
sur ton routage avancé.
Le 06-10-2007, à propos de
Re: [Linux] Deux interfaces sur le même LAN,
Pascal Hambourg écrivait dans fr.comp.reseaux.ip :Et doc ? Je ne vois pas trop comment débrouiller le truc :-(
Tu veux quoi exactement ? J'ai bien une petite idée, mais je préfère te
laisser l'exprimer.
eth3 (213.215.42.69) pour le trafic à destination de mon serveur frontal
(donc ssh, dns, tous ces trucs...).
eth0 (213.215.42.70) et ses alias pour le trafix à destination des
clusters, le serveur frontal ne faisant que du NAT à destination de ces
clusters et de la QoS (limitation de trafic en fonction des ports et des
adresses).
Si je reformule,
1) Trafic reçu :
- destiné à 213.215.42.70 -> doit être reçu sur eth0
- destiné à 213.215.42.69 -> doit être reçu sur eth3
2) Trafic émis :
- source 213.215.42.70 -> doit être émis sur eth0
- source 213.215.42.69 -> doit être émis sur eth3
J'ai bon ?
Root gershwin:[/etc/iproute2] > echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter
La précaution classique.Root gershwin:[/etc/iproute2] > ip route show
213.215.42.64/28 dev eth0 proto kernel scope link src 213.215.42.70
213.215.42.64/28 dev eth3 proto kernel scope link src 213.215.42.69
192.168.1.0/24 dev eth2 proto kernel scope link src 192.168.1.254
192.168.0.0/24 dev eth1 proto kernel scope link src 192.168.0.1
default via 213.215.42.65 dev eth3
Ça ne montre que le contenu de la table 'main', que tu avais déjà fourni
avec le résultat de la commande 'route'.Root gershwin:[/etc/iproute2] > ip rule show
0: from all lookup local
101: from 213.215.42.70 lookup public_traffic
102: from all fwmark 0x1 lookup public_traffic
32766: from all lookup main
32767: from all lookup default
Le contenu de la table 'public_traffic' aurait été bienvenu. Je suppose
que son but est d'envoyer par eth0. Que signifie la marque 0x1 ? Elle
marque les paquets provenant des clusters ?
Pour le 1), il faut regarder du côté du paramètre du noyau
/proc/sys/net/ipv4/conf/*/arp_ignore pour faire en sorte que seule
l'interface ayant l'adresse demandée réponde aux requêtes ARP. La valeur
1 devrait convenir. La description se trouve dans le fichier
networking/ip-sysctl.txt de la documentation du noyau, elle-même située
dans le répertoire Documentation/ des sources du noyau.
Pour le 2), je suppose que les règles 101 et 102 devraient se charger
d'envoyer sur eth0 ce qui doit l'être, mais j'ai besoin d'en savoir plus
sur ton routage avancé.
public_traffic est une table ayant par défaut une route passant par
eth0 (passerelle 213.215.42.65). La marque 0x1 est posée par une
règle ipfilter (ce qui provient de mes clusters par eth2 et qui
n'est pas à destination de la machine frontale est marqué).
Comment obtenir la table public_traffic ?
Par ailleurs, tant que je suis ici ;-) Existe-t-il un moyen de
router un paquet local sur une route qui n'est pas une route par
défaut ? Par exemple router les paquets générés _localement_ sur
eth3 (route par défaut) sauf le smtp (par exemple sur eth0) ?
J'arrive sans problème à router comme je veux les paquets qui
transitent par mes machines, mais pas ceux qui sont générés
localement (j'ai même essayé la ciblre ROUTE sans trop de
succès...)...
public_traffic est une table ayant par défaut une route passant par
eth0 (passerelle 213.215.42.65). La marque 0x1 est posée par une
règle ipfilter (ce qui provient de mes clusters par eth2 et qui
n'est pas à destination de la machine frontale est marqué).
Comment obtenir la table public_traffic ?
Par ailleurs, tant que je suis ici ;-) Existe-t-il un moyen de
router un paquet local sur une route qui n'est pas une route par
défaut ? Par exemple router les paquets générés _localement_ sur
eth3 (route par défaut) sauf le smtp (par exemple sur eth0) ?
J'arrive sans problème à router comme je veux les paquets qui
transitent par mes machines, mais pas ceux qui sont générés
localement (j'ai même essayé la ciblre ROUTE sans trop de
succès...)...
public_traffic est une table ayant par défaut une route passant par
eth0 (passerelle 213.215.42.65). La marque 0x1 est posée par une
règle ipfilter (ce qui provient de mes clusters par eth2 et qui
n'est pas à destination de la machine frontale est marqué).
Comment obtenir la table public_traffic ?
Par ailleurs, tant que je suis ici ;-) Existe-t-il un moyen de
router un paquet local sur une route qui n'est pas une route par
défaut ? Par exemple router les paquets générés _localement_ sur
eth3 (route par défaut) sauf le smtp (par exemple sur eth0) ?
J'arrive sans problème à router comme je veux les paquets qui
transitent par mes machines, mais pas ceux qui sont générés
localement (j'ai même essayé la ciblre ROUTE sans trop de
succès...)...
public_traffic est une table ayant par défaut une route passant par
eth0 (passerelle 213.215.42.65). La marque 0x1 est posée par une
règle ipfilter (ce qui provient de mes clusters par eth2 et qui
n'est pas à destination de la machine frontale est marqué).
Je ne pense pas qu'il soit nécessaire de faire la distinction puisque la
table de routage 'local', qui contient les destinations locales à la
machine et broadcast, a priorité sur les règles de routage avancé.
Comment obtenir la table public_traffic ?
$ ip route show table public_traffic
Par ailleurs, tant que je suis ici ;-) Existe-t-il un moyen de
router un paquet local sur une route qui n'est pas une route par
défaut ? Par exemple router les paquets générés _localement_ sur
eth3 (route par défaut) sauf le smtp (par exemple sur eth0) ?
J'arrive sans problème à router comme je veux les paquets qui
transitent par mes machines, mais pas ceux qui sont générés
localement (j'ai même essayé la ciblre ROUTE sans trop de
succès...)...
ROUTE c'est moche, tous ceux qui ne l'utilisent pas te le diront. :-p
Les règles de routage (ip rule...) s'appliquent aussi aux paquets émis
localement. Par contre le marquage avec la cible iptables MARK ou
CONNMARK doit être fait dans la chaîne OUTPUT puisque c'est par là et
non par la chaîne PREROUTING que passent ces paquets.
public_traffic est une table ayant par défaut une route passant par
eth0 (passerelle 213.215.42.65). La marque 0x1 est posée par une
règle ipfilter (ce qui provient de mes clusters par eth2 et qui
n'est pas à destination de la machine frontale est marqué).
Je ne pense pas qu'il soit nécessaire de faire la distinction puisque la
table de routage 'local', qui contient les destinations locales à la
machine et broadcast, a priorité sur les règles de routage avancé.
Comment obtenir la table public_traffic ?
$ ip route show table public_traffic
Par ailleurs, tant que je suis ici ;-) Existe-t-il un moyen de
router un paquet local sur une route qui n'est pas une route par
défaut ? Par exemple router les paquets générés _localement_ sur
eth3 (route par défaut) sauf le smtp (par exemple sur eth0) ?
J'arrive sans problème à router comme je veux les paquets qui
transitent par mes machines, mais pas ceux qui sont générés
localement (j'ai même essayé la ciblre ROUTE sans trop de
succès...)...
ROUTE c'est moche, tous ceux qui ne l'utilisent pas te le diront. :-p
Les règles de routage (ip rule...) s'appliquent aussi aux paquets émis
localement. Par contre le marquage avec la cible iptables MARK ou
CONNMARK doit être fait dans la chaîne OUTPUT puisque c'est par là et
non par la chaîne PREROUTING que passent ces paquets.
public_traffic est une table ayant par défaut une route passant par
eth0 (passerelle 213.215.42.65). La marque 0x1 est posée par une
règle ipfilter (ce qui provient de mes clusters par eth2 et qui
n'est pas à destination de la machine frontale est marqué).
Je ne pense pas qu'il soit nécessaire de faire la distinction puisque la
table de routage 'local', qui contient les destinations locales à la
machine et broadcast, a priorité sur les règles de routage avancé.
Comment obtenir la table public_traffic ?
$ ip route show table public_traffic
Par ailleurs, tant que je suis ici ;-) Existe-t-il un moyen de
router un paquet local sur une route qui n'est pas une route par
défaut ? Par exemple router les paquets générés _localement_ sur
eth3 (route par défaut) sauf le smtp (par exemple sur eth0) ?
J'arrive sans problème à router comme je veux les paquets qui
transitent par mes machines, mais pas ceux qui sont générés
localement (j'ai même essayé la ciblre ROUTE sans trop de
succès...)...
ROUTE c'est moche, tous ceux qui ne l'utilisent pas te le diront. :-p
Les règles de routage (ip rule...) s'appliquent aussi aux paquets émis
localement. Par contre le marquage avec la cible iptables MARK ou
CONNMARK doit être fait dans la chaîne OUTPUT puisque c'est par là et
non par la chaîne PREROUTING que passent ces paquets.