Análisis de un update BGP de 2048 rutas

Fecha: 30 de septiembre del 2023

Escenario

Este laboratorio es una continuación del anterior y evalúa cuantas tramas/paquetes/segmentos se necesitan

para anunciar 2048 rutas (o redes, según se quiera interpretar) y como vimos antes, si existie fragmentación,

cuantos posibles fragmentos hay en cada update.

Este escenario es la preparación para analizar la transferencia de una tabla BGP completa.

1.- Configuración inicial:

Como en lab anterior, configuramos rutas null para redistribuirlas en el BGP anunciandolas a un router

vecino en los updates que queremos analizar.

0 a 255 son 256 rutas

|

Router-A(config)#ip route 200.1.0.0 255.255.255.0 null 0 (ruta 1)

Router-A(config)#ip route 200.1.1.0 255.255.255.0 null 0 (ruta 2)

Router-A(config)#ip route 200.1.2.0 255.255.255.0 null 0 (ruta 3)

Router-A(config)#  (resto de las rutas)

Router-A(config)#ip route 200.8.255.0 255.255.255.0 null 0 (ruta 2048)

Router-A(config)# |

Router-A(config)# 8 x 256 = 2048 rutas

Router-A(config)#

Router-A(config)#router bgp 65535

Router-A(config-router)#redistribute static

Router-A(config-router)#end

Router-A#

2.- Verificación:

Router-A#sh ip route summary

IP routing table name is default (0x0)

IP routing table maximum-paths is 32

Route Source    Networks    Subnets     Replicates   Overhead    Memory (bytes)

connected         0                  2                 0                120              360

static             2048                0                 0            20760          62280

application        0                  0                 0                     0                 0

bgp 65535        0                  2                 0                 420            1260

  External:  7 Internal: 0 Local: 0

internal             2                                                    14720

Total             2050                2                 0             21300         78620

Router-A#

3.- Generamos el update:

4.- Verificamos en Wireshark:

Frame 13: 1514 bytes on wire (12112 bits), 1514 bytes captured (12112 bits) on interface id 0 (primer fragmento del primer update)

Ethernet II, Src: cc:46:d6:2b:5a:54, Dst: 70:81:05:b5:77:82

Internet Protocol Version 4, Src: 10.0.0.1, Dst: 10.0.0.2

Transmission Control Protocol, Src Port: 179, Dst Port: 39106, Seq: 96, Ack: 194, Len: 1460

Frame 15: 1514 bytes on wire (12112 bits), 1514 bytes captured (12112 bits) on interface id 0 (segundo fragmento del primer update)

Ethernet II, Src: cc:46:d6:2b:5a:54, Dst: 70:81:05:b5:77:82

Internet Protocol Version 4, Src: 10.0.0.1, Dst: 10.0.0.2

Transmission Control Protocol, Src Port: 179, Dst Port: 39106, Seq: 1556, Ack: 194, Len: 1460

Frame 16: 1224 bytes on wire (9792 bits), 1224 bytes captured (9792 bits) on interface id 0 (tercer fragmento del primer update)

Ethernet II, Src: cc:46:d6:2b:5a:54, Dst: 70:81:05:b5:77:82

Internet Protocol Version 4, Src: 10.0.0.1, Dst: 10.0.0.2

Transmission Control Protocol, Src Port: 179, Dst Port: 39106, Seq: 3016, Ack: 194, Len: 1170

Source Port: 179

Destination Port: 39106

Sequence Number: 3016 (relative sequence number)

Sequence Number (raw): 3405446454

Acknowledgment Number: 194 (relative ack number)

Acknowledgment number (raw): 3797529390

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

Flags: 0x018 (PSH, ACK)

000. .... .... = Reserved: Not set

...0 .... .... = Accurate ECN: Not set

.... 0... .... = Congestion Window Reduced: Not set

.... .0.. .... = ECN-Echo: Not set

.... ..0. .... = Urgent: Not set

.... ...1 .... = Acknowledgment: Set

.... .... 1... = Push: Set (esto indica que ya se debe rearmar el segmento)

.... .... .0.. = Reset: Not set

.... .... ..0. = Syn: Not set

.... .... ...0 = Fin: Not set

Window: 16191

Checksum: 0x1bcd [unverified]

Urgent Pointer: 0

TCP payload (1170 bytes)

TCP segment data (1170 bytes)

