Thursday, December 22, 2011

OSPF Simulation using Quagga


Scenario

 

IP Details

All the Routers in the diagram are actually Debian Machines.

Router Alpha:
  • eth0: 192.168.10.254/24
  • eth1: 10.0.0.2/30
Router Beta:
  • eth0: 192.168.20.254/24
  • eth1: 10.0.0.1/30
  • eth2: 10.0.0.5/30
Router Gamma:
  • eth0: 192.168.30.254/24
  • eth1: 10.0.0.6/30

Objective

We would be configuring the Linux boxes with dynamic routing protocol OSPF for total connectivity. This would be done with the help of Quagga.

Router Alpha Configuration

root@alpha:~# apt-get install quagga


First, we have to enable the routing protocols needed.
root@alpha:~# cd /etc/quagga/
root@alpha:~# vim daemons
zebra=yes
bgpd=no
ospfd=yes
ospf6d=no
ripd=no
ripngd=no
isisd=no


Next, we would be configuring the interface parameters. Keep in mind, there are example configuration files stored in /usr/share/doc/quagga/examples.
root@alpha:/etc/quagga# vim zebra.conf
hostname AplhaRouter
password zebra
enable password zebra
!
! Interface's description.
!
interface lo
description loopback
ip address 127.0.0.1/8
ip forwarding 

interface eth0
description LAN
ip address 192.168.10.254/24
ip forwarding

interface eth1
description to_beta
ip address 10.0.0.2/30
ip forwarding


log file /var/log/quagga/zebra.log


Now to the OSPF Configuration.


root@alpha:/etc/quagga# vim ospfd.conf
### we define the interfaces that take part in OSPF
interface eth0
interface eth1

router ospf
network 10.0.0.0/30 area 0
network 192.168.10.0/24 area 0

log stdout
log file /var/log/quagga/ospfd.log

Now, it's time to start the Quagga daemon. We do this by-


root@alpha:/etc/quagga# /etc/init.d/quagga restart


vtysh provides a shell that resembles the CISCO IOS shell. It even supports commands from the CISCO IOS. If vtysh.conf is not already present, we copy the file from /usr.

root@alpha:~# cp /usr/share/doc/quagga/examples/vtysh.conf.sample /etc/quagga/vtysh.conf
root@alpha:~#vtysh
Hello, this is Quagga (version 0.99.17).
Copyright 1996-2005 Kunihiro Ishiguro, et al.


AlphaRouter# show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
I - ISIS, B - BGP, > - selected route, * - FIB route

C>* 127.0.0.0/8 is directly connected, lo
C>* 10.0.0.2/30 is directly connected, eth0
C>* 192.168.10.0/24 is directly connected, eth1
AlphaRouter# exit


We can issue commands like show ip route or show ip ospf in vtysh to check the available routes and OSPF status. However, since there are no OSPF neighbors yet, the show ip route should show only directly connected devices.


Router Beta Configuration

Time to configure the next Linux box. The configuration is identical except for the network parameters. Here it goes -
root@beta:/etc/quagga# cat zebra.conf
hostname BetaRouter
password zebra
enable password zebra
!
! Interface's description.
!
interface lo
description loopback
ip address 127.0.0.1/8
ip forwarding

interface eth0
description LAN
ip address 192.168.20.254/24
ip forwarding

interface eth1
description to_alpha
ip address 10.0.0.1/30
ip forwarding

interface eth2
description to_gamma
ip address 10.0.0.5/30
ip forwarding


log file /var/log/quagga/zebra.log

root@beta:/etc/quagga# cat ospfd.conf
### we define the interfaces that take part in OSPF
interface eth0
interface eth1
interface eth2

router ospf
network 10.0.0.0/30 area 0
network 10.0.0.4/30 area 0
network 192.168.20.0/24 area 0

log stdout
log file /var/log/quagga/ospfd.log

Time to start the Quagga daemon again.

root@beta:/etc/quagga# /etc/init.d/quagga restart

root@beta:~#vtysh
Hello, this is Quagga (version 0.99.17).
Copyright 1996-2005 Kunihiro Ishiguro, et al.


BetaRouter# show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - ISIS, B - BGP, > - selected route, * - FIB route

C>* 127.0.0.0/8 is directly connected, lo
O 10.0.0.1/30 [110/20] is directly connected, eth1
C>* 10.0.0.1/30 is directly connected, eth1
O 10.0.0.5/30 [110/20] is directly connected, eth2
C>* 10.0.0.5/30 is directly connected, eth2
O>* 192.168.10.0/24 [110/40] via 10.0.0.2, eth1,
O 192.168.20.0/24 [110/20] is directly connected, eth0
C>* 192.168.20.0/24 is directly connected, eth0


BetaRouter# exit
As we can see now, the neighbor relationship has been formed and Alpha and beta have already exchanged routing information.
Now try pinging between the Alpha and Beta networks. Should work. Alternatively, also using the good old route command as well to see whether the routes are already being learnt. 

