Lesson Contents
This packet capture shows BGP Roles and the Only to Customer (OTC) attribute from RFC 9234 on the wire. Two VyOS routers (FRRouting) peer over eBGP: AS 1 is the provider, AS 2 is the customer. Each router announces its role in the OPEN message, and routes the provider sends down to its customer are marked with OTC. That mark is what stops a customer from leaking those routes to other providers, without any route-maps.
The BGP route leaking lesson explains route leaks and where roles fit in, and BGP messages covers the OPEN, UPDATE and NOTIFICATION messages you’ll see here. To see what happens when the roles don’t match, look at the BGP Role Mismatch Packet Capture. 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 | vyos-bgp-roles-otc.pcapng |
| Packets | 10 |
| Protocol | BGP-4 with BGP Role capability (code 9) and OTC path attribute (type 35), RFC 9234 |
| Transport | TCP 179 |
| Devices | VyOS (FRRouting): AS 1 / 1.1.1.1 provider (192.168.12.1), AS 2 / 2.2.2.2 customer (192.168.12.2) |
| Wireshark filter | bgp, bgp.cap.role or bgp.update.path_attribute.otc |
Packets in this capture
No. Source Port Destination Port Info
1 192.168.12.2 179 192.168.12.1 37600 OPEN Message
2 192.168.12.2 52248 192.168.12.1 179 OPEN Message
3 192.168.12.1 179 192.168.12.2 52248 OPEN Message
4 192.168.12.1 37600 192.168.12.2 179 OPEN Message
5 192.168.12.2 179 192.168.12.1 37600 NOTIFICATION (Cease / Connection Collision Resolution)
6 192.168.12.1 37600 192.168.12.2 179 NOTIFICATION Message
7 192.168.12.1 37600 192.168.12.2 179 NOTIFICATION Message
8 192.168.12.2 52248 192.168.12.1 179 UPDATE Message, UPDATE Message
9 192.168.12.1 179 192.168.12.2 52248 UPDATE Message (OTC), UPDATE Message
10 192.168.12.1 179 192.168.12.2 52248 UPDATE Message (OTC)The capture starts after the TCP handshakes, so Wireshark marks some segments with “ACKed unseen segment”. That’s expected and doesn’t affect the BGP messages.
Packet walkthrough
OPEN messages with the BGP Role capability (packets 1-4)
This is the customer’s OPEN message:
Border Gateway Protocol - OPEN Message
Type: OPEN Message (1)
Version: 4
My AS: 2
Hold Time: 180
BGP Identifier: 2.2.2.2
Optional Parameters Length: 72
Optional Parameters
Optional Parameter: Capability
Capability: Multiprotocol extensions capability
AFI: IPv4 (1)
SAFI: Unicast (1)
Optional Parameter: Capability
Capability: Route Refresh Capability (Cisco)
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: Customer (3)
Optional Parameter: Capability
Capability: Support for Additional Paths
Optional Parameter: Capability
Capability: FQDN Capability
Hostname: vyos
Optional Parameter: Capability
Capability: Graceful Restart capability
Optional Parameter: Capability
Capability: Long-Lived Graceful Restart (LLGR) CapabilityAnd this is the BGP Role capability in the provider’s OPEN message:
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)- Capability code 9, length 1: the BGP Role capability is a single byte with one of five values: 0 Provider, 1 Route Server, 2 Route Server Client, 3 Customer, 4 Peer.
- Provider (0) and Customer (3): a valid pair. The allowed pairs are Provider-Customer, Customer-Provider, Peer-Peer, RS-RS-Client and RS-Client-RS. Any other combination is a role mismatch, and the session is rejected with a NOTIFICATION.
- The role is configured per neighbor. On FRRouting/VyOS it’s
neighbor X local-role provider|customer|peer|rs-server|rs-client, optionally withstrict-mode, which also rejects neighbors that don’t send a role at all.
Connection collision (packets 1-7)
Look at the ports: there are two TCP sessions. 192.168.12.1 connected from port 37600 to 179, and 192.168.12.2 connected from port 52248 to 179. Both routers started a session at the same moment, so each side sent an OPEN on both connections.
BGP keeps one of them. RFC 4271 says to keep the connection that was opened by the router with the higher BGP Identifier. 2.2.2.2 is higher than 1.1.1.1, so the session 2.2.2.2 opened (port 52248) survives. The other one is closed with a NOTIFICATION:
Border Gateway Protocol - NOTIFICATION Message
Type: NOTIFICATION Message (3)
Major error Code: Cease (6)
Minor error Code (Cease): Connection Collision Resolution (7)This isn’t an error. You’ll see it in real networks whenever two neighbors connect at the same time. It has nothing to do with BGP roles.
Customer to provider: no OTC (packet 8)
Border Gateway Protocol - UPDATE Message
Type: UPDATE Message (2)
Withdrawn Routes Length: 0
Total Path Attribute Length: 28
Path attributes
Path Attribute - ORIGIN: IGP
Path Attribute - AS_PATH: 2
Path Attribute - NEXT_HOP: 192.168.12.2
Path Attribute - MULTI_EXIT_DISC: 0
Network Layer Reachability Information (NLRI)
2.2.2.2/32
Border Gateway Protocol - UPDATE Message
Type: UPDATE Message (2)
Withdrawn Routes Length: 0
Total Path Attribute Length: 0The customer advertises its own prefix 2.2.2.2/32 to its provider without an OTC attribute. Routes sent “uphill” to a provider never get OTC, because a provider may advertise customer routes to everyone.
The second UPDATE is empty: no withdrawn routes, no attributes, no NLRI. That’s the End-of-RIB marker (RFC 4724). It tells the neighbor “this is everything I have for IPv4 unicast”.
Provider to customer: OTC added (packet 9)
Border Gateway Protocol - UPDATE Message
Type: UPDATE Message (2)
Withdrawn Routes Length: 0
Total Path Attribute Length: 35
Path attributes
Path Attribute - ORIGIN: IGP
Path Attribute - AS_PATH: 1
Path Attribute - NEXT_HOP: 192.168.12.1
Path Attribute - MULTI_EXIT_DISC: 0
Path Attribute - OTC: 1
Flags: 0xc0, Optional, Transitive, Complete
1... .... = Optional: Set
.1.. .... = Transitive: Set
Type Code: OTC (35)
Length: 4
Only to Customer: 1
Network Layer Reachability Information (NLRI)
1.1.1.1/32- OTC, type code 35, optional transitive: a 4-byte AS number. Routers that don’t support RFC 9234 still pass it on because it’s optional transitive. They only set the Partial flag, and the AS number in it stays the same.
- Only to Customer: 1: when a router sends a route to a customer (or a peer or RS client) and the route has no OTC yet, it adds OTC with its own AS number. AS 1 marks 1.1.1.1/32 as “only for customers, from AS 1”.
- Why this stops leaks: AS 2 is now not allowed to send this route to its other providers or peers. Routes with OTC may only go down to customers. If AS 2 leaks it anyway, the next AS sees an OTC from a customer or a non-matching OTC from a peer, and drops the route as a leak.
The customer’s own route comes back with OTC (packet 10)
Border Gateway Protocol - UPDATE Message
Path attributes
Path Attribute - ORIGIN: IGP
Path Attribute - AS_PATH: 1 2
Path Attribute - NEXT_HOP: 192.168.12.1
Path Attribute - OTC: 1
Network Layer Reachability Information (NLRI)
2.2.2.2/32The provider advertises 2.2.2.2/32 back to the customer that sent it, with AS path “1 2” and OTC 1. FRRouting doesn’t suppress this by default. The customer drops the route anyway, because its own AS 2 is in the AS path (normal eBGP loop prevention).