Pruebas de fragmentación de tráfico en un túnel EoIP

Fecha: 3 y 4 de abril del 2024

Escenario

Este laboratorio es el tercero en la trilogía EoIP y analiza el aumento de bytes de una trama/paquete al pasar por el túnel,

ya que se le agregan nuevas cabeceras de layers 2, 3 y “3 ½”. También el aumento de 4 bytes por el etiquetado 802.1q

ya que el túnel pasar tramas de diferentes VLANs, y que sucede al excedernos en la MTU.

1.- Tomemos como ejemplo una trama/paquete con un ping “cargado” (MTU al máximo):

1.1.- Se genera en el host origen (VLAN 1 sin etiquetar de extremo a extremo):

C:\> ping 192.168.0.100 -f -l 1472

Haciendo ping a 192.168.0.100 con 1472 bytes de datos:

Respuesta desde 192.168.0.100: bytes=1472 tiempo=2ms TTL=128

Respuesta desde 192.168.0.100: bytes=1472 tiempo=9ms TTL=128

Respuesta desde 192.168.0.100: bytes=1472 tiempo=2ms TTL=128

Respuesta desde 192.168.0.100: bytes=1472 tiempo=2ms TTL=128

Podemos ver la trama/paquete a su máxima capacidad ya que faltan los 4 bytes del CRC que completa los 1518 bytes.

1.2.- En tránsito:

Aquí vemos que existe fragmentación ya que al tunelarse se agregan nuevas cabeceras y la trama/paquete “crece” 42 bytes, y por lo tanto

La cuenta es 1518 + 42 = 1560 > 1518.

1.2.1.- Detalle curioso (o rebuscado) de como Wireshark nos muestra las tramas/paquetes fragmentados:

Frame 1: 1514 bytes on wire (12112 bits), 1514 bytes captured (12112 bits)

Ethernet II, Src: 18:fd:74:03:b7:9a, Dst: 18:fd:74:03:b9:2a (layer 2, 14 bytes)

Internet Protocol Version 4, Src: 181.10.139.236, Dst: 181.111.221.110 (layer 3, 20 bytes)

Data (1480 bytes)

0000 18 fd 74 03 b9 2a 18 fd 74 03 b7 9a 08 00 45 00

0010 05 dc cd 03 20 00 fe 2f f6 19 b5 0a 8b ec b5 6f (el 2f resaltado indica que el payload es protocolo 47 (GRE/EoIP))

0020 dd 6e 20 01 64 00 05 ea 00 00 e8 6a 64 dc e2 f5

0030 00 23 cd b0 08 89 08 00 45 00 05 dc 9f 2f 40 00

0040 80 01 d3 c1 c0 a8 00 7b c0 a8 00 64 08 00 15 aa

0050 00 01 2a 9d 61 62 63 64 65 66 67 68 69 6a 6b 6c

0060 6d 6e 6f 70 71 72 73 74 75 76 77 61 62 63 64 65

---resumido---

05d0 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71

05e0 72 73 74 75 76 77 61 62 63 64

1.2.2.- Donde entre los datos podemos ver:

La cabecera GRE, layer 2 original, layer 3 original, ICMP y datos comenzando en 61

0000 18 fd 74 03 b9 2a 18 fd 74 03 b7 9a 08 00 45 00

0010 05 dc cd 03 20 00 fe 2f f6 19 b5 0a 8b ec b5 6f

0020 dd 6e 20 01 64 00 05 ea 00 00 e8 6a 64 dc e2 f5

0030 00 23 cd b0 08 89 08 00 45 00 05 dc 9f 2f 40 00

0040 80 01 d3 c1 c0 a8 00 7b c0 a8 00 64 08 00 15 aa

0050 00 01 2a 9d 61 62 63 64 65 66 67 68 69 6a 6b 6c

0060 6d 6e 6f 70 71 72 73 74 75 76 77 61 62 63 64 65

---resumido---

05d0 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71

05e0 72 73 74 75 76 77 61 62 63 64 (ver que los datos del payload terminan en 64)

Frame 2: 76 bytes on wire (608 bits), 76 bytes captured (608 bits)

Ethernet II, Src: 18:fd:74:03:b7:9a, Dst: 18:fd:74:03:b9:2a (layer 2, 14 bytes)

Internet Protocol Version 4, Src: 181.10.139.236, Dst: 181.111.221.110 (layer 3, 20 bytes)

Generic Routing Encapsulation (MIKROTIK EoIP) (layer “3 ½”, 8 bytes)

Ethernet II, Src: 00:23:cd:b0:08:89, Dst: e8:6a:64:dc:e2:f5

Internet Protocol Version 4, Src: 192.168.0.123, Dst: 192.168.0.100

Internet Control Message Protocol ) (layer “3 ½”, 8 bytes)

Type: 8 (Echo (ping) request)

Code: 0

Checksum: 0x15aa [correct]

