Freigeben über

Clear the way - MSMQ coming through

  • Artikel

[[Edited Ping information - 20th May 2008]]

A reasonably common question is "what ports does MSMQ use?" Usually the infrastructure guys have their routers locked down tight and want to open up only the bare minimum to let your new MSMQ application through. The problem can be in understanding what the different ports that MSMQ uses are actually for.

First, MSMQ operates in two distinct ways to move data:

  1. Pushing messages
  2. Pulling messages

and each uses a completely different protocol.

Pushing messages

This uses the MSMQ protocol which operates over TCP port 1801. You need this port open at a bare minimum if you want to send messages. MSMQ uses this port to first establish a network session to a destination and then send the messages. If only this port is open then independent clients will not be able to contact domain controllers and messages are then limited to using a direct format name without any routing capability.

Pulling messages

RPC is used for this operation which requires access through TCP ports 135, 2103 and 2105. First the client makes an RPC call over port 135 to determine which ports MSMQ is listening on for RPC-based remote reads. Then the client makes the RPC call to ports 2103/2105 to read the message. (Note that these two port numbers may be incremented by 11 if they are already in use when MSMQ starts up.)

Additional port usage 
  • Active Directory
    • Global Catalogue
  • MSMQ Ping
  • Server discovery
  • Remote management

It may be necessary for the client to contact Active Directory, such as when creating public queues or sending messages without direct format names, and the ports required are version-specific:

  • Client is MSMQ 2.0 and earlier
    The domain controller requires down-level client support installed which listens for RPC traffic on TCP ports 135 and 2101. (Note that port 2101 may be incremented by 11 if it is already in use when MSMQ starts up.)
  • Client MSMQ 3.0 and later
    The domain controller requires no extra support and natively listens for LDAP traffic on TCP port 389 (and TCP port 3268 if the DC is also a global catalogue).  

Note: none of the Active Directory ports (2101, 389, 3268) will be required if MSMQ is running in Workgroup mode.

The internal "ping" mechanism for Message Queuing operates over UDP port 3527. MSMQ uses this to optimise establishing the session so blocking the port is not critical but may cause an initial delay of six seconds. (Note that according to the IANA port list, Veritas (now Symantec) use port 3257 for Backup Exec Server but this can be changed to avoid a port conflict)

Independent clients use UDP port 1801 to multicast a server discovery broadcast.  

MSMQ listens on port 2107 for RPC calls to remote management APIs. (Note this is MSMQ 3.0 onwards so not always mentioned in the older documentation.)

References

178517 TCP ports, UDP ports, and RPC ports that are used by Message Queuing
183293 How To Configure a Firewall for MSMQ Access
832017 Service overview and network port requirements for the Windows Server system

Comments

  • Anonymous
    May 20, 2008
    "The internal "ping" mechanism" Hello, while investigating possible missing messages I noticed 3527 UDP failures in network monitor captures. We push messages using direct names on private queues. We allow our MSMQ clients to any port but only TCP through a F5 load balancer. Therefore UDP fails. Before I look at changing F5 is there any deeper detail available on benefits of pinging. We do not see any delays. Thanks Gary

  • Anonymous
    May 20, 2008
    Hi Gary, there isn't really much to it. The MSMQ FAQ document (link on the left) says (in section 18.1 "How are messages delivered to a remote computer?"): "• Ping the other computer (over UDP port 3527), and then wait up to one second for a reply. The remote side replies with another UDP packet, signaling that it is ready to accept a session. ... Ping is used only for the first time Message Queuing tries to establish a session." You are not seeing any delays as MSMQ will only wait a second for initiating the TCP connection.

  • Anonymous
    May 20, 2008
    24 40.468191 LOCAL remote UDP Src Port: Unknown (1037); Dst Port: Unknown (3527); Length = 32 (0x20) LIVEVM35 MSMACHINE IP 25 0.000000 remote LOCAL ICMP Destination Unreachable: 10.0.3.202  (See frame 24) MSmachine LIVEVM35 IP 26 6.008640 LOCAL remote TCP Control Bits: ....S., len:    0, seq:3725120085-3725120086, ack:         0, win:65535, src: 1847  dst: 1801 LIVEVM35 MSMACHINE IP John, I believe its 6 seconds. Above I managed to catch a outgoing queue start with a message waiting while hitting refresh on computer manager. The other guy suggests so as well... http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=859495&SiteID=1. All my other captures today also show ping...wait 6...create tcp session. Not a great concern to me as our system is not considered (nearly) real time. May raise it with F5 community. Thanks Gary

  • Anonymous
    May 20, 2008
    I have conflicting information from the same source (one second and several seconds) so I think I'll ignore that and go with your evidence of six. I don't expect you to see any performance issues apart from the initial conection delay.

  • Anonymous
    July 10, 2008
    I'm now into full swing looking at MSMQ 4.0 on Windows Server 2008 using Virtual Server. I haven't got