1
00:00:00,920 --> 00:00:07,730
Entonces, en resumen, cuando un dispositivo desea comunicarse con otro dispositivo en la misma subred,

2
00:00:07,730 --> 00:00:16,190
enviará una transmisión al segmento local para encontrar la dirección MAC del dispositivo utilizando la dirección IP de destino.

3
00:00:16,190 --> 00:00:20,080
Entonces, en este caso, sains the frame to the hub.

4
00:00:20,390 --> 00:00:27,290
El concentrador porque es un repetidor multipuerto enviará el marco fuera de todos los puertos excepto el puerto en el

5
00:00:27,290 --> 00:00:28,060
que llegó.

6
00:00:28,130 --> 00:00:36,560
Por lo tanto, tanto el enrutador como el hoost ven recibir el marco. Las tarjetas de interfaz de red solo aceptarán el

7
00:00:36,650 --> 00:00:44,150
tráfico unicast destinado a su dirección MAC o aceptarán el tráfico de difusión y aceptarán el tráfico de multidifusión para

8
00:00:44,210 --> 00:00:47,880
las direcciones de multidifusión a las que se suscriben.

9
00:00:48,170 --> 00:00:52,480
El enrutador tiene una dirección MAC de g en la interfaz primero Ethan 00.

10
00:00:52,610 --> 00:00:59,480
Entonces el enrutador recibirá la transmisión y reenviará la solicitud a los protocolos de Hialeah. El Rotto

11
00:00:59,480 --> 00:01:07,850
podrá ver al menos tres que esta es una solicitud extraña para la dirección IP 10 1 1 2 pero la

12
00:01:07,850 --> 00:01:14,690
Rodda en este ejemplo está configurada con direcciones IP 10 1 uno ciento y 10 1 a 100.

13
00:01:14,690 --> 00:01:20,990
Entonces, la tabla de recuento descarta el marco porque la solicitud no es para una de sus direcciones IP.

14
00:01:21,260 --> 00:01:23,660
Los enrutadores no envían transmisiones.

15
00:01:23,660 --> 00:01:30,710
Por lo tanto, esta transmisión no se reenvía desde la interfaz Ethan, es 0 1, por lo que la transmisión recibida

16
00:01:30,710 --> 00:01:32,170
por Rada se interrumpe.

17
00:01:32,420 --> 00:01:38,990
La tarjeta de interfaz de red en PCC recibirá la transmisión y verá que esta es una solicitud de alta

18
00:01:38,990 --> 00:01:40,370
para su dirección IP.

19
00:01:40,370 --> 00:01:43,220
Entonces responderá con una respuesta op.

20
00:01:43,340 --> 00:01:50,990
Como hemos visto en Why, capture PCC, se actualizará su caché para mostrar que la dirección IP 10 1 1 1

21
00:01:51,410 --> 00:01:57,530
está asociada a la paga de la dirección MAC y luego enviará el frame al hub.

22
00:01:57,530 --> 00:02:02,300
El Hubble reenvía el cuadro de todos los puertos porque es un repetidor multipuerto.

23
00:02:02,300 --> 00:02:07,830
La ruta en este ejemplo recibirá un marco del concentrador pero debido a que la dirección MAC

24
00:02:07,830 --> 00:02:14,510
de destino es a y no es la dirección MAC del Rato que es g the rot, dejará caer el marco.

25
00:02:14,540 --> 00:02:21,380
También recibirá una copia del cuadro cuando reciba el cuadro, lo aceptará porque la dirección de destino

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

27
00:02:22,310 --> 00:02:23,870
Y su dirección MAC es a.

28
00:02:24,020 --> 00:02:31,520
A continuación, actualizará su caché con una entrada ascendente que indica que la dirección IP 10 1 1 2 está asociada a

29
00:02:31,520 --> 00:02:32,840
la dirección MAC C. Entonces, la respuesta permite actualizar su dinero en efectivo.

30
00:02:33,020 --> 00:02:38,550
En este punto, no se ha transmitido tráfico de usuario.

31
00:02:38,630 --> 00:02:41,900
Lo que sucedió aquí es que

32
00:02:42,110 --> 00:02:49,070
los dispositivos simplemente han resuelto qué direcciones MAC están asociadas con qué direcciones IP.

33
00:02:49,070 --> 00:02:50,560
Entonces AA ahora sabe

34
00:02:50,690 --> 00:03:00,100
que la dirección MAC C está asociada con la dirección IP 10 1 1 2, el tráfico rosa no se puede transmitir con una fuente

