SQLServer Resolution Protocol Packets Anatomy

SSRP (acronym for SQLServer Resolution Protocol) is a protocol defined by Microsoft and introduced long time ago with SQLServer 2000 to support multiple engine instances installations on the same server.

SQLServer client libraries leverages on SSRP to make easier find SQLServer in the network (using packet broadcasting/multicasting) and connect to a SQLServer Named or Clustered Istance endpoint trasparently.

SSRP is an application-layer protocol (OSI's stack Level 7) based on request/response UDP packets, 1434 port is assigned by Internationl Standards. It does not provide or support security, authentication and negotiation.

SSRP can be used to discover a single-istance SQLServer endpoint:

or multiple-istances SQLServer endpoints (broadcast/multicast):

SSRP communications are implemented by a client and a server: usually the client is a SQLServer client library like ADO.NET or JDBC and the server is a Database Server Discovery Service, commonly implemented in the SQLServer Broswer process (sqlbrowser.exe).

How it works SSRP?

It's quite straightforward: SQLServer Browser open a socket and listen on 1434 UDP port, clients send different types of UDP packets asking for SQLServer istances connection protocol information and the SQLBrowser reply or not with a specific UDP packet. SQLServer Browser read data about SQLServer istances configuration from registry hive.

Let's see what are the UDP packets allowed by SSRP and dissect them. My bisturi is Microsoft Network Monitor that's able to understand and make human readable SSRP packets. Just set Windows Parser Profile active in the options menu:

Start a network trace, type ssrp on the filter and apply to catch only SSRP messages:

 

Broadcast

Broadcast feature is used, for example, by SQLServer Management Studio to discover SQLServer istances on the network:

A 1 byte UDP packet CLNT_BCAST_EX is broadcasted to 255.255.255.255 ipv4 address:

SQLServer Browser listening on 1434 UDP port catch this message and reply with a variable lenght SVR_RESP message containing the list of available istances and and their network protocol connection information:

In the example above the response data contains only information about istance TCP/IP endpoint because is the only communication protocol configured on that istance, but SSRP support sending connection informations also for VIA (discontinued on 2012) and Named Pipes. Enabling Named Pipes on my SQLServer 2016 test istance the response data contained in the SVR_RESP packet is slightly different:

Named Instance resolution

SSRP is behind the automatic resolution of TCP port for named istances and is widely used by all SQLServer client libraries. In the example below Management Studio is connecting to a named instance called INST2016:

The client message involved in this mechanism is CLNT_UCAST_INST. When a SQLServer client library try to open a connection to a named istance first send a variable lenght CLNT_UCAST_INST message to resolve TCP port:

The SQLServer Browser reply always with a SVR_RESP message and act with the same behavior explained before.

Named Istance and DAC

DAC is the acronym for Dedicated Administrator Console and it's configured to listen on 1434 TCP port for default SQLServer installations. SSRP support port resolution also for DAC with a couple of UDP packets. As documented on technet:

"...the DAC avoids using a SQL Server Resolution Protocol (SSRP) request to the SQL Server Browser Service when connecting. It first connects over TCP port 1434. If that fails, it makes an SSRP call to get the port."

This is the case when DAC is not listening on standard 1434 TCP port, from SQLServer Error Log:

Connect using the admin prefix using SQLServer Management Studio:

The client send a variable lenght CLNT_UCAST_DAC message, containing the instance name:

The SQLBrowser reply with a SVR_RES_DAC message:

The right DAC TCP port is inside the response data and of course match with the Error Log entry above.