J'ai trouvé comment faire pour que ce soit l'adresse de l'interface virtuelle qui soit utilisé comme adresse source sur la réponse.
Dans le fichier snmpd.conf, au lieu de mettre simplement les ports en écoute:
agentaddress udp:53,161
, il faut mettre en clair les adresses ip des interfaces virtuelles et les ports en écoute, comme suivant:
agentaddress 192.168.1.2:53,192.168.1.3:53 etc...
avec eth0 à 192.168.1.2 et eth0:0 à 192.168.1.3.
Le problème c'est que cette solution est limité, je ne peux pas écouter sur toutes les adresses IP du subnet et donc sur toutes mes interfaces virtuelles car il semble avoir une limite.
Comment fait on pour faire pour repousser cette limite ou pour l'annuler?
Merci d'avance.
C'est bizard, le man de snmpd ne semble pas indiquer de façon simple pour le binder directement sur une interface, il faut donc faire autrement.
Tes interfaces virtuelles ont des ips qui appartiennent au même sous reseau ??
Oui, elles appartiennent au même subnet.
Dans ce cas par défault, le noyau choisis la route la plus courte pour répondre à la requette snmp, comme toutes les routes ont le même poids (route -n, puis regarder la colone 'Metric'), il prend la première qui vient ce qui correspond dans ton cas à l'interface principale.
Il n'ya qu'une route puisqu'elles appartiennent au même subnet et je ne vois pas comment les routes influent sur l'adresse IP source.
Pour résoudre ton problème, il faut mettre en place une solution de load balancing [1]. Ca te permet de répartir la charge sur les différents liens. En cherchant avec google, j'ai trouvé pen [2] qui permet de faire du load balancing basé sur la couche applicative (il y a peut etre d'autres solutions).
Voila un peu le contexte, en fait je réalise un outils automatiques de test de configuration de firewall. Or j'utilise le démon snmpd pour répondre à des requêtes UDP. Je suis parti de ftester qui est codé en perl, or dans ce code pour tester tcp, j'utilse la fonction send() du module Net::RawIP qui ne permet d'inspecter que la table principale donc les solutions à la iproute2 ne sont pas possibles.
Et franchement, je ne vois pas trés bien ce que le load balancing peu m'apporté.....?????
[^] # Re: Tete a queue
Posté par jokobbb . En réponse au message limite du nombre d'interface à l'écoute snmpd. Évalué à 1.
[^] # Une première solution mais limité.....
Posté par jokobbb . En réponse au message snmpd et interfaces virtuelles. Évalué à 1.
Dans le fichier snmpd.conf, au lieu de mettre simplement les ports en écoute:
agentaddress udp:53,161
, il faut mettre en clair les adresses ip des interfaces virtuelles et les ports en écoute, comme suivant:
agentaddress 192.168.1.2:53,192.168.1.3:53 etc...
avec eth0 à 192.168.1.2 et eth0:0 à 192.168.1.3.
Le problème c'est que cette solution est limité, je ne peux pas écouter sur toutes les adresses IP du subnet et donc sur toutes mes interfaces virtuelles car il semble avoir une limite.
Comment fait on pour faire pour repousser cette limite ou pour l'annuler?
Merci d'avance.
[^] # Re: Plus de détails
Posté par jokobbb . En réponse au message snmpd et interfaces virtuelles. Évalué à 1.
Tes interfaces virtuelles ont des ips qui appartiennent au même sous reseau ??
Oui, elles appartiennent au même subnet.
Dans ce cas par défault, le noyau choisis la route la plus courte pour répondre à la requette snmp, comme toutes les routes ont le même poids (route -n, puis regarder la colone 'Metric'), il prend la première qui vient ce qui correspond dans ton cas à l'interface principale.
Il n'ya qu'une route puisqu'elles appartiennent au même subnet et je ne vois pas comment les routes influent sur l'adresse IP source.
Pour résoudre ton problème, il faut mettre en place une solution de load balancing [1]. Ca te permet de répartir la charge sur les différents liens. En cherchant avec google, j'ai trouvé pen [2] qui permet de faire du load balancing basé sur la couche applicative (il y a peut etre d'autres solutions).
Voila un peu le contexte, en fait je réalise un outils automatiques de test de configuration de firewall. Or j'utilise le démon snmpd pour répondre à des requêtes UDP. Je suis parti de ftester qui est codé en perl, or dans ce code pour tester tcp, j'utilse la fonction send() du module Net::RawIP qui ne permet d'inspecter que la table principale donc les solutions à la iproute2 ne sont pas possibles.
Et franchement, je ne vois pas trés bien ce que le load balancing peu m'apporté.....?????