1
00:00:00,920 --> 00:00:07,730
En résumé, lorsqu'un périphérique souhaite communiquer avec un autre périphérique du même sous-réseau, il

2
00:00:07,730 --> 00:00:16,190
envoie une diffusion sur le segment local pour rechercher l'adresse MAC du périphérique à l'aide de l'adresse IP cible.

3
00:00:16,190 --> 00:00:20,080
Donc, dans ce cas, le cadre est attaché au concentrateur.

4
00:00:20,390 --> 00:00:27,290
Le concentrateur, car il s’agit d’un répéteur multi-ports, enverra le cadre de tous les ports, à l’exception du port sur lequel il

5
00:00:27,290 --> 00:00:28,060
est arrivé.

6
00:00:28,130 --> 00:00:36,560
Les cartes d'interface réseau acceptent uniquement le trafic destiné à leur adresse MAC ou acceptent

7
00:00:36,650 --> 00:00:44,150
le trafic de diffusion ainsi que le trafic de multidiffusion pour les adresses

8
00:00:44,210 --> 00:00:47,880
de multidiffusion auxquelles ils sont abonnés.

9
00:00:48,170 --> 00:00:52,480
Le routeur a une adresse MAC de g sur l’interface d’abord Ethan 00.

10
00:00:52,610 --> 00:00:59,480
Pour que le routeur reçoive la diffusion et transmette la demande aux protocoles Hialeah, le serveur Rotto

11
00:00:59,480 --> 00:01:07,850
pourra voir au moins trois qu'il s'agit d'une demande impaire pour l'adresse IP 10 1 1 2 mais la Rodda dans

12
00:01:07,850 --> 00:01:14,690
cet exemple est configurée avec les adresses IP 10 1 cent cent 10 1 à 100.

13
00:01:14,690 --> 00:01:20,990
Donc, le ratable abandonne le cadre parce que la demande ne concerne pas l'une de ses adresses IP.

14
00:01:21,260 --> 00:01:23,660
Les routeurs ne transmettent pas les émissions.

15
00:01:23,660 --> 00:01:30,710
Donc, cette diffusion n’est pas transmise en dehors de l’interface Ethan, elle est 0 1 et la diffusion reçue par

16
00:01:30,710 --> 00:01:32,170
la Rada est supprimée.

17
00:01:32,420 --> 00:01:38,990
La carte d’interface réseau sur le PCC recevra la diffusion et verra qu’il s’agit d’une demande de disponibilité pour

18
00:01:38,990 --> 00:01:40,370
son adresse IP.

19
00:01:40,370 --> 00:01:43,220
Donc, il va ensuite répondre avec une réponse op.

20
00:01:43,340 --> 00:01:50,990
Comme nous l'avons vu dans Pourquoi faut-il capturer, PCC mettra à jour son cache jusqu'à pour montrer que l'adresse IP 10

21
00:01:51,410 --> 00:01:57,530
1 1 1 est associée à l'adresse MAC payante et enverra ensuite la trame au concentrateur

22
00:01:57,530 --> 00:02:02,300
Hubble transfère le cadre de tous les ports car il s’agit d’un répéteur multi-ports.

23
00:02:02,300 --> 00:02:07,830
La route dans cet exemple recevra une trame du concentrateur, mais comme l'adresse MAC

24
00:02:07,830 --> 00:02:14,510
de destination est un et que ce n'est pas l'adresse MAC du Rato qui gâche, elle perdra la trame.

25
00:02:14,540 --> 00:02:21,380
Vous recevrez également une copie du cadre quand il recevra le cadre, il l'acceptera car l'adresse de destination

26
00:02:21,380 --> 00:02:22,180
est a.

27
00:02:22,310 --> 00:02:23,870
Et son adresse MAC est a.

28
00:02:24,020 --> 00:02:31,520
Il mettra alors à jour son cache vers le haut avec une entrée indiquant que l'adresse IP 10 1 1 2 est associée à

29
00:02:31,520 --> 00:02:32,840
l'adresse MAC C ..

30
00:02:33,020 --> 00:02:38,550
La réponse permet donc de mettre à jour sa trésorerie.

31
00:02:38,630 --> 00:02:41,900
À ce stade, aucun trafic d'utilisateur n'a été transmis.

32
00:02:42,110 --> 00:02:49,070
Ce qui s’est passé ici, c’est que les périphériques ont simplement déterminé quelles adresses MAC sont associées à

33
00:02:49,070 --> 00:02:50,560
quelles adresses IP.

34
00:02:50,690 --> 00:03:00,100
Donc, AA sait maintenant que l’adresse MAC C est associée à l’adresse IP 10 1 1 2, le trafic rose ne peut pas être