Router Gamma Configuration

The configuration of Gamma is same as the previous Linux boxes.


root@gamma:/etc/quagga# cat zebra.conf
hostname GammaRouter
password zebra
enable password zebra
!
! Interface's description.
!
interface lo
description loopback
ip address 127.0.0.1/8
ip forwarding

interface eth0
description LAN
ip address 192.168.30.254/24
ip forwarding

interface eth1
description to_beta
ip address 10.0.0.6/30
ip forwarding

log file /var/log/quagga/zebra.log


root@gamma:/etc/quagga# cat ospfd.conf
### we define the interfaces that take part in OSPF
interface eth0
interface eth1

router ospf
network 10.0.0.4/30 area 0
network 192.168.30.0/24 area 0

log stdout
log file /var/log/quagga/ospfd.log

Time to start the Quagga daemon again.


root@alpha:/etc/quagga# /etc/init.d/quagga restart

The system is now ready to rumble. Try viewing the routes by route or ip route or show ip route (vtysh). All the routers should be able to ping each other, and each host from any of the LANs should be able to communicate with host of other LAN. Again, traceroute can also be used to check the path that is being taken by a packet.


Hope it helps.


Wednesday, December 21, 2011

RSYNC with Different Port

If SSH is not listening to the default port 22, then naturally we can not use RSYNC without specifying the SSH port. For example, if SSH is listening to port 4321, RSYNC can be used like this -

# rsync -av -e "ssh -p 4321"   source_file   user@IP:/destination

Hope it helps.

Backing up with RSYNC


Backing up with RSYNC

RSYNC is a program that is widely used for backing up data. RSYNC is able to create full, as well as incremental backups, and is pretty easy to use. Moreover, RSYNC can also be used to backup data into remote machines. When backing up to remote machine, RSYNC can utilize SSH which means the communication is being protected by one of the world’s strongest protections. Here’s how RSYNC can be used –

Objective

  1. All files in the directory /original needs to be backed up at /backup. The process must be repeated every 10 days.
  2. The directory /backup needs to be backed up at 192.168.10.254:/backup2. The process must be repeated every 15 days.

Phase 1:

We are using the –a option for ‘archive’ . Archive is used to preserve permissions. The –v option is used for ‘verbose’ output.

root@firefly:~# ls -l /original/
total 0
-rw-r--r-- 1 root root 0 Dec 21 19:40 f1
-rw-r--r-- 1 root root 0 Dec 21 19:40 f2
-rw-r--r-- 1 root root 0 Dec 21 19:40 f3
-rw-r--r-- 1 root root 0 Dec 21 19:40 f4
-rw-r--r-- 1 root root 0 Dec 21 19:40 f5
-rw-r--r-- 1 root root 0 Dec 21 19:40 f6
-rw-r--r-- 1 root root 0 Dec 21 19:40 f7
-rw-r--r-- 1 root root 0 Dec 21 19:40 f8

This is the list of files to be backed up.

root@firefly:~# rsync -av /original/ /backup/
sending incremental file list
./
f1
f2
f3
f4
f5
f6
f7
f8

sent 401 bytes  received 167 bytes  1136.00 bytes/sec
total size is 0  speedup is 0.00

root@firefly:~# ls -l /backup/
total 0
-rw-r--r-- 1 root root 0 Dec 21 19:40 f1
-rw-r--r-- 1 root root 0 Dec 21 19:40 f2
-rw-r--r-- 1 root root 0 Dec 21 19:40 f3
-rw-r--r-- 1 root root 0 Dec 21 19:40 f4
-rw-r--r-- 1 root root 0 Dec 21 19:40 f5
-rw-r--r-- 1 root root 0 Dec 21 19:40 f6
-rw-r--r-- 1 root root 0 Dec 21 19:40 f7
-rw-r--r-- 1 root root 0 Dec 21 19:40 f8

As we can see, all the files have been copied to the destination directory. While using RSYNC, we need to keep in mind that RSYNC is sensitive about the trailing ‘/’ in the source argument. To RSYNC, ‘/original’ and ‘/original/’ are not the same thing.

To repeat the task every 10 days, we would add the following crond rule-

Min
Hour
Day of Month
Month
Day of Week
Command
00
02
*/10
*
*
rsync -av /original/ /backup/

 

Phase 2

Here, we would copy the directory /backup from the source machine to the remote machine’s directory /backup2. Here’s how it’s done-

root@localhost:~# rsync -av -e ssh /backup/ 192.168.10.254:/backup2

That wasn’t hard, was it? The only remaining thing to do is to add a scheduled task with the help of crond.

Min
Hour
Day of Month
Month
Day of Week
Command
00
04
*/15
*
*
rsync -av -e ssh /backup/ 192.168.10.254:/backup2


And that’s it. Hope it helps.  ^_^

SSH Login Without Passwords (Alternate SSH Port)