[Checksum Status: Good]

Identifier (BE): 1 (0x0001)

Identifier (LE): 256 (0x0100)

Sequence Number (BE): 10909 (0x2a9d)

Sequence Number (LE): 40234 (0x9d2a)

[Response frame: 4]

Data (1472 bytes)

Frame (76 bytes):

0000 18 fd 74 03 b9 2a 18 fd 74 03 b7 9a 08 00 45 00

0010 00 3e cd 03 00 b9 fe 2f 1a ff b5 0a 8b ec b5 6f

0020 dd 6e 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 (ver que es continuación de 64 del paquete anterior)

0030 73 74 75 76 77 61 62 63 64 65 66 67 68 69 6a 6b

0040 6c 6d 6e 6f 70 71 72 73 74 75 76 77

1.2.3.- Que le sucede a la trama/paquete:

1.2.4.- Cuando sale del origen:

1.2.5.- Cuando llega al router:

1.2.6.- Cuando se encapsula en EoIP:

1.2.7.- Cuando se transmite:

1.2.8.- Cuando se recibe:

1.3.- En destino:

Aquí vemos que la trama vuelve a la normalidad, igual que cuando se transmitió en el host origen. Otro dato que nos llevamos es que no existe

reesamblado de las tramas/paquetes en el host final tal como otros casos sino que esto se produce en el terminador del túnel EoIP.

2.- Con VLAN etiquetada:

2.1.- Se genera tráfico en el host origen:

Frame 9: 1514 bytes on wire (12112 bits), 1514 bytes captured (12112 bits) on interface id 0

Ethernet II, Src: 00:23:cd:b0:08:89, Dst: e8:6a:64:dc:e2:f5 (layer 2, 14 bytes)

Internet Protocol Version 4, Src: 192.168.10.123, Dst: 192.168.10.100 (layer 3, 20 bytes)

Internet Control Message Protocol (layer “3 ½”’, 8 bytes)

Data (1472 bytes) (payload, 1472 bytes)

Total: 1514 bytes

0000 e8 6a 64 dc e2 f5 00 23 cd b0 08 89 08 00 45 00

0010 00 3c b9 ab 00 00 80 01 00 00 c0 a8 0a 7b c0 a8

0020 0a 64 08 00 22 f0 00 01 2a 6b 61 62 63 64 65 66

0030 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76

0040 77 61 62 63 64 65 66 67 68 69

---resumido---

05d0 75 76 77 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d

05e0 6e 6f 70 71 72 73 74 75 76 77

2.2.- Cuando sale del switch hacia el router:

Cuando se transmite del switch hacia el router ahora la trama está etiquetada con 802.1q (10T de tagged)

Se puede ver que de 1514 bytes (1518 con el CRC) “crece” a 1518 bytes (1522 con el CRC).

Frame 1: 1518 bytes on wire (12144 bits), 1518 bytes captured (12144 bits)

Ethernet II, Src: 00:23:cd:b0:08:89, Dst: e8:6a:64:dc:e2:0f

Destination: e8:6a:64:dc:e2:0f

Source: 00:23:cd:b0:08:89

Type: 802.1Q Virtual LAN (0x8100) (ver ethertype más abajo)

802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 10

000. .... .... .... = Priority: Best Effort (default) (0)

...0 .... .... .... = DEI: Ineligible

.... 0000 0000 1010 = ID: 10

Type: IPv4 (0x0800) (ver ethertype más abajo)

Internet Protocol Version 4, Src: 192.168.10.123, Dst: 192.168.10.100

Internet Control Message Protocol

Data (1472 bytes)

Fuente: https://en.wikipedia.org/wiki/EtherType

2.3.- Cuando transita por el túnel EoIP:

La trama de la VLAN 10 al salir del switch ya está etiquetada (tagged, 10T) por lo que el túnel la encapsulará etiquetada, agregándole

las cabeceras L2, L3 y GRE lo que le da un aumento de 74 a 120 bytes en tránsito.

En este ejemplo además de las nueva cabeceras agregamos la etiqueta (tag) de 4 bytes correspondiente a la VLAN10.

Frame 17: 1514 bytes on wire (12112 bits), 1514 bytes captured (12112 bits)

Ethernet II, Src: 18:fd:74:03:b7:9a, Dst: 18:fd:74:03:b9:2a

Destination: 18:fd:74:03:b9:2a

Source: 18:fd:74:03:b7:9a

Type: IPv4 (0x0800) (este es el ethertype para IP)

Internet Protocol Version 4, Src: 181.10.139.236, Dst: 181.111.221.110

0100 .... = Version: 4

.... 0101 = Header Length: 20 bytes (5)

Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)

Total Length: 1500

Identification: 0xcd03 (52483)

001. .... = Flags: 0x1, More fragments

...0 0000 0000 0000 = Fragment Offset: 0

Time to Live: 254

