BGP UPDATE with Multiple Prefixes Packet Capture

Lesson Contents

How many prefixes fit in one BGP UPDATE message? This packet capture shows the answer in practice. A Cisco router advertises eight prefixes (172.16.0.0/24 to 172.16.7.0/24) to its eBGP neighbor, and because all eight share the same path attributes, they travel in one 82-byte UPDATE. A second capture shows the same eight prefixes with a different MED each, and then BGP needs eight separate UPDATE messages.

That’s the key rule of the UPDATE message: one set of path attributes, followed by every prefix that shares them. The BGP messages lesson covers all message types. More captures are in the Packet Capture Library.

Want to open this capture in Wireshark yourself? The pcap file is free with a NetworkLessons account. Your free account also unlocks all our free lessons and every capture in the Packet Capture Library.

Create a free account to download the pcap

Already have an account? Log in and the download button appears here.

Capture overview

File	bgp-ebgp-update-same-path-attributes.pcap
Packets	38 (session setup, End-of-RIB markers, then the UPDATE with eight prefixes in packet 21)
Protocol	BGP-4 (RFC 4271), UPDATE message
Transport	TCP 179, eBGP between 192.168.12.1 (AS 1) and 192.168.12.2 (AS 2)
Devices	Cisco IOS routers
Wireshark filter	`bgp.type == 2` for UPDATE messages only

Packet walkthrough

One UPDATE, eight prefixes (packet 21)

Border Gateway Protocol - UPDATE Message
    Length: 82
    Type: UPDATE Message (2)
    Withdrawn Routes Length: 0
    Total Path Attribute Length: 27
    Path attributes
        Path Attribute - ORIGIN: IGP
            Type Code: ORIGIN (1)
            Length: 1
            Origin: IGP (0)
        Path Attribute - AS_PATH: 1
            Type Code: AS_PATH (2)
            Length: 6
            AS Path segment: 1
                Segment type: AS_SEQUENCE (2)
                Segment length (number of ASN): 1
                AS4: 1
        Path Attribute - NEXT_HOP: 192.168.12.1
            Type Code: NEXT_HOP (3)
            Length: 4
            Next hop: 192.168.12.1
        Path Attribute - MULTI_EXIT_DISC: 0
            Type Code: MULTI_EXIT_DISC (4)
            Length: 4
            Multiple exit discriminator: 0
    Network Layer Reachability Information (NLRI)
        172.16.0.0/24
            NLRI prefix length: 24
            NLRI prefix: 172.16.0.0
        172.16.1.0/24
            NLRI prefix length: 24
            NLRI prefix: 172.16.1.0
        172.16.2.0/24
            NLRI prefix length: 24
            NLRI prefix: 172.16.2.0
        172.16.3.0/24
            NLRI prefix length: 24
            NLRI prefix: 172.16.3.0
        172.16.4.0/24
            NLRI prefix length: 24
            NLRI prefix: 172.16.4.0
        172.16.5.0/24
            NLRI prefix length: 24
            NLRI prefix: 172.16.5.0
        172.16.6.0/24
            NLRI prefix length: 24
            NLRI prefix: 172.16.6.0
        172.16.7.0/24
            NLRI prefix length: 24
            NLRI prefix: 172.16.7.0

An UPDATE message has three parts, in this order:

Withdrawn routes: prefixes that are no longer reachable. The length is 0, so nothing is withdrawn here. One UPDATE can withdraw some prefixes and advertise others at the same time.
Path attributes: one set of attributes, 27 bytes here: ORIGIN, AS_PATH, NEXT_HOP and MED. The attributes apply to every prefix in the NLRI that follows.
NLRI: the advertised prefixes. Each one is just a prefix length (1 byte) plus only as many bytes of the prefix as the length needs. A /24 takes 4 bytes in total: 1 length byte and 3 bytes of address.

Count the bytes: 19 bytes of BGP header, 2 bytes withdrawn routes length, 2 bytes total path attribute length, 27 bytes of attributes and 8 × 4 = 32 bytes of NLRI. That adds up to the 82 bytes in the length field. The attributes are sent once, no matter how many prefixes share them.

Different attributes: eight UPDATEs

The second capture has the same eight prefixes, but this time the router sets a different MED on each one (100 for 172.16.0.0/24 up to 800 for 172.16.7.0/24):

Border Gateway Protocol - UPDATE Message
    Length: 54
    Type: UPDATE Message (2)
    Withdrawn Routes Length: 0
    Total Path Attribute Length: 27
        Path Attribute - ORIGIN: IGP
        Path Attribute - AS_PATH: 1
        Path Attribute - NEXT_HOP: 192.168.12.1
        Path Attribute - MULTI_EXIT_DISC: 800
    Network Layer Reachability Information (NLRI)
        172.16.7.0/24
Border Gateway Protocol - UPDATE Message
    Length: 54
    Type: UPDATE Message (2)
    Withdrawn Routes Length: 0
    Total Path Attribute Length: 27
        Path Attribute - ORIGIN: IGP
        Path Attribute - AS_PATH: 1
        Path Attribute - NEXT_HOP: 192.168.12.1
        Path Attribute - MULTI_EXIT_DISC: 700
    Network Layer Reachability Information (NLRI)
        172.16.6.0/24
... (six more UPDATE messages, MED 600 down to 100)

One UPDATE per unique set of attributes: every prefix has a different MED, so no two prefixes can share an UPDATE. Each message carries the full 27 bytes of attributes for just one 4-byte prefix.
8 × 54 = 432 bytes instead of 82: more than five times as much data for the same eight routes. Wireshark shows all eight messages in one TCP segment (packet 21, 486 bytes on the wire), because BGP sends them back to back.

At Internet scale, this packing makes a big difference. Many prefixes from the same origin share the same attributes, so they’re packed together. Anything that makes attributes unique per prefix, like a per-prefix MED or community, increases the number of UPDATE messages and the time it takes to converge. On Cisco IOS, show ip bgp update-group shows the related optimization on the sending side: neighbors with the same outbound policy share one set of formatted UPDATEs.