[3 Reassembled TCP Segments (4090 bytes): #13(1460), #15(1460), #16(1170)]

[Frame: 13, payload: 0-1459 (1460 bytes)]

[Frame: 15, payload: 1460-2919 (1460 bytes)]

[Frame: 16, payload: 2920-4089 (1170 bytes)]

[Segment count: 3]

[Reassembled TCP length: 4090]

[Reassembled TCP Data: ffffffffffffffffffffffffffffffff0ffa020000001b4001010240020602010000fffe…]

Border Gateway Protocol - UPDATE Message

Marker: ffffffffffffffffffffffffffffffff

Length: 4090

Type: UPDATE Message (2)

Withdrawn Routes Length: 0

Total Path Attribute Length: 27

Path attributes

Network Layer Reachability Information (NLRI)

200.1.0.0/24

200.1.1.0/24

200.1.2.0/24

200.1.3.0/24

200.1.4.0/24

---resumido---

200.4.239.0/24

200.4.240.0/24

200.4.241.0/24 (hasta aquí 1010 rutas)

Frame 18: 1514 bytes on wire (12112 bits), 1514 bytes captured (12112 bits) on interface id 0 (primer fragmento del segundo update)

Ethernet II, Src: cc:46:d6:2b:5a:54, Dst: 70:81:05:b5:77:82

Internet Protocol Version 4, Src: 10.0.0.1, Dst: 10.0.0.2

Transmission Control Protocol, Src Port: 179, Dst Port: 39106, Seq: 4186, Ack: 194, Len: 1460

Frame 19: 1514 bytes on wire (12112 bits), 1514 bytes captured (12112 bits) on interface id 0 (segundo fragmento del segundo update)

Ethernet II, Src: cc:46:d6:2b:5a:54, Dst: 70:81:05:b5:77:82

Internet Protocol Version 4, Src: 10.0.0.1, Dst: 10.0.0.2

Transmission Control Protocol, Src Port: 179, Dst Port: 39106, Seq: 5646, Ack: 194, Len: 1460

Frame 20: 1224 bytes on wire (9792 bits), 1224 bytes captured (9792 bits) on interface id 0 (tercer fragmento del segundo update)

Ethernet II, Src: cc:46:d6:2b:5a:54, Dst: 70:81:05:b5:77:82

Internet Protocol Version 4, Src: 10.0.0.1, Dst: 10.0.0.2

Transmission Control Protocol, Src Port: 179, Dst Port: 39106, Seq: 7106, Ack: 194, Len: 1170

[3 Reassembled TCP Segments (4090 bytes): #18(1460), #19(1460), #20(1170)]

[Frame: 18, payload: 0-1459 (1460 bytes)]

[Frame: 19, payload: 1460-2919 (1460 bytes)]

[Frame: 20, payload: 2920-4089 (1170 bytes)]

[Segment count: 3]

[Reassembled TCP length: 4090]

[Reassembled TCP Data: ffffffffffffffffffffffffffffffff0ffa020000001b4001010240020602010000fffe…]

Border Gateway Protocol - UPDATE Message

Marker: ffffffffffffffffffffffffffffffff

Length: 4090

Type: UPDATE Message (2)

Withdrawn Routes Length: 0

Total Path Attribute Length: 27

Path attributes

Network Layer Reachability Information (NLRI)

200.4.242.0/24

200.4.243.0/24

200.4.244.0/24

---resumido---

200.8.225.0/24

200.8.226.0/24

200.8.227.0/24 (hasta aquí 2020 rutas)

Frame 21: 239 bytes on wire (1912 bits), 239 bytes captured (1912 bits) on interface id 0 (tercer update)

Ethernet II, Src: cc:46:d6:2b:5a:54, Dst: 70:81:05:b5:77:82

Internet Protocol Version 4, Src: 10.0.0.1, Dst: 10.0.0.2

Transmission Control Protocol, Src Port: 179, Dst Port: 39106, Seq: 8276, Ack: 194, Len: 185

Border Gateway Protocol - UPDATE Message

Marker: ffffffffffffffffffffffffffffffff

Length: 162

Type: UPDATE Message (2)

Withdrawn Routes Length: 0

Total Path Attribute Length: 27

Path attributes

Network Layer Reachability Information (NLRI)

200.8.228.0/24

200.8.229.0/24

200.8.230.0/24

---resumido---

200.8.253.0/24

200.8.254.0/24

200.8.255.0/24 (aquí 28 rutas, mas las 2020 anteriores nos dan 2048 rutas)

Border Gateway Protocol - UPDATE Message

Marker: ffffffffffffffffffffffffffffffff

Length: 23

Type: UPDATE Message (2)

Withdrawn Routes Length: 0

Total Path Attribute Length: 0

5.- Buscamos una causa del tamaño de cada update:

Para eso nos remitimos a la RFC 4271 en donde se encuentra especificado el protocolo BGP:

https://www.ietf.org/rfc/rfc4271.txt?number=4271

4. Message Formats

This section describes message formats used by BGP.

BGP messages are sent over TCP connections. A message is processed

only after it is entirely received. The maximum message size is 4096

octets. All implementations are required to support this maximum

message size. The smallest message that may be sent consists of a

BGP header without a data portion (19 octets).

All multi-octet fields are in network byte order.

4.1. Message Header Format
 
 Each message has a fixed-size header. There may or may not be a data
 portion following the header, depending on the message type. The
 layout of these fields is shown below:
 
 0 1 2 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | |
 + +
 | |
 +  +
 | Marker |
 + +
 |  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Length | Type |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
 Marker:
 
 This 16-octet field is included for compatibility; it MUST be
 set to all ones.
 
 Length:
 
 This 2-octet unsigned integer indicates the total length of the
 message, including the header in octets. Thus, it allows one
 to locate the (Marker field of the) next message in the TCP
 stream. The value of the Length field MUST always be at least
 19 and no greater than 4096, and MAY be further constrained,
 depending on the message type. "padding" of extra data after
 the message is not allowed. Therefore, the Length field MUST
 have the smallest value required, given the rest of the
 message.
 
 Type:
 
 This 1-octet unsigned integer indicates the type code of the
 message. This document defines the following type codes:
 
 1 - OPEN
 2 - UPDATE
 3 - NOTIFICATION
 4 – KEEPALIVE
 
 

6.- Resumen:

Por estandar, el BGP está limitado a enviar 4 Kbytes de información en cada update, necesitando tantos

updates como rutas/redes deba anunciar, en este caso 4 bytes por ruta/red (x.y.z y prefijo).

Por cada update de 4 Kbytes el segmento TCP se fragmenta en tres, en este escenario en particular, se

necesitaron 3 updates en 7 tramas/paquetes/segmentos (payload TCP):

2 updates de 3 fragmentos: 2 de 1514 + 1 de 1224 bytes = 4252 bytes (ó 4090 disponibles como payload

BGP) y un último update de 239 bytes (o 185 disponibles como payload BGP) para que el vecino complete

la tabla BGP, y luego poder armar la tabla de enrutamiento.

(2023) My neighbor is a dealer

Rosario, Argentina