Many people don't use the default SSH port 22 for security purposes. In such case, when sharing the public key with a remote host, the following command can be used -



root@localhost:~# ssh-copy-id -i id_dsa.pub '-p 1234 root@192.168.12.253'

Should work. enjoy :)

SSH login without passwords


SSH Private-Public Key Pair Login

Everyone would agree with the fact that SSH is the most widely used remote access protocol used in Linux based operating systems. The primary reason behind the popularity of SSH is, it utilizes one way encryption, supports many encryption algorithms as well as pre-shared keys for authentication.

There are a couple of remote file sharing software that rely on SSH for protection like SCP, SFTP, RSYNC. Among them, RSYNC is really popular for taking backups. But because RSYNC to a remote host relies on SSH, and SSH prompts for a password, automating the backup process cannot be done with default settings. Here is where private-public key pair kicks in to save the day. With the help of the key pair, it is possible to utilize SSH to a remote host without using passwords.

The methodology is pretty simple.
  1. HostA generates a private and public key pair.
  2. While generating the pair, no passphrases are used because the objective is to enable SSH without passwords.
  3. HostA shares the public key with HostB.
  4. When HostA tries to connect to HostB using ssh, HostA provides information from the private key stored in HostA. This information is matched with the previously shared public key stored in HostB.
  5. If everything goes fine, a user from HostA is able to connect to HostB.

Objective:

The root user at host firefly (192.168.1.3) should be able to login to host spider (192.168.1.2) using SSH without providing passwords.

Phase 1:

root@firefly:~# ssh-keygen -t rsa
DSA or RSA can be used, but RSA is more secured. The configuration of RSA and DSA is identical (only the filename is different)

Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Here, we have entered blank passphrase because we want to enable SSH login without passwords.

Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
56:0c:7b:b1:9d:7c:2b:db:d6:27:7b:6b:94:e1:b9:cf root@firefly
The key's randomart image is:
+--[ RSA 2048]----+
|        . .      |
|         + = .   |
|        . = + .  |
|         o   . o |
|        S   . o +|
|       .     + * |
|            . = +|
|             . *o|
|              ooE|
+-----------------+


The pair of keys is now generated. The private key is named id_rsa and the public key is id_rsa.pub.

root@firefly:~# ls -l /root/.ssh/
total 20
-rw------- 1 root root 1679 Dec 21 18:57 id_rsa
-rw-r--r-- 1 root root  394 Dec 21 18:57 id_rsa.pub
-rw-r--r-- 1 root root 1326 Dec 20 11:12 known_hosts

One thing should be kept in mind. SSH is very sensitive about the file ownership and permissions. Make sure that the permissions are like properly set.

Phase 2:

Now, the id_rsa.pub file needs to shared with the host spider.
root@firefly:~# ssh-copy-id -i .ssh/id_rsa.pub root@192.168.1.2
root@192.168.1.2's password:

Now try logging into the machine, with "ssh 'root@192.168.1.2'", and check in:

  .ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.

During this process, this happens
  1. The content of the file id_rsa.pub file is transferred to spider (192.168.1.2).
  2. The content is stored in the file ~/.ssh/authorized_keys
  3. Anytime a public key is shared, the information is appended the file authorized_keys.
Time to check whether it works or not  =?

root@firefly:~# ssh 192.168.1.2
Linux spider 2.6.32-5-686 #1 SMP Mon Jun 13 04:13:06 UTC 2011 i686

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Wed Dec 21 16:15:41 2011 from 192.168.1.3
root@spider:~#

Well, guess what? It works :)

Last piece of information, as stated earlier, SSH is really sensitive about ownership and permissions. So make sure that the permissions are correct.

root@spider:~# ls -l .ssh/
total 16
-rw------- 1 root root  394 Dec 21 18:58 authorized_keys
-rw-r--r-- 1 root root 2210 Dec 20 12:21 known_hosts

Hope it helps. ^_^

Friday, December 2, 2011

Adding Persistent Static Routes in Debian

Stumbled upon this just a while ago...

Adding a static Route in Debian can be easily done by using the command

route add -net 192.168.2.0 netmask 255.255.255.0 gw 192.168.1.2 dev eth1

Here, the network 192.168.2.0 is accessible through next hop 192.168.1.2 exit interface eth1. However, the problem is that the system forgets the route if the network service restarts. Here's how the route can be made permanent -


# The primary network interface
auto eth1
allow-hotplug eth1
iface eth1 inet static
    address 192.168.1.3
    netmask 255.255.255.0

up route add -net 192.168.2.0 netmask 255.255.255.0 gw 192.168.1.2 dev eth1
up route add -net 192.168.10.0 netmask 255.255.255.0 gw 192.168.1.2 dev eth1

down route del -net 192.168.2.0 netmask 255.255.255.0 gw 192.168.1.2 dev eth1
down route del -net 192.168.10.0 netmask 255.255.255.0 gw 192.168.1.2 dev eth1

The route is would now be updated every time the network service is restarted. Works like a charm :)