Protocol: Generic Routing Encapsulation (47)

Header Checksum: 0xf619

Source Address: 181.10.139.236

Destination Address: 181.111.221.110

Data (1480 bytes)

0000 18 fd 74 03 b9 2a 18 fd 74 03 b7 9a 08 00 45 00 (layer 2) (layer 3)

0010 05 dc 5e 04 20 00 fe 2f 65 19 b5 0a 8b ec b5 6f

0020 dd 6e 20 01 64 00 05 ee 00 00 e8 6a 64 dc e2 f5 (layer 3)(GRE)(layer 2)

0030 00 23 cd b0 08 89 81 00 00 0a 08 00 45 00 05 dc

0040 50 f3 40 00 80 01 0d fe c0 a8 0a 7b c0 a8 0a 64 (layer 3)

0050 08 00 15 a6 00 01 2a a1 61 62 63 64 65 66 67 68 (ICMP)(data)

0060 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 77 61

---resumido---

05d0 75 76 77 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d

05e0 6e 6f 70 71 72 73 74 75 76 77 (ver que es 61 en la continuación de data en frame 18)

Frame 18: 80 bytes on wire (640 bits), 80 bytes captured (640 bits)

Frame 1: 120 bytes on wire (960 bits), 120 bytes captured (960 bits)

Ethernet II, Src: 18:fd:74:03:b7:9a, Dst: 18:fd:74:03:b9:2a

Internet Protocol Version 4, Src: 181.10.139.236, Dst: 181.111.221.110

Generic Routing Encapsulation (MIKROTIK EoIP) (todas estas cabeceras realmente están en Frame 17,

Ethernet II, Src: 00:23:cd:b0:08:89, Dst: e8:6a:64:dc:e2:f5 comportamiento del Wireshark sin entender)

Destination: e8:6a:64:dc:e2:f5

Source: 00:23:cd:b0:08:89

Type: 802.1Q Virtual LAN (0x8100) (este es el ethertype para 802.1q)

802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 10 (este es el VLAN id)

Internet Protocol Version 4, Src: 192.168.10.123, Dst: 192.168.10.100

Internet Control Message Protocol

Data (1472 bytes)

0000 18 fd 74 03 b9 2a 18 fd 74 03 b7 9a 08 00 45 00

0010 00 6a 98 54 00 00 fe 2f 50 3b b5 0a 8b ec b5 6f

0020 dd 6e 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e

0030 6f 70 71 72 73 74 75 76 77 61 62 63 64 65 66 67

0040 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 77

2.4.- Cuando entra al switch desde el router:

Cuando sale del switch al host destino:

Cuando se recibe en la PC destino:

En este caso la trama/paquete es exactamente igual a la enviada (de hecho es la misma) ya que pertenece al mismo segmento

LAN, no hay saltos con decrementos TTL, etc... y la trama ya se encuentra sin etiquetar (untagged).

3.- Cómo buscamos la máxima MTU posible en el túnel:

Activamos el bit DF (Don’t Fragment) utilizando el argumento -f y buscamos con prueba y error un valor aproximado,

en este caso lo resumimos a los valores de la prueba, pero generalmente son varios intentos.

C:\> ping 192.168.10.251 -f -l 1473

Haciendo ping a 192.168.10.251 con 1473 bytes de datos:

Es necesario fragmentar el paquete pero se especificó DF.

Es necesario fragmentar el paquete pero se especificó DF.

Es necesario fragmentar el paquete pero se especificó DF.

Es necesario fragmentar el paquete pero se especificó DF.

C:\> ping 192.168.10.251 -f -l 1472 (este es el MTU máximo utilizando el túnel con tag 802.1q de 4 bytes extra)

Haciendo ping a 192.168.10.251 con 1472 bytes de datos:

Respuesta desde 192.168.10.251: bytes=1472 tiempo=5ms TTL=255

Respuesta desde 192.168.10.251: bytes=1472 tiempo=5ms TTL=255

Respuesta desde 192.168.10.251: bytes=1472 tiempo=5ms TTL=255

Respuesta desde 192.168.10.251: bytes=1472 tiempo=3ms TTL=255

4.- Resumen:

Cuando utilizamos la máxima capacidad de transmisión (MTU) debemos tener en cuenta que en el recorrido de extremo

a extremo podemos tener modificaciones tales como el etiquetado (802.1q) o reencapsulado del tráfico, o como también

el agregado de cabeceras (GRE/EoIP), lo que puede llevar a la fragmentación.

En este caso puntual, la fragmentación ocurre entre ambos terminadores GRE/EoIP y es transparente, pero hay casos

Donde la fragmentación permanece hasta el host final y eso a veces lleva a (fuertes) dolores de cabeza.

El tema de la fragmentación tiene mucho para experimentar, aquí dejo uno algo…áspero. Que lo disfruten…

(2024) I’dont need a doctor, I’m sure

Rosaro, Argentina