BGP Role Mismatch Packet Capture

Lesson Contents

What happens when two eBGP neighbors don’t agree on their BGP Role? This packet capture shows it: two FRRouting routers are both configured as provider. They exchange OPEN messages, see that the roles don’t form a valid pair, and immediately tear down the session with an OPEN Message Error / Role Mismatch NOTIFICATION (error code 2, subcode 11). The session never comes up, and the routers keep retrying.

Role mismatches are one of the first things you’ll run into when you deploy RFC 9234. To see a working provider-customer session with the OTC attribute, look at the BGP Role Capability and OTC Attribute Packet Capture. The BGP route leaking lesson explains why roles exist, and BGP messages covers the OPEN and NOTIFICATION messages in general. 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-role-mismatch.pcap
Packets	13 (one complete connection attempt)
Protocol	BGP-4, BGP Role capability (RFC 9234)
Transport	TCP 179
Devices	FRRouting 10.2.1 in Containerlab: R1 AS 1 (192.168.12.1), R2 AS 2 (192.168.12.2), both with `local-role provider`
Wireshark filter	`bgp` or `bgp.notify.minor_error_open == 11`

This is the configuration of R1. R2 is the same, with AS 2 and neighbor 192.168.12.1:

router bgp 1
 bgp router-id 1.1.1.1
 no bgp ebgp-requires-policy
 neighbor 192.168.12.2 remote-as 2
 neighbor 192.168.12.2 local-role provider

Packets in this capture

No. Time      Source        Destination   Info
1   0.000000  192.168.12.2  192.168.12.1  39144 → 179 [SYN]
2   0.000013  192.168.12.1  192.168.12.2  179 → 39144 [SYN, ACK]
3   0.000022  192.168.12.2  192.168.12.1  39144 → 179 [ACK]
4   0.000087  192.168.12.2  192.168.12.1  OPEN Message
5   0.000102  192.168.12.1  192.168.12.2  179 → 39144 [ACK]
6   0.000192  192.168.12.1  192.168.12.2  OPEN Message
7   0.000197  192.168.12.2  192.168.12.1  39144 → 179 [ACK]
8   0.000235  192.168.12.1  192.168.12.2  NOTIFICATION Message
9   0.000246  192.168.12.2  192.168.12.1  39144 → 179 [ACK]
10  0.000255  192.168.12.2  192.168.12.1  NOTIFICATION Message
11  0.000343  192.168.12.2  192.168.12.1  39144 → 179 [FIN, ACK]
12  0.000561  192.168.12.1  192.168.12.2  179 → 39144 [FIN, ACK]
13  0.000569  192.168.12.2  192.168.12.1  39144 → 179 [ACK]

The whole attempt takes less than a millisecond. The TCP session comes up fine, both routers send an OPEN, both reject the other’s OPEN, and the connection is closed. The routers keep retrying every few seconds, and every attempt looks exactly like this one.

Packet walkthrough

OPEN from R2 (packet 4)

Border Gateway Protocol - OPEN Message
    Length: 104
    Type: OPEN Message (1)
    Version: 4
    My AS: 2
    Hold Time: 180
    BGP Identifier: 2.2.2.2
    Optional Parameters Length: 75
    Optional Parameters
        Optional Parameter: Capability
            Capability: Multiprotocol extensions capability
                AFI: IPv4 (1)
                SAFI: Unicast (1)
        Optional Parameter: Capability
            Capability: Route refresh capability
        Optional Parameter: Capability
            Capability: Enhanced route refresh capability
        Optional Parameter: Capability
            Capability: Support for 4-octet AS number capability
                AS Number: 2
        Optional Parameter: Capability
            Capability: BGP-Extended Message
        Optional Parameter: Capability
            Parameter Type: Capability (2)
            Parameter Length: 3
            Capability: BGP Role
                Type: BGP Role (9)
                Length: 1
                BGP Role: Provider (0)
        Optional Parameter: Capability
            Capability: Support for Additional Paths
        Optional Parameter: Capability
            Capability: PATHS-LIMIT Capability
        Optional Parameter: Capability
            Capability: FQDN Capability
                Hostname: R2
        Optional Parameter: Capability
            Capability: Graceful Restart capability

OPEN from R1 (packet 6)

Border Gateway Protocol - OPEN Message
    Type: OPEN Message (1)
    My AS: 1
    BGP Identifier: 1.1.1.1
        Optional Parameter: Capability
            Capability: BGP Role
                Type: BGP Role (9)
                Length: 1
                BGP Role: Provider (0)

Both routers claim to be the provider. If both sides are providers, each router thinks the other is its customer. It would add OTC to every route it sends, and then reject every route it receives as a leak, because routes from a customer must never carry OTC. RFC 9234 doesn’t allow that pair. These are the only valid combinations:

Local role	Remote role
Provider (0)	Customer (3)
Customer (3)	Provider (0)
Peer (4)	Peer (4)
Route Server (1)	Route Server Client (2)
Route Server Client (2)	Route Server (1)

NOTIFICATION: Role Mismatch (packets 8 and 10)

Border Gateway Protocol - NOTIFICATION Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 21
    Type: NOTIFICATION Message (3)
    Major error Code: OPEN Message Error (2)
    Minor error Code (Open Message): Role Mismatch (11)

Error code 2, subcode 11: OPEN Message Error / Role Mismatch, a new subcode that RFC 9234 added. Both routers detect the problem independently, so each sends its own NOTIFICATION (packet 8 from R1, packet 10 from R2).
Length 21: the minimum NOTIFICATION size: a 16-byte marker, 2-byte length, 1-byte type and the two error code bytes, with no data. The message doesn’t say which role it expected. You have to look at the OPEN messages (or the neighbor output) for that.
After a NOTIFICATION, BGP always closes the TCP connection. That’s the FIN exchange in packets 11-13.

On the router, the neighbor stays in Idle/Active and shows the reason:

R2# show bgp neighbors 192.168.12.1
  Local Role: provider
  Remote Role: undefined
  BGP state = Idle
    Notifications:          4          0
  Last reset 00:01:09,  Notification sent (OPEN Message Error/Role Mismatch)

The fix is to configure one side as local-role customer, or both as local-role peer, depending on the real business relationship.

What about a neighbor without a role?

A role mismatch only happens when both neighbors send a role. If one neighbor doesn’t support RFC 9234 and sends no BGP Role capability, the session comes up normally, but without role-based leak prevention. To reject neighbors that don’t send a role, FRRouting has neighbor X local-role provider strict-mode. In that case, the NOTIFICATION is OPEN Message Error / Role Mismatch as well.