Slide 1
Most trusted JOB oriented professional program
DevOps Certified Professional (DCP)

Take your first step into the world of DevOps with this course, which will help you to learn about the methodologies and tools used to develop, deploy, and operate high-quality software.

Slide 2
DevOps to DevSecOps – Learn the evolution
DevSecOps Certified Professional (DSOCP)

Learn to automate security into a fast-paced DevOps environment using various open-source tools and scripts.

Slide 2
Get certified in the new tech skill to rule the industry
Site Reliability Engineering (SRE) Certified Professional

A method of measuring and achieving reliability through engineering and operations work – developed by Google to manage services.

Slide 2
Master the art of DevOps
Master in DevOps Engineering (MDE)

Get enrolled for the most advanced and only course in the WORLD which can make you an expert and proficient Architect in DevOps, DevSecOps and Site Reliability Engineering (SRE) principles together.

Slide 2
Gain expertise and certified yourself
Azure DevOps Solutions Expert

Learn about the DevOps services available on Azure and how you can use them to make your workflow more efficient.

Slide 3
Learn and get certified
AWS Certified DevOps Professional

Learn about the DevOps services offered by AWS and how you can use them to make your workflow more efficient.

previous arrow
next arrow

Perforce Network Troubleshooting Guide | How to Resolve Perforce Network Issues?

perforce-network-troubleshooting-guide
Spread the Knowledge

perforce-network-troubleshooting-guide

1. netstat -a
Check to make sure that the server is running. netstat -a gives a list of all processes listening on network ports. Look for lines that contain “LISTEN” and “1666” (or whatever port you have Perforce running on.)  If you do not see such a line, the server is not running.

2. p4 -p 127.0.0.1:1666 info
Verify that the server accepts local connections using the localhost address from the server machine.
If you cannot connect check and make sure P4PORT is set to “1666” for the server. This ensures the server is listening on all interfaces.  Setting P4PORT to ‘localhost:1666’ will set it to only allow connections from the local machine.

Note:
Make sure that it is set properly with ‘p4 set -S Perforce P4PORT’ and if it’s not, set it:
p4 set -S Perforce P4PORT=1666

On Linux/Mac/Unix, instead of using ‘p4 set’, you can either set the environment variable $P4PORT or use the ‘-p’ flag to p4d:
p4d -r $P4ROOT -p 1666 [other flags]

3. ping server
Verify network connectivity by pinging the server from the client. If you cannot ping the server, then either ICMP is being blocked or there is a network issue outside of Perforce.

4. telnet <server> <port>
Verify that the server port is reachable by “telnet <server> <port>”. This can give you a descriptive error or confirm a connection. Note that on Windows servers the telnet utility might not be available by default; if it is not available, you can install it from your Programs and Features control panel item. In the sidebar there is a Turn Windows Features On or Off, select it and then check Telnet Client in the list. Click OK.

5. Check port filters/firewalls settings
If you still cannot connect, then verify the TCP/IP properties settings for any port filters/firewalls. If there is a firewall, make sure that incoming connections to port 1666 are permitted, and that all existing outbound connections are permitted (the latter is usually standard). On Windows machines, go to Control Panel -> Windows Firewall, click on Advanced Settings, and then click on Inbound Rules on the sidebar. Make sure p4d is enabled.

6. DNS is resolving the IP address correctly
Check to make sure that DNS is resolving the IP address correctly. Pinging by DNS name is quick verification. “nslookup <hostname>” or “dig <hostname>” can also work.

7. using the IP address
Run the Perforce command using the IP address instead of DNS name. If IP address works, suspect DNS resolution problems or an incorrectly spelled hostname. If IP address does not work, suspect a problem with either host table entries or routing or other network problems. The commands “route” and “arp -a” can be helpful in this regard.

8. If problem is intermittent, suspect hardware, interface configuration, or congestion problems. Tools such as fping and wireshark are useful for uncovering these sorts of errors.

9. tracert <perforce_server
Check for inordinate delays with the traceroute command “tracert <perforce_server>”. On linux, it is called “traceroute”.

Reference…
http://kb.perforce.com/article/905

Rajesh Kumar