Showing posts with label Networking. Show all posts
Showing posts with label Networking. Show all posts

Monday, February 6, 2012

The CompTIA Network+ exam

I recently wanted to brush up on my networking knowledge so decided to have a go at the CompTIA Network+ certification.  The CompTIA Network+ exam is technology agnostic (it doesn't get hung up on CISCO details) and reasonably straighforward.  You don't need any sys admin experience (or any prior certifications) just a bit of technical know how, some study and you'll be fine.

In my own case, my background is software engineering and technical architecture.   I have never worked as a sys admin and never will - I am pretty sure a good sys admin would  find this certification too easy.  So, if you are in a similar boat you may be asking what is the benefit of putting the time into attempting this certification?

Some reasons...

Reason 1: Protocols

In every architecture (especially a J2EE / JEE one) you don't just have a range of software protocols (e.g. RMI, JDBC) you usually have an array of classical network protocols:  TCP, DHCP, DNS, HTTP,  HTTPS etc. And depending on what your architecture is trying to do you'll more than likely have a few more.  For example, if you're sending / receiving emails you'll be talking mail server, SMTP, POP3 and IMAP; if you have some Voice over IP, you'll be talking SIP and RTP.  Having a good understanding of every protocol that does something in your architecture is as important as understanding every component in your architecture.  It's all part of the same jigsaw.

Reason 2: IP
 
In your deployment, as you start to scale and start adding more servers to your architecture understanding things like IP addressing mechanisms, subnetting, private IPs, static IPs,  APIPA, Autonomous systems, WINS, Default gateways, broadcast addresses, NAT, DHCP scopes,  etc. becomes important.   Even if you are not scaling, you may want to do something like put your REST services under their own domain name in the same way Dropbox (http://api.dropbox.com) and Twitter (http://api.twitter.com/) do.  Understanding how to do this and how to get the benefits from it require some networking knowledge.  For example, you may decide to use different TTL values for your REST domain name than for the rest of your architecture.

Reason 3: Security

The Network + certification contains plenty of interesting stuff from a security perspective:
  • The difference between stateless and stateful firewalls. Stateful Firewalls remember your session and can have more sophisticated rules based on its knowledge of previous requests from the same session.
  • The various wireless encryption standards (WEP is awful, WPA2 is good).
  • The various attacks that can happen to your network, DoS, Smurf etc.
  • RADIUS, TACACS+ and Kerberos protocols
  • Understanding that FTP, Telnet, RSH, RCP, SNMP v1/2 are unsecure
  • Understanding that SSH, SNMPv3, SFTP, SCP are secure.
  • Intrustion protection scanners and Intrustion detection scanners - what they do and when to use them.
  • Port scanners - useful for seeing which ports are open. Try angry ip scanner
  • Packet sniffers - useful for lots of things. Have a go with wireshark
  • IPSec - the only IP encryption protocol to work at layer 3. It encrypts both header and payload.
Reason 4: Performance

From a performance perspective:
  • Wireless network speeds - 802.11n is way faster (up tp 400 Mbps) than 802.11g (54 Mbps) which many networks are still on.
  • Optic fibre options and types- single mode supports much longer distances than multimode. 
  • Bandwidth for various ethernet cables types. For example 1000BaseT has a speed of 1 GB/s and must use Cat 5e / 6 cable. It has a distance of only 100M. 
  • Methods to guarentee or increase bandwith for users and applications - Traffic shaping and QoS
Reason 5: Network commands

Some network commands are well known and obvious to all of us. For example: PING.  But, do you know how do to set buffer size for your ping request? (It's PING -l). Or that PING will give you idea of network hops from the TTL value returned?  Or what protocol is required for ping to work? (It's ICMP). Is this any relevance?  Well it may not be. But, it might help you.  For example, by default you can't PING an Amazon EC2 instance because - by default -  Amazon disable ICMP for its EC instances.  Now that might be useless information, or it might save you a painful 2 hours some day!

The Network+ certification  also contains some good stuff on commands that aren't so obvious.  This includes DIG and MTR . The former is useful for diagnosing DNS problems and gives a little bit more than NSLOOKUP; the latter (MTR) is a sort of combination of TRACEROUTE and PING.

Exam preparation

To study for this exam, I read the CompTIA Network+ book by Mike Meyers and went through all the Network+ training videos from Professor Messer - these are free and really good.  The exam contains 100 multiple choice questions that have to be answered in 90 minutes.  In comparison to any Java certification, that's a lot more questions.  Most of the questions are reasonably straight forward however, the pass mark is 80% which is a lot higher than most other industry standard certifications - so it's not that easy a certification.  Regarding cost, well at exchange rates of the time I did the exam (Feb 2012), the damage to the credit card was €263.00.  I sat the exam at the New Horizons exam centre on Strand Street Great, Dublin 1.  Good set up there.

Summary

So in summary, the Network+ exam will not turn you into a Sys admin genius. Some of the questions are easy, some are just a matter of brushing up on what you probably already knew and other parts you'll learn something new.  As with every certification, there are the proverbial bits of irrelevant stuff - things you have to learn for the exam and probably never need again.  This can be a pain.  However, there are also many good things that can be learnt.  I have tried to outline some of them here.  Please feel free to add a comment below or contact me if you have any questions

Sunday, April 17, 2011

SMTP

Simple Mail Transfer Protocol (SMTP) is text based protocol for sending emails across the Internet. It grew for the need for different systems needing to communicate with each other.

A SMTP transactions consists of three command / reply sequences. They are:
  1. MAIL command. Establishes return address.
  2. RCPT command. Establishes recipient of message.
  3. DATA content of the message.
(Note: SMTP commands usually consist of four characters others are HELO and EHLO).

The Server responds to these commands uses status codes. The responses are positive (2xx reply codes) or negative. Negative replies can be permanent (5xx codes) or transient (4xx codes)

What is the difference between SMTP and POP and IMAP?

SMTP is really for sending messages. It cannot pull messages from a remote server on demand. You wanna read those messages sent to you that are on your email server. You need to use either the Post Office Protocol (POP) or Internet Message Access Protocol (IMAP).

So you wanna try it?

Ok, so you're sick of using email tools such as outlook for sending email messages. You wanna send your own messages?
  • Open a command prompt.
  • Type "telnet 25".
  • Talk to the server using SMTP.
SMTP and Web Services

It is possible to have Web Services over SMTP instead of HTTP. But it's more complex. Why? Because SMTP does not provide much flexibility to responses for requests. With HTTP a SOAP request message can be put into the HTTP message body. Similar a SOAP message can be put in the HTTP message body for a response. SMTP allows a SOAP message to be easily attached to the request. But not the response. A separate SMTP is required for the response.

So why why why would you ever want to use SMTP for sending SOAP messages? It might be:
  • You cannot use HTTP because of firewalls
  • The request / response model isn't desired by your application. You might just want something like publish / subscribe
  • You web services are take a long time to run and you don't want situations where HTTP will time out on you.


References:

  1. RFC 821
  2. RFC 2821
  3. SMTP inside and out
  4. Web Services over SMTP
  5. WSDL 1.1 spec