 |
||
| ||
| |||||
| Dernière réponse | |
|---|---|
| Sujet : [doc/info] Broadcast | |
| trictrac | en pratique, oui, mais en theorie, pas forcement ;)
Mais bon, j'en ai pas besoin moi. |
| Aperçu |
|---|
| Vue Rapide de la discussion |
|---|
| trictrac | en pratique, oui, mais en theorie, pas forcement ;)
Mais bon, j'en ai pas besoin moi. |
| Xavier_35 | Bah le routeur il s'en fout il les garde plus longtems dans son cache, c'est windows qui les garde trois minutes, et pis normalement y'a de l'activité toutes les trois minutes quand même ! Nan ? |
| trictrac | et si, pdt +de 3 min, le pc a pas d'activité réseau, hein?? :p
(je sais, je chipote a mort la .. mais RARP intervient pas dans le cas present ;) ) |
| Xavier_35 | Tu consulte le cache ARP de ton routeur (ou de ton switch) |
| trictrac | oki, mais sur un reseau normal. Pas de serveur, pas de trucs comme ca. Un reseau tout simple.
Si je connais l'adresse mac d'un poste, est-ce que je peux en connaitre son ip? comment on fait concretement ? |
| kR0M | et à ton avis RARP c'est quoi ?
exactement ce que t'as dit que c'était pas possible : avoir une IP à partir de l'adresse MAC ne me réponds pas que c'est pas possible, c'est marqué en noir sur blanc : RARP requires one or more server hosts to maintain a database of mappings from hardware address to protocol address. tu m'expliques l'intérêt d'avoir un serveur qui fait la correspondance entre MAC<=>IP si c'est pour qu'on puisse pas l'utiliser ? C'est justement le sujet de ce topic, le broadcast est utilisé de façon à ce que la station qui connait pas son IP puisse en avoir une. Evidemment, cette communication n'utilise pas le protocole IP, mais ARP ! ce qui fait que la carte réseau qui souhaite connaitre son IP n'a pas besoin d'IP pour communiquer !!! |
| trictrac | Ah bah voila, je savais bien qu'on pouvait pas trouver l'IP a partir de la MAC ;)
com21:"ça a été demandé plusieurs fois et ya tjrs eu réponses à ses demandes..." si la reponse c'est RARP, elle etait donc fausse ;) |
| FLo14 | Voici ce que dit la RFC 103:
Status of this Memo This RFC suggests a method for workstations to dynamically find their protocol address (e.g., their Internet Address), when they know only their hardware address (e.g., their attached physical network address). This RFC specifies a proposed protocol for the ARPA Internet community, and requests discussion and suggestions for improvements. I. Introduction Network hosts such as diskless workstations frequently do not know their protocol addresses when booted; they often know only their hardware interface addresses. To communicate using higher-level protocols like IP, they must discover their protocol address from some external source. Our problem is that there is no standard mechanism for doing so. Plummer's "Address Resolution Protocol" (ARP) [1] is designed to solve a complementary problem, resolving a host's hardware address given its protocol address. This RFC proposes a "Reverse Address Resolution Protocol" (RARP). As with ARP, we assume a broadcast medium, such as Ethernet. II. Design Considerations The following considerations guided our design of the RARP protocol. A. ARP and RARP are different operations. ARP assumes that every host knows the mapping between its own hardware address and protocol address(es). Information gathered about other hosts is accumulated in a small cache. All hosts are equal in status; there is no distinction between clients and servers. On the other hand, RARP requires one or more server hosts to maintain a database of mappings from hardware address to protocol address and respond to requests from client hosts |
| FLo14 |
|
| Kernel-Panic | Tu fais bien, pcq tu peux pas le prouvé, vu que c'est impossible ;) |
| kR0M | c'est pas mon but dans la vie de te prouver qu'un paquet de broadcast peut être routé
je l'ai vu arriver, un point c'est tout... |
| Kernel-Panic |
|
| Xavier_35 |
|
| trictrac | bah justement, nopn ...
le broadcast c'est xx.xx.255.255 .. et ca ne correspond a aucune regle de routage ca. Donc ca ne 'devrait' pas pouvoir etre routé. J'ai essayé sur des cisco que j'ai sous la main la, et je ne vois pas comment c'est possible, le routeur sachant que ce genre de paquet ne doit pas etre forwardé. |
| kR0M |
|
| FLo14 |
|
| Kernel-Panic | Je sais pas ou ta vu ton routeur magique, mais une addresse de bcast n'est pas routable... en aucun cas. le seul moyen de passé un bcast a travers un routeur c'est avec un agent de relai (l'éméteur et le récepteur doivent connaitre leur IP respectif). Tu t'ai jaimais pauser la question a savoir pourquoi il faut un server dhcp (ou un relais dhcp) apres chaque routeur ? si une addresse peu etre router par erreur, et dois forcement pouvoir est routable sans erreur.
et sois dit en passant, les Switchs utilise les bcast quand quand un hôte est incunnu a sa table de routage (d'addresse physique) |
| kR0M | c'est pas une question de niveau ou je ne sais quoi
c'est une question de table de routage qui fait que tu peux arriver à propager un broadcast au reste de ton réseau. Je pense qu'un switch "intelligent" saura éviter ça, mais un routeur peut se planter si tu le forces correctement. |
| Xavier_35 |
|
| trictrac |
|
| tomtom41 | question : les switchs de niveaux 3 laissent passer le broadcast ou pas ? |
| com21 | cache de 3 minutes si mes souvenirs sont bon |
| Kernel-Panic |
|
| com21 |
|
| kR0M | évidemment Windows a un cache ARP, mais pour le consulter aucune idée...
sinon toi t'aimes bien chipoter, oui l'opération inverse c'est Reverse ARP mais le protocole reste le meme ! c'était des exemples d'utilisation du broadcast à la base... et pour en revenir au routeur qui route un broadcast, si si je peux te jurer que ça peut arriver, je l'ai vu, une table de routage mal renseignée et le routeur route un broadcast sur les adresses broadcast de ses autres interfaces. (network de l'univ rules) Je précise que c'est pas moi qui ai fait ça, on m'a juste raconté le coup et j'ai pu constater le b****l que ça a mis. |
| trictrac | bon a savoir ca .. ca a été demandé deja plusieur fois sans reponse ici meme.
Merci bien, ca peut toujours servir |
| Xavier_35 |
|
| trictrac | +1 pour la reponse de xav, un routeur mal configuré ne routera pas le broadcast, vu que le broadcast est non routable.
De plus, une precision demandée: "Quand une machine veut connaître l'adresse IP d'une autre machine dont elle ne connait que l'adresse MAC, elle fait un broadcast et seule la machine qui a l'adresse MAC en question répond, en donnant ainsi son IP. Ça marche aussi à l'envers. " a l'envers, oui, ca marche, on est d'accord, c'est le principe du protocoel ARP Pour connaitre l'IP a partir de la mac, par contre, ca a été plusieurs fois demandé sur ce meme forum, et tu interesserais plein de monde si tu développais ... |
| Xavier_35 |
|
| kR0M | néfaste faut pas exagérer non plus
Le broadcast est utile voire indispensable à un réseau. Par exemple prenons ARP (address resolution protocol) qui est un protocole qui met en relation les adresses MAC / IP des machines du réseau. Quand une machine veut connaître l'adresse IP d'une autre machine dont elle ne connait que l'adresse MAC, elle fait un broadcast et seule la machine qui a l'adresse MAC en question répond, en donnant ainsi son IP. Ça marche aussi à l'envers. Autre application : DHCP Au départ, la machine sur le réseau ne connait pas sa config, elle n'a donc pas d'adresse IP. Elle fait un broadcast sur le réseau pour avoir sa config et seul le serveur DHCP répond. Normalement il n'y a pas de broadcast au niveau de la couche application sur un réseau. C'est réservé aux couches inférieures pour leur fonctionnement propre. D'autre part un pont/routeur ne DOIT PAS router un broadcast, ce qui ne signifie pas qu'il ne le fera pas; s'il est mal configuré ça peut se produire. Dans ce cas, un flood du réseau risque fort de se produire. Voilà pour ces compléments d'information. |
| tomtom41 | ok merci :) |
| chiendepoche | non un routeur laisse pas passer un broadcast |
| tomtom41 |
|
| trictrac | bah c'est nefaste :
ca consomme de la bande passante inutilement : un paquet est forwardé chez tout le monde. Ca consomme du cpu inutilement, car toute les interfaces reseaux remontent les paquets dans la pile IP Bref, faut eviter. C'est d'ailleur pour ca que le protocole SMB c'est de la daube avec l'agrandissement d'un reseau: tout lemonde broadcast a tout va pour s'annoncer |
| tomtom41 |
|
| trictrac | je comprend pas bien la question: impact sur le réseau : flood du réseau
application: multidiffusion sur des reseaux non-multicast, et dans des cas bien particuliers. Je vois pas quoi dire de plus, le concept est si simple: tu envoies le trafic a tout le réseau. |
| tomtom41 | :hello: Je recherche des infos sur le broadcast. J'ai fait une recherche sur le forum mais rien de bien précis. Donc j'aimerais connaitre : -> son impact sur un réseau (charge du réseau) -> ces applications merci pour votre aide :) |