35
00:03:00,100 --> 00:03:06,760
transmis avec une source d’adresse MAC d’un qui est l’adresse MAC de destination de la machine locale

36
00:03:06,760 --> 00:03:07,550
C ..

37
00:03:07,570 --> 00:03:14,740
En d’autres termes, PCC, l’adresse MAC de destination a été apprise

38
00:03:14,760 --> 00:03:21,040
par le biais des adresses IP source ARP, et

39
00:03:21,070 --> 00:03:25,680
l’adresse IP de destination est changée.

40
00:03:25,690 --> 00:03:26,820
Il est arrivé le

41
00:03:27,010 --> 00:03:33,130
Ainsi, le routeur recevra à nouveau la trame mais l’abandonnera car son adresse MAC est G

42
00:03:33,130 --> 00:03:36,760
et l’adresse MAC de destination pour cette trame est

43
00:03:36,760 --> 00:03:43,480
Le PCC recevra également le trafic et l'acceptera car l'adresse MAC de destination est C et que ses adresses Mac locales

44
00:03:43,480 --> 00:03:48,970
voient les deux têtes en retard seront supprimées et les informations d'adresse IP seront lues par

45
00:03:49,120 --> 00:03:51,010
les protocoles de couche supérieure.

46
00:03:51,010 --> 00:03:59,950
Ceci est un paquet d'écho ICMP pour que le PC réponde avec un message de réponse d'écho C enverra la trame au concentrateur avec

47
00:03:59,950 --> 00:04:06,760
l'adresse MAC source de l'adresse MAC de destination d'un EGNOS, l'adresse MAC de l'AA en raison du message

48
00:04:06,760 --> 00:04:09,070
de demande du précédent OP.

49
00:04:09,070 --> 00:04:17,020
Donc, son cache a une adresse MAC en association avec une adresse IP source 10 1 1 1 et la trame est en

50
00:04:17,020 --> 00:04:18,100
c ..

51
00:04:18,160 --> 00:04:24,750
L'adresse MAC de destination est une adresse IP source est 10 1 1 2 l'adresse IP de destination est 10 1 1 1.

52
00:04:25,000 --> 00:04:30,430
Lorsque la trame est reçue par le concentrateur, Hubble se répète sur tous les ports, sauf celui sur lequel

53
00:04:30,430 --> 00:04:31,740
elle a été reçue.

54
00:04:31,900 --> 00:04:38,370
Le Rotto recevra la trame mais l’abandonnera car l’adresse MAC de destination n’est pas G.

55
00:04:38,530 --> 00:04:45,070
L’adresse MAC des routeurs locaux lorsqu’elle reçoit la trame du concentrateur, elle l’acceptera car l’adresse MAC de destination

56
00:04:45,070 --> 00:04:48,420
est a et les adresses MAC des PC.

57
00:04:48,850 --> 00:04:54,460
Il supprimera ensuite les en-têtes de couche 2 et transmettra les informations à un protocole de couche supérieure.

58
00:04:54,460 --> 00:04:56,530
Dans ce cas, c'était une réponse d'écho.

59
00:04:56,770 --> 00:04:59,540
Ainsi, le ping affichera un message de réussite.

60
00:04:59,560 --> 00:05:07,430
En d'autres termes, une demande d'écho a été envoyée au CCP et un message de réponse d'écho a été correctement reçu.

61
00:05:07,470 --> 00:05:13,590
Ainsi, dans ma capture de Wireshark, par exemple, je peux filtrer les messages ICMP.

62
00:05:13,690 --> 00:05:21,850
Je peux voir l’écho initial demander un message envoyé par mon PC à 10 0 0 0 2 4 4 et je peux alors voir

63
00:05:21,850 --> 00:05:23,830
le message de réponse d'écho.

64
00:05:23,830 --> 00:05:28,380
Notez qu'il s'agit d'un envoi individuel de trame de coûts.

65
00:05:28,390 --> 00:05:36,280
Tout d'abord, de mon PC au routeur local, puis une monodiffusion du routeur à ma machine locale, les mêmes informations

66
00:05:36,280 --> 00:05:43,000
sont affichées si vous envoyez une commande ping à un autre périphérique local du segment, vous verrez

67
00:05:43,000 --> 00:05:45,010
quelque chose de similaire.

68
00:05:45,190 --> 00:05:49,970
Ping 10 0 0 2 4 4 et le ping a réussi.

69
00:05:50,020 --> 00:05:56,890
Ainsi, dans cet exemple, mon PC a réussi à obtenir une réponse du périphérique distant auquel je faisais un ping.