35
00:03:00,100 --> 00:03:06,760
de dirección MAC de la cual es la dirección MAC de destino de la máquina local de C. En otras palabras, PCC la dirección MAC de destino se aprendió a través de ARP. Las direcciones IP de origen cambian la dirección IP

36
00:03:06,760 --> 00:03:07,550
de destino uno

37
00:03:07,570 --> 00:03:14,740
a uno y también cabe preguntarse cuándo el concentrador recibe el marco de la PC lo repetirá en todas las interfaces excepto en la interfaz.

38
00:03:14,760 --> 00:03:21,040
Llegó.

39
00:03:21,070 --> 00:03:25,680
Por lo tanto, el enrutador recibirá nuevamente el marco, pero lo abandonará porque su dirección MAC es G y la dirección MAC de

40
00:03:25,690 --> 00:03:26,820
destino para este marco es c. PCC también recibirá el tráfico

41
00:03:27,010 --> 00:03:33,130
y lo aceptará porque la dirección MAC de destino es C y sus direcciones MAC locales ven que los últimos dos cabezales serán eliminados y

42
00:03:33,130 --> 00:03:36,760
la información de la dirección IP será leída por los protocolos de capa superior.

43
00:03:36,760 --> 00:03:43,480
Este es un paquete de eco ICMP para que la PC responda con un mensaje de respuesta de eco C enviará la trama al concentrador con

44
00:03:43,480 --> 00:03:48,970
una dirección MAC de origen para ver la dirección MAC de destino de una dirección MAC de AA de EGNOS debido

45
00:03:49,120 --> 00:03:51,010
al mensaje de solicitud de OP anterior.

46
00:03:51,010 --> 00:03:59,950
Por lo tanto, la memoria caché tiene una dirección MAC asociando en el árbol a con la dirección IP

47
00:03:59,950 --> 00:04:06,760
10 1 1 1 de la dirección MAC de origen y el marco es c. La dirección MAC de destino es una dirección IP de origen es 10 1 1 2 la dirección IP de destino es 10 1 1 1.

48
00:04:06,760 --> 00:04:09,070
Cuando el centro recibe

49
00:04:09,070 --> 00:04:17,020
la trama, el Hubble repite todos los puertos, excepto aquel en el que se recibió.

50
00:04:17,020 --> 00:04:18,100
El Rotto recibirá el marco, pero lo abandonará porque la dirección MAC de destino no está en G.

51
00:04:18,160 --> 00:04:24,750
La dirección MAC de los enrutadores locales cuando recibe el marco del concentrador lo aceptará porque

52
00:04:25,000 --> 00:04:30,430
la dirección MAC de destino es una y las direcciones MAC de la computadora.

53
00:04:30,430 --> 00:04:31,740
Luego quitará los encabezados de la capa 2 y reenviará la información a los protocolos de capa superior.

54
00:04:31,900 --> 00:04:38,370
En este caso, fue una respuesta de eco.

55
00:04:38,530 --> 00:04:45,070
Entonces, el ping mostrará un mensaje de éxito.

56
00:04:45,070 --> 00:04:48,420
En otras palabras, se envió una solicitud de eco al PCC y se recibió con éxito un mensaje de respuesta de eco.

57
00:04:48,850 --> 00:04:54,460
Entonces en mi captura de wireshark, por ejemplo, puedo filtrar los mensajes ICMP.

58
00:04:54,460 --> 00:04:56,530
Puedo ver el eco inicial solicitar un mensaje enviado desde mi PC a

59
00:04:56,770 --> 00:04:59,540
10 0 0 0 2 4 4 y luego puedo ver el mensaje de respuesta de eco.

60
00:04:59,560 --> 00:05:07,430
Tenga en cuenta que se trata de unidifusión de un único marco de costes.

61
00:05:07,470 --> 00:05:13,590
En primer lugar, desde mi PC al enrutador local y, a continuación, una unidifusión desde el enrutador

62
00:05:13,690 --> 00:05:21,850
a mi máquina local, se mostraría la misma información si está haciendo ping a otro dispositivo local en el segmento como usuario.

63
00:05:21,850 --> 00:05:23,830
Vería algo similar a esto.

64
00:05:23,830 --> 00:05:28,380
Ping 10 0 0 2 4 4 y el ping fue exitoso.

65
00:05:28,390 --> 00:05:36,280
Entonces, en este ejemplo, mi PC obtuvo una respuesta exitosa del dispositivo remoto al que estaba haciendo ping.

66
00:05:36,280 --> 00:05:43,000
 

67
00:05:43,000 --> 00:05:45,010
 

68
00:05:45,190 --> 00:05:49,970
 

69
00:05:50,020 --> 00:05:56,890