Asking for Help Online

By stretch | Thursday, February 17, 2011 at 3:30 a.m. UTC

A few weeks ago I wrote an article on Supplementary Study Resources, which discusses sources of information beyond textbooks, including discussion forums and other interactive sources. Along a similar line of thought, today's post offers some guidance for asking questions on large public forums. For many readers, all of the below will be common sense. The advice is targeted primarily at two audiences:

  • People who are new to the field
  • People who can't figure out why no one replies to their questions

My advice is broken into simple dos and don'ts, with illustrative examples where appropriate.


Don't be clingy

Can someone help me configure EIGRP?

This is probably the most common error I see people make. Understand that any support for which you have not paid is ad-hoc and best effort; in other words, there is no guarantee you will be helped. And if someone does help, there is no guarantee that he or she will continue to help until the problem has been solved to your satisfaction.

Very few people are willing to offer themselves as a dedicated point of contact as you work through an issue. Don't specifically ask for someone to volunteer their services. Simply state your problem (be specific); if someone has the time and inclination to assist, they will.

Don't claim urgency


If it was actually urgent, you'd be paying someone to help you fix it right now, not making a forum post or chatting on IRC. Claiming undue prioritization implies that the time of others isn't as important as yours, and isn't going to get you any help.

Also, never capitalize your entire thread title when posting on a forum. It's simply poor netiquette.

Don't play chat tag

When conversing via IRC or some similar real-time chat, only ask questions when you have the time and energy to engage in conversation. Typically, other people will need you to provide more information to help you; don't simply paste your question into IRC, go to lunch, then come back and expect anyone to still be interested (or even remember your question).

If you want to put a question out there, but don't have time to respond to follow-up inquiries immediately, post on a discussion forum or mailing list instead.

Don't double-post

When posting on a forum, post only once. Don't duplicate your post across multiple message boards. It's annoying and unnecessary. Further, it demonstrates an absence of basic understanding with regard to forum etiquette, which will only discourage others from responding.

Don't pretend you know more than you do

Hey guys, first off I just want to say I've been a techie for over ten years, I have a dozen certifications, and I make six figures so I'm definitely not a noob. I'm just trying to figure out what this little light blue cable that came with this router is for.

People who make inflated claims seldom realize how transparent they are. Or how hard everyone else is laughing.

Don't ask for things you know you shouldn't

Generally speaking, this includes but is not limited to asking for:

  • Pirated books or software
  • Answers to your homework
  • Certification test questions (braindumps)
  • Help hacking into your ex-girlfriend's Facebook account

A helpful rule of thumb for those with under-performing consciences: if you wouldn't ask the question in front of a crowd in person, don't ask it online.


First ask yourself how someone else would know the answer

Does an 1841 support MPLS?

There are two general types of questions that people ask: objective (dealing in absolutes) and subjective (dealing in individual experiences). The majority of technical questions are objective in nature: "Does model A support feature B?", "How do I configure C?", etc. Subjective questions deal more with opinion and experience: "How does model X compare with model Y?", "Should I enable feature Z?"

How do you suppose someone else would find the answer to the question above regarding MPLS support on Cisco 1841 routers? Clearly it's an objective question. The answer is easily researched in vendor documentation yourself; there is no excuse to ask someone else to do the work for you. Even if you don't know where to locate said documentation, the question should at least be rephrased, "How can I determine whether an 1841 supports MPLS?" You'll find people are far more willing to loan you a fishing rod than to catch you a fish.

Provide sufficient detail and context

Why doesn't NAT work on my router?

How would you expect anyone not standing over your shoulder to answer such a vague question? Details are invaluable things, and the more you provide the better your chance of receiving a productive response will be.

Include your configurations where applicable

The first reply in many, many forum threads is "Please post your configs." Rather than waiting for someone to ask, go ahead and attach sanitized configs (whole or partial, depending on the scope of the topic) along with your initial post. And don't simply dump configuration text into the post body: Remember to enclose configuration snippets in code blocks for easy readability. Attach long configs as separate text files.

Show your work

This is by far one of the most beneficial ideals you can include in a solicitation for help. Always remember to include the steps you've already taken on your own when requesting assistance. Consider the following two posts:

Guys, I can't get two routers to establish a BGP adjacency. What could be the problem?

Guys, I can't get two routers to establish a BGP adjacency. I've verified that they're both configured with the correct AS numbers and peer addresses. No authentication is in use. show ip bgp summary shows that the adjacency is getting stuck in active mode. I've attached a packet capture taken from the link if that helps. Any ideas?

The second post is far more likely to attract interest, because the author has demonstrated initiative in excluding some common mistakes prior to posting and in providing a packet capture for others to inspect. You want to write posts like the second one.

Provide closure

Finally, if you come upon a solution to your problem, be sure to return to your initial query and record the solution. The benefits of this are three-fold:

  • You provide a sense of closure and appreciation for the people who helped.
  • You provide potential help for others with your same problem who come across the post via Google.
  • You have ad hoc documentation of the resolution for your own purposes should the problem recur months or years in the future.

About the Author

