You can configure a network interface from the command line using the networking utilities. You configure your network client hosts with the command line by using commands to change your current settings or by editing a number of system files.

Configuring DHCP address for your network card

If you want to configure DHCP address you need to edit the /etc/network/interfaces and you need to enter the following lines replace eth0 with your network interface card

sudo vi /etc/network/interfaces

# The primary network interface – use DHCP to find our address
auto eth0
iface eth0 inet dhcp

Configuring Static IP address for your network card

If you want to configure Static IP address you need to edit the /etc/network/interfaces and you need to enter the following lines replace eth0 with your network interface card

sudo vi /etc/network/interfaces

# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.3.90
gateway 192.168.3.1
netmask 255.255.255.0
network 192.168.3.0
broadcast 192.168.3.255

After entering all the details you need to restart networking services using the following command

sudo /etc/init.d/networking restart

Setting up Second IP address or Virtual IP address in Ubuntu

If you are a server system administrator or normal user some time you need to assign a second ipaddress to your Ubuntu machine.For this you need to edit the /etc/network/interfaces file and you need to add the following syntax.Below one is the only example you need to chnage according to your ip address settings

sudo vi /etc/network/interfaces

auto eth0:1
iface eth0:1 inet static
address 192.168.1.60
netmask 255.255.255.0
network x.x.x.x
broadcast x.x.x.x
gateway x.x.x.x

You need to enter all the details like address,netmask,network,broadcast and gateways values after entering all the values save this file and you need to restart networking services in debian using the following command to take effect of our new ipaddress.

After entering all the details you need to restart networking services using the following command

sudo /etc/init.d/networking restart

Setting your ubuntu stytem hostname

Setting up your hostname upon a ubuntu installation is very straightforward. You can directly query, or set, the hostname with the hostname command.

As an user you can see your current hostname with

sudo /bin/hostname

Example

To set the hostname directly you can become root and run

sudo /bin/hostname newname

When your system boots it will automatically read the hostname from the file /etc/hostname

If you want to know more about how to setup host name check here

Setting up DNS

When it comes to DNS setup Ubuntu doesn’t differ from other distributions. You can add hostname and IP addresses to the file /etc/hosts for static lookups.

To cause your machine to consult with a particular server for name lookups you simply add their addresses to /etc/resolv.conf.

For example a machine which should perform lookups from the DNS server at IP address 192.168.3.2 would have a resolv.conf file looking like this

sudo vi /etc/resolv.conf

enter the following details

search test.com
nameserver 192.168.3.2

Network Troubleshooting Tips

Networking is sometimes considered to be complex, and hard to troubleshoot and manage. However, Linux provides you with Some tools to figure out exactly what’s going wrong on your network, and how to fix it.Here we are going see some tools and how to check the network connectivity.

Ping

Ping is a computer network tool used to test whether a particular host is reachable across an IP network. Ping works by sending ICMP “echo request” packets to the target host and listening for ICMP “echo response” replies (sometimes dubbed “Pong!” as an analog from the Ping Pong table tennis sport.) Using interval timing and response rate, ping estimates the round-trip time (generally in milliseconds although the unit is often omitted) and packet loss (if any) rate between hosts.

This is very basic and powerful tool to check Internet connection

Example

ping -c 4 google.com

-c option is used to pass how many packets you’re sending

If everything working file you should get reply looks like below

Pinging www.l.google.com [64.233.183.103] with 32 bytes of data:

Reply from 64.233.183.103: bytes=32 time=12ms TTL=244
Reply from 64.233.183.103: bytes=32 time=12ms TTL=244
Reply from 64.233.183.103: bytes=32 time=12ms TTL=244
Reply from 64.233.183.103: bytes=32 time=12ms TTL=244

Ping statistics for 64.233.183.103:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 12ms, Maximum = 12ms, Average = 12ms

Traceroute

traceroute is a computer network tool used to determine the route taken by packets across an IP network. An IPv6 variant, traceroute6, is also widely available.Very useful to trace IP packets.

Example

traceroute google.com

ifconfig

The Unix command ifconfig can function as a tool to configure a network interface for TCP/IP from the command line interface (CLI).This is another easy tool to see if your interface is actually loading correctly.

Example

ifconfig

