[Overview] How routing updates/routes traverse through BGP routers

BGP - as like other routing protocols, perform the mainly tasks by propagating routing information from neighbors and itself to get the best information about routes. This post will provide some overview points to clarify how routing updates and routes traverse through BGP router.

1. Which kinds of route BGP deals with

Firstly, we should know which routes will be processed by (and not limited) BGP router.

• _The received (updated) routes: these are routes coming from other neighbors to provide the newest information about network. 
• _The locally sourced routes: these routes generated from router itself.
• _The advertised routes: the routes which routers want to send out to their neighbors.

2. Where are places hold the routes

In BGP, there are several tables contain routing information. Those tables are called Routing Information Base - RIB. BGP maintains three RIB tables, include:

• _Adj-RIB-In: this table holds all the routes coming from peers of BGP router. These routes still haven't treated by modifications yet and not stored in routing table right time they are received.
• _Local RIB: best paths will be stored here and then submitted to routing table. It also contains BGP prefixes injected by the current router.
• _Adj-RIB-Out: This holds all BEST routes will be advertised to peers.

3. How things occur when something named policy gets involved

BGP uses policies to modify and make some rules apply to routing flow. You can define inbound or outbound policies to affect to route/path selection. For example, inbound policies can be used to filter/modify routes coming from update sources before allowing them to get through router. Or you can define output policies to make sure about which routes should be advertised to outside inter-network.

Below figure shows what happening when routes come to in go from BGP router:

The steps as follow:

• -Updated routes received from peers must go to input policies are put into Adj-RIB-In table first.
• -Input policies decide whether these routes are allowed to continue or drop out.
•  These information will be filtered by Input policies.
• -Path selection will decide which routes are best and install them into Local-RIB. These routes then will be submitted into IP-RIB for local router.
• -From Local-RIB table, some routes will be chosen to advertise to peer. These routes must be filtered by Output policies to ensure that they are exactly what is going to be sent out.
• -These routes then stored in Adj-RIB-Out table and then advertised to peers.

Alert in monit

Every monitor tool should have a good alert functional to tell administrator about issues and monit is not an exception. Traditionally, monit allows us to contact with manager by sending email to report about any error happened to monitored services.

1. Enable email alert in monit

By default, if you don't define a notify statement, monit will not send alert messsages. There are two forms of alert statement:
-Global: enable alert to all services.
-Local: enable alert for individual service.
 Recipients in global and local lists are notified when service failed, recovered or changed. If you define both global and local recipients, the local recipient will override.
To set a global alert message, in global section using the "set" keyword

set alert recipient@domain.foo

When this statement is defined, all services being monitored will send messages to address recipient@domain.foo when something goes wrong.

To locally set alert function for each service

 check file test_alert with path "/home/cuong/testfile"
        alert abc@localhost
        if failed permission 0777 then alert

2.  Configurations for email notifications

2.1. Define mail server

Mail server is defined in global section using "set" keyword:

 SET MAILSERVER [hostname/ip] [port]

2.2. Alert message layout

monit provides a default layout for notification message, you can define of your own style. An example of standard layout

set mail-format {
        from:  monit@$HOST
        subject: monit alert -- $EVENT $SERVICE
        message: $EVENT Service $SERVICE
                Date: $DATE
                Action: $ACTION
                Host: $HOST
                Description: $DESCRIPTION
        monit by cuongnv at $DATE
}

Result:

From: monit@Deb6
To: cuong@localhost
Subject: monit alert -- Connection failed exim4
Date: Sat, 20 Apr 2013 14:25:12 GMT
X-Mailer: monit 5.5
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit

Connection failed Service exim4
                Date: Sat, 20 Apr 2013 21:25:12
                Action: restart
                Host: Deb6
                Description: failed protocol test [SMTP] at INET[localhost:25] via TCP -- SMTP: error receiving data -- Resource temporarily unavailable

        monit by cuongnv at Sat, 20 Apr 2013 21:25:12

Monitor your system with Monit

Previous posts covered terms and definitions about monit. This post will use those things to monitor processes running on system. Better is begin with an example of using monit in monitoring running service.

1. Example using monit to monitor sshd service

This example demonstrates configuring monit to monitor SSH service running on Debian 6 system, assuming monit is up and running well.

As mentioned in previous post, monitrc file is parted into 2 sections. One is global section with values globally applied to functions of monit. Another is spent for definitions of monitored object called service entries. Below illustration only shows the part of service:

(1)check process sshd with pidfile "/var/run/sshd.pid"
(2)        start = "/etc/init.d/ssh start"
(3)        stop = "/etc/init.d/ssh stop"

(4)        if failed port 22 protocol ssh then restart
(5)        if 5 restarts within 5 cycles then timeout
(6) alert admin@domain.foo

OK, I've just showed you about definitions of monitored service: SSH. When you're done putting these into monitrc file and restart monit, something like this will show up

2. Explanation

OK, show time is up, now it's time to explain what actually happened.

Line (1) tells monit about service to monitor, in this case is SSH. The syntax:

check process [process name] with pid [path/to/pidfile]

-check: keyword to monitor service.
-process: keyword tells monit to monitor a service.
-[process name]: unique name of process, in my example is sshd
-with pid: key word specifies the pid file.
-[path/to/pidfile]: fully path to process id of service, in my example is /var/run/sshd.pid

Line (2) (3) are defined in case you want to start or stop service by defining start and stop program.

Line (4)

if failed port 22 protocol ssh then restart

tells monit to take a test by making a connection to port 22 with ssh protocol running. And if the test statement is true (failed to connect), monit will make the action after the "then". Restart action actually executes stop first, wait up 30s for it to stop, then take start action in wait 30s for it to start. You can also specify the uid/gid runs the service.

Line (5)

if 5 restarts within 5 cycles then timeout

is another test action. The 1st 5 is the number of times restart service. Cycle is the time set in global section. If the "if" statement is true, "then" will set a timeout for service.

Line (6)

alert admin@domain.foo

will send an alert message to specified address. The definition of email server in global section will be covered later.

OK, now you can have an overview of definition for a monitored service.

3. What to monitor?

After having an overview about creating an object (process) to monitor by monit, it's time to come back to the question: which object(s) can monit monitor?

There are several objects (services) can take a "check" by monit:
-Process:

 check process [process name] with pid [path/to/pidfile]

-File:

 check file [filename] with path [path/to/file]

ex:  check file httpd.conf with path /usr/local/apache/conf/httpd.conf

-Directory:

check directory [dir_name] with path [path/to/dir]

ex:  check directory sbin with path /sbin

-Device:

check device [device_name] with path [path/to/device]

ex:  check device CDROM with path /dev/cdrom

-Remote host:

check host [name_of_hsost] with address [ip_addr_or_name]

ex: check host abc.domain.foo with address 10.1.1.1

It's possible to check the service running on remote host.

-System:

check system [system_name]
ex: check system my_host

Monit httpd authentication methods

Monit supports two types of authentication users via its tiny web server.

 1. Limit access from host and network

Monit uses access control lists to control the number of sources connect to server. It allows you to define both source by IP address or hostname. If the hostname is used, it will request the translation service to know the IP address of source.

If the host trying to connect to server but not found in access list will be logged with their IP address.
For example:

 set httpd port 2812 and
         use address 192.168.56.101
          SSL ENABLE
          PEMFILE         /opt/monit/monit.pem
          allow localhost
          allow host.abc.com
          allow 10.0.0.1
          allow 10.0.0.0/8

 With this configuration, any host NOT in the list - localhost, host.abc.com, 10.0.0.1 and network 10.0.0.0/8 will be denied from accessing to server. Log file will track the information of host trying to connect to server:

[PDT Apr  6 20:40:14] error    : monit: Denied connection from non-authorized client [192.168.56.1]
[PDT Apr  6 20:40:14] error    : monit: Denied connection from non-authorized client [192.168.56.1]

2. Basic authentication

There are several ways that server challenges clients  to send authentication information. Based on this information, server will decide act permit or deny. They could be:
-An allow statement contains a username and password separated by a colon (:) like this:

set httpd port 2812
      allow username:password

And this is CLEAR TEXT type
-Using PAM
-Using files in "htpasswd" format. If cryptographic is used, specify it in allow statement

 set httpd port 2812
       allow md5 /opt/monit/htpasswd usera userb userc

-Limit permission of user to read-only

set httpd port 2812
      allow username:password read-only

And it's possible to combine these methods to match requirements:

 set httpd port 2812 and
         use address 192.168.56.101
          SSL ENABLE
          PEMFILE         /opt/monit/monit.pem
          allow 10.0.0.0/8
          allow username:password

This configuration permits only connections from network 10.0.0.0/8 with a user "username" provides exactly pass "password".