Jeremy Stretch is a network engineer living in the Raleigh-Durham, North Carolina area. He is known for his blog and cheat sheets here at Packet Life. You can reach him by email or follow him on Twitter.

Posted in Opinion


February 17, 2011 at 4:12 a.m. UTC

That's a great article Jeremy! I might have to link or quote you over on the discussion forums that I help moderate.

I would also add one point... if you are posting in a forum or blog make sure you subcribe to the post or comments. There's nothing more exacerbating for someone to spend the time replying when the original poster never bothers to come back and read the response(s).

Thanks for sharing!

erickbe (guest)
February 17, 2011 at 5:03 a.m. UTC

Good article. You should probably expand on sanitized configs for the new people also.

Jens Link (guest)
February 17, 2011 at 9:12 a.m. UTC
February 17, 2011 at 12:03 p.m. UTC

For me a couple things count towards my inclination to help in a forum:

1.) All of the above. :)

2.) Neatness counts. You might not be a native English speaker - if so, say so, and I'll give you some slack. But if not, then use proper punctuation, grammar, and above all spelling. Look through your post for mistakes before sending. Using proper case, spelling, and punctuation makes text that's often difficult to read, easier.

3.) Don't speak 1337. I am a professional with a family. I have much, much more important things to do than to try to figure out what the ... you're saying because you're so 1337.

4.) Be courteous. Be extra courteous, since I can't see your body language.

5.) It's FINE to capitalize a word for emphasis when nothing else (italics, bold, etc.) are available. ITS NOT FINE TO CAPITALIZE EVERYTHING ... THIS IS YELLING. YELLING = auto ignore.

6.) Personally, a common smiley here and there is ok to coummicate sarcasm, frustration, kidding, etc. Don't over do it. :P

Thanks Stretch - great post as usual.

Steve Occh (guest)
February 17, 2011 at 1:48 p.m. UTC

Chances are if they are smart enough to ask a precise question and provide packet captures they should be knowledgeable to figure it out themselves.

imMute (guest)
February 17, 2011 at 1:57 p.m. UTC

This is probably the most common error I see people make. Understand that any support for which you have not paid is ad-hoc and best effort; in other words, there is no gaurantee you will be helped. And if someone does help, there is no guarantee that he or she will continue to help until the problem has been solved to your satisfaction.

This is a personal pet peeve. I idle around in a little less than a dozen IRC channels and I see people using IRC as if it were a paid support service.
IRC should be for tossing out non-critical ideas (such as that BGP issue you mentioned) and the extra pair of eyes that is oh-so-useful.

February 17, 2011 at 3:02 p.m. UTC

@Steve: I disagree. Performing a packet capture is mind-numbingly simple, whereas many more advanced technologies are certainly not.

JL (guest)
February 17, 2011 at 3:16 p.m. UTC

Great post, there is a typo "gaurantee" ;)

Steve (guest)
February 17, 2011 at 3:28 p.m. UTC

I've always wondered what that light blue cable is too... :)

Great post Jeremy.

Porkchop (guest)
February 17, 2011 at 4:17 p.m. UTC

One more, very related: In IRC, even for short configs, use a service like Never paste your config into the channel.

February 17, 2011 at 5:30 p.m. UTC

Further to the point about "ask yourself how someone else would know the answer", it's terribly annoying when someone posts a question on a forum that has already been answered somewhere else in the forum (often several times).

If a site or a forum doesn't have a built in search feature, Google is your friend. Include


in your Google searches and Google will only search pages on that site. For example:

VoIP bandwidth

would give you search results for documents about calculating VoIP bandwidth and

VoIP bandwidth

would lead you to posts by Jeremy about VoIP bandwidth, as well as any posts or comments in the PacketLife forums that contain these keywords.

February 18, 2011 at 11:58 a.m. UTC

Also nice to give a feedback on a solution. If it is good or doesn't work, give a feedback. This encourages other people to help you. Don't keep silence.

February 19, 2011 at 6:45 p.m. UTC

No mention of hijacking? ;)

Thx for the good read!

Roger & CCIE Blog (guest)
February 25, 2012 at 7:56 p.m. UTC

Very relevant post, the key to getting your forum post answered is to just ask a sensible question with relevant information.

I am always happy to try an help anybody if I fell they have at least tried to do a bit of troubleshooting themselves first.

There is a whole load of engineers now if they can't google the answer don't know what to do!


March 21, 2012 at 2:30 p.m. UTC

There are situations in our life when we all need help.But!Very important is to know HOW to ask for help.Especially, if you are asking people online.I think this atricle is very useful, because it says how to do that right.I agree that you shouldn't demand to help you in case you don't pay for this.So you should be polite and don't pretend that you know everything and count all your certifications.If you need financial help you can use such service as
payday advance loans ,if you ask people questions or ask to help you,you should ask reasonable questions and be patient.

Heather (guest)
January 15, 2016 at 5:24 a.m. UTC

Thanks for this article. Can I suggest 2 Hands. Org as a place to safely ask for help online? I wad helped through them 2 years ago and then I was able to help 2 families this last Christmas.

Comments have closed for this article due to its age.