eth0 Link encap:Ethernet HWaddr 00:0A:E6:C6:07:85
inet addr:132.18.0.16 Bcast:132.18.0.255 Mask:255.255.255.0
inet6 addr: fe80::20a:e6ff:fec6:785/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:18458 errors:0 dropped:0 overruns:0 frame:0
TX packets:8982 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:4015093 (3.8 MiB) TX bytes:1449812 (1.3 MiB)
Interrupt:10 Base address:0xd400

Route

This is very useful to check routing config

Example

route -n

Netstat

If you want to see Routing Tables,all open ports,all listen ports

netstat -nr

-n means return numeric output (ie, IP address instead of hostname)

-r means print the routing table

find all open ports

netstat -a

find listening ports

netstat -l

http://www.debianadmin.com/ubuntu-networking-for-basic-and-advanced-users.html

open a terminal and enter:
1. sudo apt-get install traceroute (to install the packages you need)
2. traceroute domain or IP (traceroute namhuy.org or traceroute yourdomain.com

NAME

       traceroute - print route IP packets follow going to a remote host

SYNOPSIS

       traceroute [ options ] host [ size ]

DESCRIPTION

       Traceroute  attempts  to  trace  the route an IP packet follows to some
       internet host.  It finds  out  intermediate  hops  by  launching  probe
       packets  with a small time-to-live (TTL) value, and then listens for an
       ICMP reply of time exceeded from an  intermediate  router.   Traceroute
       starts  probing  with a TTL of one, and increments by one until an ICMP
       port unreachable reply is received.  This means the  probe  either  got
       through to host, or hit the maximum TTL.

       host  is  the only mandatory argument, and specifies the target system,
       either as an IP address, or as a host name.  Parameter size  determines
       the size of the probe packets in bytes.

OPTIONS

       -a     Abort after 10 consecutive hops without an answer.

       -d     Turn  on  socket level debugging.  This option is only available
              to the super-user (root).

       -m max_ttl
              Set the maximum time-to-live (TTL) value that will be  used  for
              probing.  Hosts that are farther than max_ttl hops away will not
              be traced (default 30).

       -n     Report only IP addresses, but no hostnames.

       -p port
              Start  probing  at  an  alternate  UDP  port  (default   33434).
              Traceroute by default sends out UDP packets with increasing port
              numbers starting at port, and listens for ICMP  errors  returned
              from  remote  hosts.  This scheme only works if there are no UDP
              servers listening on the probed hosts in the range from port  to
              port + max_ttl.

       -q n   Send  out  n  queries  for  each  TTL  (each  intermediate host)
              (default 3).

       -r     Set Dont Route option, advising routers to drop the packets.  In
              other words, only probe within the local subnet.

       -s addr
              Set  source address of outgoing packets to addr, given either as
              numeric IP address, or as hostname.

       -t tos Set  the  type-of-service  field  in  the  outgoing  IP  packets
              (default 0).  tos is valid in the range of 0 to 255.

       -u     Use microsecond timestamps.

       -v     Turn on verbose output.

       -w wait
              Set  timeout for replies to wait seconds (default 5 sec).  If no
              ICMP reply is received within wait after a packet has been  sent
              out, the probe is considered as failed.

       -A     Report  the Autonomous System Number (ASN) at each hop.  Roughly
              speaking, the ASN tells which administration a router is subject
              to.   See  RFC 1930 for all the details, and section ENVIRONMENT
              below on how to fine tune the lookup.

       -I proto
              Send out probe packets using IP protocol proto, given either  as
              name  or  numerical  value  (default  UDP).   Some features like
              parallel probing are only available when using UDP.

       -M     Determine the maximum transfer unit (MTU) along the  path.   See
              RFC 1191 for details.

       -O     At each hop, perform a DNS lookup and report the owner as listed
              in the SOA record.

       -P     Send out multiple probes in  parallel.   The  default  behaviour
              probes  each  hop  in turn, starting from the nearest.  Parallel
              mode is faster, but less reliable.  Many routers rate limit ICMP
              packets  from a single host, so dropouts are much more likely in
              parallel mode, and need not indicate a networking problem.

       -Q     Report detailed statistics on the round trip times at  each  hop
              (minimum / average +- standard deviation / maximum).  The values
              are given in milli seconds.

       -S min_ttl
              Set the time-to-live (TTL) value in the first packet sent out to
              min_ttl (default 1).  This option determines the first (nearest)
              host that will show up in the trace.

       -T t   End each line with t instead of a newline.  This comes in handy,
              for example, when including traceroute’s output in an HTML page.

       -U     Move on to probing the next hop as soon as the first  successful
              probe arrives.

       -$     Send  out  nothing  but a single ping with a very large time-to-
              live.

DIAGNOSTICS

       Usually the round trip time is printed for  each  probe  at  each  hop.
       Special symbols denote when something went wrong:

       *      No reply received within wait seconds.

       !      Reply arrived with a time-to-live value of one or lower.

       !H     Received   a   reply   telling  that  the  destination  host  is
              unreachable.

       !N     Received  a  reply  telling  that  the  destination  network  is
              unreachable.

       !P     Received   a   reply   telling  that  the  desired  protocol  is
              unavailable.

       !S     Received a reply telling that  source  routing  failed.   Should
              never occur--unless the probed gateway is screwed.

       !F     Received  a  reply telling that fragmentation is needed.  Should
              never occur--unless the probed gateway is screwed.

EXAMPLES

       (This section is taken almost verbatim from the  documentation  in  the
       traceroute sourcecode.)

              [yak 71]% traceroute nis.nsf.net.
              traceroute to nis.nsf.net (35.1.1.48), 30 hops max, 56 byte packet
               1  helios.ee.lbl.gov (128.3.112.1)  19 ms  19 ms  0 ms
               2  lilac-dmc.Berkeley.EDU (128.32.216.1)  39 ms  39 ms  19 ms
               3  lilac-dmc.Berkeley.EDU (128.32.216.1)  39 ms  39 ms  19 ms
               4  ccngw-ner-cc.Berkeley.EDU (128.32.136.23)  39 ms  40 ms  39 ms
               5  ccn-nerif22.Berkeley.EDU (128.32.168.22)  39 ms  39 ms  39 ms
               6  128.32.197.4 (128.32.197.4)  40 ms  59 ms  59 ms
               7  131.119.2.5 (131.119.2.5)  59 ms  59 ms  59 ms
               8  129.140.70.13 (129.140.70.13)  99 ms  99 ms  80 ms
               9  129.140.71.6 (129.140.71.6)  139 ms  239 ms  319 ms
              10  129.140.81.7 (129.140.81.7)  220 ms  199 ms  199 ms
              11  nic.merit.edu (35.1.1.48)  239 ms  239 ms  239 ms

       Note  that  lines 2 & 3 are the same.  This is due to a buggy kernel on
       the 2nd hop system -- lbl-csam.arpa -- that  forwards  packets  with  a
       zero TTL.

       A more interesting example is:

              [yak 72]% traceroute allspice.lcs.mit.edu.
              traceroute to allspice.lcs.mit.edu (18.26.0.115), 30 hops max
               1  helios.ee.lbl.gov (128.3.112.1)  0 ms  0 ms  0 ms
               2  lilac-dmc.Berkeley.EDU (128.32.216.1)  19 ms  19 ms  19 ms
               3  lilac-dmc.Berkeley.EDU (128.32.216.1)  39 ms  19 ms  19 ms
               4  ccngw-ner-cc.Berkeley.EDU (128.32.136.23)  19 ms  39 ms  39 ms
               5  ccn-nerif22.Berkeley.EDU (128.32.168.22)  20 ms  39 ms  39 ms
               6  128.32.197.4 (128.32.197.4)  59 ms  119 ms  39 ms
               7  131.119.2.5 (131.119.2.5)  59 ms  59 ms  39 ms
               8  129.140.70.13 (129.140.70.13)  80 ms  79 ms  99 ms
               9  129.140.71.6 (129.140.71.6)  139 ms  139 ms  159 ms
              10  129.140.81.7 (129.140.81.7)  199 ms  180 ms  300 ms
              11  129.140.72.17 (129.140.72.17)  300 ms  239 ms  239 ms
              12  * * *
              13  128.121.54.72 (128.121.54.72)  259 ms  499 ms  279 ms
              14  * * *
              15  * * *
              16  * * *
              17  * * *
              18  ALLSPICE.LCS.MIT.EDU (18.26.0.115)  339 ms  279 ms  279 ms

       (I start to see why I’m having so much trouble with mail to MIT.)  Note
       that the gateways 12, 14, 15, 16 & 17 hops away either don’t send  ICMP
       "time exceeded" messages or send them with a TTL too small to reach us.
       14 - 17 are running the MIT C Gateway  code  that  doesn’t  send  "time
       exceeded"s.  God only knows what’s going on with 12.

       The  silent  gateway  12 in the above may be the result of a bug in the
       4.[23]BSD network code (and its derivatives):  4.x (x <=  3)  sends  an
       unreachable   message  using  whatever  TTL  remains  in  the  original
       datagram.  Since, for gateways, the remaining TTL  is  zero,  the  icmp
       "time  exceeded" is guaranteed to not make it back to us.  The behavior
       of this bug is  slightly  more  interesting  when  it  appears  on  the
       destination system:

               1  helios.ee.lbl.gov (128.3.112.1)  0 ms  0 ms  0 ms
               2  lilac-dmc.Berkeley.EDU (128.32.216.1)  39 ms  19 ms  39 ms
               3  lilac-dmc.Berkeley.EDU (128.32.216.1)  19 ms  39 ms  19 ms
               4  ccngw-ner-cc.Berkeley.EDU (128.32.136.23)  39 ms  40 ms  19 ms
               5  ccn-nerif35.Berkeley.EDU (128.32.168.35)  39 ms  39 ms  39 ms
               6  csgw.Berkeley.EDU (128.32.133.254)  39 ms  59 ms  39 ms
               7  * * *
               8  * * *
               9  * * *
              10  * * *
              11  * * *
              12  * * *
              13  rip.Berkeley.EDU (128.32.131.22)  59 ms !  39 ms !  39 ms !

       Notice  that  there are 12 "gateways" (13 is the final destination) and
       exactly the last half of them are "missing".  What’s  really  happening
       is  that  rip  (a  Sun-3  running  Sun OS3.5) is using the TTL from our
       arriving datagram as the TTL in its icmp reply.   So,  the  reply  will
       time  out  on the return path until we probe with a TTL that’s at least
       twice the path length.  I.e., rip is really only 7 hops away.

ENVIRONMENT

       The lookup process of Autonomous System Numbers  (ASN,  see  option  -A
       above) can be configured via several environment variables. By default,
       traceroute issues a whois query on the Routing Assets  Database  (RADB)
       at whois.ra.net, which should be sufficient in most cases.  Chances are
       that you don’t want to change anything here, unless you know very  well
       what you are doing.

       The  contents of the following environment variables are limited to 100
       characters at most.  Any trailing characters are silently ignored.   If
       unset, compiled-in defaults are used.

       RA_SERVER
              Server to issue a RADB whois query on, given either as hostname,
              or dotted-quad IP address.  Defaults to whois.ra.net.

       RA_SERVICE
              TCP port to connect to on the whois server, given either as name
              or port number.  Defaults to whois.

       The following variables determine how traceroute attempts to extract an
       ASN from the whois reply.

       DATA_DELIMITER
              Each line containing an ASN starts with this tag.   Defaults  to
              origin:.

       The  RADB  may  contain more than one entry for a given IP address.  To
       find out the correct entry, traceroute has to look up the  subnet  that
       is the most specific to this IP.

       ROUTE_DELIMITER
              Each  line  containing  a  subnet  entry  starts  with this tag.
              Defaults to route:.

       PREFIX_DELIMITER
              The network IP  and  the  prefix  are  separated  by  this  tag.
              Defaults to /.

NOTES

       This  is  not  the  standard  version of traceroute (as included in the
       netkit package), but an alternative implementation maintained  by  Ehud
       Gavron.  It  is  based on the Van Jacobson/BSD traceroute, and includes
       additional features  including  AS  lookup,  TOS  support,  microsecond
       timestamps,  path  MTU discovery, and parallel probing.  It is known as
       trACESroute or traceroute-nanog.

BUGS

       Please send any bugs to Ehud Gavron <gavron@wetwork.net> and/or  report
       them      to      the     Debian     Bug     Tracking     System     at
       http://bugs.debian.org/traceroute-nanog.

AUTHORS

       TrACESroute is maintained by Ehud Gavron <ehud.gavron@login.com>.

       The first man page was written by Brian Russo for use with  Debian/GNU,
       and was later rewritten by Daniel Kobras <kobras@debian.org> and Martin
       A.  Godisch  <martin@godisch.de>.   Some  parts  are  taken  from   the
       documentation  in the source code.  Still, this man page may be used by
       others.