[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".

First steps with Monit

After sucessfully installed monit, the next step is coming close to it. You should getting familiar with some things related to monit.

1. How to start and stop monit

To start monit, you just have to type:

# monit

And to stop it:

# monit quit

2. monit configuration file

As the same with many services on Linux, monit operation is controlled by a configuration file. This file named: monitrc and have a sample file right in the extracted folder you configured. monit will try to search and use this file in priority order:

1. ~/.monitrc
2.  /etc/monitrc (Debian based)
3. $sysconfdir/monitrc ( $sysconfdir is examined while configured as ./configure --sysconfdir)
4. ./monitrc

This file is devided into 2 main parts: global part and service part.

• Global part is place where you control everything about monit. monit will see and execute this part first to set appropriate configurations. The global set entry starts with keyword set and the item to configure. 

• Service part is where you put your services under controlled by monit. Service entry starts with keyword check followed by  the service type to monitor.

3. Logging

An important part is monitoring monit, this should be the very first step to work with every service you attempt to control. With monit, you just have to make a set statement in monitrc file. Using this set statement:

set logfile [path/to/logfile]

4. monit httpd

monit allows us to control it via web interface with a tiny web service running at (default) port 2812. You can then determine any unused port you want. To enable this function, using a global set statement in monitrc file:

set httpd port 2812

After enabling web service for monit, you can access monit via the URL:

http://localhost:2812

You can permit monit using ssl with this tiny web service if you compiled monit with ssl supported, the steps as follow:
Generate a self-signed ceritificate: (You must have openssl installed or something providing the similar functioning. )

• +Export environment variable for OpenSSL

• #export OPENSSL_CONF=/etc/ssl/openssl.cnf (default path in Debian)

• +Generate  private key and certificate

• #openssl req -new -x509 -days 365 -nodes -out /opt/monit/monit.pem -keyout /opt/monit/monit.pem
•  using $man openssl for more details about options

• +Generate Diffie-Hellman parameters

• #openssl gendh 512 >> /opt/monit/monit.pem 

• +Change mod for .pem file to 0700

• #chmod 0700 /opt/monit/monit.pem

After configuring self-signed certificate for monit web service, go to monitrc file and indicate monit to use SSL connection:

set httpd port 2812
    ssl enable
    pemfile /opt/monit/monit.pem

To this time, my monitrc file contains:

set httpd port 2812 and

        use address 192.168.56.101 # accept connection from remote host
        ssl enable
        pemfile         /opt/monit/monit.pem
        allow admin:monit      # require user 'admin' with password 'monit'
## Enbale logging
set logfile /var/log/monit.log

OK, bring up the browser, access to monit web service, using username/password: admin/monit

Monit - Installation issues

Today, I started installing and using Monit   on Debian Squeeze system. Actually, this is the second time I use Debian system (the first time when I decided to switch to Debian from a long time using Fedora), so there are some issues I met when installing Monit.

1. Repositories
• I'm using these repos for testing server:
• deb http://security.debian.org/ squeeze/updates main contrib
• deb-src http://security.debian.org/ squeeze/updates main contrib
• deb http://ftp.debian.org/debian/ squeeze-updates main contrib non-free
• deb http://ftp.jp.debian.org/debian/ squeeze-updates main contrib non-free
• deb-src http://ftp.jp.debian.org/debian/ squeeze-updates main contrib non-free
• deb http://ftp.jp.debian.org/debian squeeze main
2.  Dependencies
• When building monit from source file, it requires you to install PAM and SSL libraries to support its functions.  If you don't want to install these functions, you can skip them from installing by specify appropriate options when configure. Executing ./configure -h for more details.
• In this case, I want to install both PAM and SSL, the packages needed are: libssl-dev and libpam0g-dev

OK, if you can install it successfully, something like this will appear:

BGP terminologies - Part 1

1. BGP neighborship states

Before a BGP peer forming neighborship with a remote BGP peer, it must pass through several states:

• Idle
• Connect
• Active
• OpenSent
• OpenConfirm
• Established

 Before enabling BGP process, both R1 and R2 in Idle state and ignore all incoming requests. When R1 enables BGP process, it sends TCP request to R2 and waits for reply. At this time, R1 goes to Connect state. If connection establishes, R1 will send an Open message to R2 and goes to OpenSent state. If fails, R1 transitions to Active state.
To view the state of local router, use command:

In Active state, R1 is trying to send TCP request to R2, if connection establishes successfully, R1 will send Open message and transitions to OpenSent state.

When R1 reaches OpenSent state, it will send to R2 Open message, if valid Open message received, Keepalive message will be sent to negotiate session parameters and R1 goes to OpenConfirm state.
In OpenConfirm state, R1 keeps sending Keepalive message, and when it received Keepalive from R2, final state Established reached.

2. BGP Attributes

BGP choose route highily based on the values of path attributes. This post considers some well-known attributes which router must regconize.

• Origin: this attribute states out the originally of route, maybe the route from IGP - i, or EGP - e, or undetermined - ?. i < e < ? and lower value is prefered.

• AS Path: lists all traversed AS, used to choose the best route and prevents routing loop. This value is only changed when advertised through eBGP. 
• Next hop: next hop address, only modified when received from an eBGP peer. Must appear in routing table.

• Multiple Exit Discriminator (MED): optional, nontransitive, eBGP advertises to iBGPs to help choosing route when multiple routes exist. iBGP does not readvertise to eBGP.

• Local Preference: locally value, never advertised to eBGP. This value is used to consider routes in the same AS. Higher value is prefered.

3. Route selection process

The route selection process depends on each vendor. For Cisco, it is:

• Weight - highest (Cisco proprietary)
• Local preference - highest
• locally originated
• AS Path - shortest
• Origin (i
• MED - lowest
• eBGP>iBGP
• IGP metric - lowest
• oldest route
• neighbor with lowest RID
• neighbor with lowest IP address.

For Juniper:

• Highest Local preference
• AS Path - shortest
• Origin - smallest
• MED - smallest
• eBGP > iBGP
• IGP metric - smallest

Policy-Based Routing

1. Introduction to PBR

PBR is a tool provides a way to change the normal processing of packet routing function. After checking frame from errors, PBR intercepts packet before router performs routing decision. Some benifits when implementing PBR:

• Transit packets based on source informations: dealing with packets from various sources.
• QoS: setting precedence or TOS value in IP packet header.
• Cost saving: manual distribute traffic over low-bandwidth, low-cost links
• Load sharing: distribute traffic over multiple paths.

2. How PRB works

PRB decides how to forward packets by refering to route map for matching logic. The steps as following:

• Create a route map for matching criterias to choose the route.
• Enable route map to use in PBR, apply to incoming interface.

Route map definition was covered about in previous post plus a set condition with next-hop attribute. The ACLs used in route map can be standard or extended ACL, that means, we can define various requirements: source/dest address or both, TCP/UDP port number, ...

3. PBR configurations

Requirement: Direct traffic from R5 goes through R2, traffic from R6 goes through R3 to reach R4.

Before applying PBR, traffic from R5, R6 destine to R4 both via 10.0.0.2 (R2).

R6#trace 12.0.0.3

Type escape sequence to abort.
Tracing the route to 12.0.0.3

  1 172.16.1.3 32 msec 20 msec 24 msec
  2 10.0.0.2 40 msec 40 msec 40 msec
  3 12.0.0.3 60 msec *  60 msec

 R5#trace 12.0.0.3

Type escape sequence to abort.
Tracing the route to 12.0.0.3

  1 172.16.1.3 32 msec 20 msec 20 msec
  2 10.0.0.2 40 msec 44 msec 40 msec
  3 12.0.0.3 60 msec *  48 msec

 Define an extended ACL to match traffic from each host:

R1#show run | section access-list
access-list 101 permit ip host 172.16.1.1 host 12.0.0.3
access-list 102 permit ip host 172.16.1.2 host 12.0.0.3

Create a route-map for matched traffic and control direction of packets:

R1#show run | section route-map
route-map PBR permit 10
 match ip address 101
 set ip next-hop 10.0.0.2
route-map PBR permit 20
 match ip address 102
 set ip next-hop 11.0.0.2
 

 Apply route-map to interface:

R1#show run | section Ethernet0/0
interface Ethernet0/0
 ip address 172.16.1.3 255.255.255.0
 ip policy route-map PBR
 half-duplex

 Verifying traffic from R5 and R6:

R5#trace 12.0.0.3

Type escape sequence to abort.
Tracing the route to 12.0.0.3

  1 172.16.1.3 20 msec 12 msec 12 msec
  2 10.0.0.2 40 msec 56 msec 44 msec
  3 12.0.0.3 72 msec *  56 msec

R6#trace 12.0.0.3

Type escape sequence to abort.
Tracing the route to 12.0.0.3

  1 172.16.1.3 24 msec 16 msec 20 msec
  2 11.0.0.2 28 msec 44 msec 40 msec
  3 12.0.0.3 60 msec *  72 msec

 The set command can use "default" keyword to add more functions. With this command, there are two cases could be happen:

• Omitting this parameter: " try PBR first, of PBR's route does not work, using routing table."
• Including this parameter: " try routing table first, if routing table fails, use PBR."

Above example is just one of many ways using PBR, you can adjust requirements by mixing some tools together to achieve your goal.

Filter routes when redistributing

This blogpost will explain about 2 tools used in filtering routes when redistributing: Distribute-lists and route-maps.

1.Distribute-lists

Distribute-lists are used to filter routing updates in both inbound and outbound direction. It refers to access-list or prefix-list to match a source traffic and then applies under routing process.

Example using access-list

Router(config)# access-list 10 permit ip 172.16.0.0 0.0.255.255
Router(config)# router rip
Router(config-router)# distribute-list 10 in serial0/0

Distribute-list only allows incoming updates to RIP on serial0/0 for traffic refered in access-list 10. That means "Only update informations from 172.16.0.0/24  go through Serial0/0 by inbound direction will be accepted to RIP protocol."

Example using prefix-list

Router(config)# ip prefix-list MYLIST 10.1.0.0/16
Router(config)# router rip
Router(config-router)# distribute-list 10 in serial0/0

With the same meaning with access-list, difference in  replacing access-list 10 with prefix-list MYLIST

Two above examples both say about routing updates, so what happen in redistribution.
Distribute-lists can be configured under routing process that importing routes from redistributed-protocol. That means, when configuring distribute-lists, you have to go to received-protocol process to configure filtering. And the command must use "out" direction because it refers to routing process from which routes are redistributed.

For example, under EIGRP process, the command

distribute-list 1 out ospf 2

tells EIGRP to apply ACL 1 when importing routes from OSPF process 2. Note that, "out" direction must be refered.
Using this figure to demonstrate:

In this scenario, two routing protocols running are EIGRP and OSPF. R1 will take redistributing functions. The requirement is preventing route 1.1.1.0/24 from redistributing into OSPF process.
Before filtering route, subnet 1.1.1.0/24 still appears in routing table of R3:

R3#show ip route ospf
     1.0.0.0/24 is subnetted, 1 subnets
O E2    1.1.1.0 [110/20] via 11.0.0.1, 00:01:08, Ethernet0/1
     2.0.0.0/24 is subnetted, 1 subnets
O E2    2.2.2.0 [110/20] via 11.0.0.1, 00:28:33, Ethernet0/1
     10.0.0.0/30 is subnetted, 1 subnets
O E2    10.0.0.0 [110/20] via 11.0.0.1, 00:28:33, Ethernet0/1
     11.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
O E2    11.11.11.0/24 [110/20] via 11.0.0.1, 00:28:33, Ethernet0/1

 I'm using prefix-list named TEST:

R1#show run | section prefix-list
ip prefix-list TEST seq 5 deny 1.1.1.0/24
ip prefix-list TEST seq 10 permit 0.0.0.0/0 le 32

 This prefix-list only denies subnet 1.1.1.0/24 exactly and allows the rest.  Go to R1, under OSPF process:

R1#show run | section router ospf
router ospf 1
 log-adjacency-changes
 redistribute eigrp 10 subnets
 network 11.0.0.0 0.0.0.3 area 0
 distribute-list prefix TEST out eigrp 10

After applying distribute-list to OSPF process, subnet 1.1.1.0/24 is no longer appears in R3's routing table.

R3#show ip route ospf
     2.0.0.0/24 is subnetted, 1 subnets
O E2    2.2.2.0 [110/20] via 11.0.0.1, 00:30:21, Ethernet0/1
     10.0.0.0/30 is subnetted, 1 subnets
O E2    10.0.0.0 [110/20] via 11.0.0.1, 00:30:21, Ethernet0/1
     11.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
O E2    11.11.11.0/24 [110/20] via 11.0.0.1, 00:30:21, Ethernet0/1

2. Route-maps

Route-map is another tool to filter traffic like ACL but has more power functions:

• Controlling redistribution between routing protocols
• Adjust attributes for routes (especially BGP)
• Implement Policy Base Routing - PBR

Route-maps are organized by statements, each statement with a permit or deny condition. Traffic must firstly matched by using some criterias and then particular attribution or action is set to matched traffic.

Syntax of route-map:

Router(config)# access-list 1 permit 10.1.0.0 0.0.0.255
Router(config)# route-map TEST permit 10
Router(config-route-map)# match ip address 1
Router(config-route-map)# set ip next-hop 2.2.2.2

An ACL was created first to match traffic from 10.1.0.0/24. Then the route-map named TEST with permit condition and a sequence number is 10.
The route-map will match traffic listed in ACL 1 and finally sets attribute next-hop to traffic.
A route-map can contains multiple match commands:

Router(config)# route-map TEST permit 10
Router(config-route-map)# match ip address 1 2 3

With matching criteria in the same line, that means "OR" logical is applied.

Router(config-route-map)# match ip address 1
Router(config-route-map)# match ip address 2

With separated lines, the "AND" logical is applied.

When using with redistribution, if you dont want to make any changes to attributes of traffic, the route-map must have permit condition, match condition refers to ACL with no set is configured.

Use above diagram and requirement to demonstrate:

R1#show run | section access-list
access-list 10 deny   1.1.1.0 0.0.0.255
access-list 10 permit any
R1#show run | section route-map
route-map TEST permit 10
 match ip address 10  <<<< there is no set condition
R1#show run | section router ospf
router ospf 1
 log-adjacency-changes
 redistribute eigrp 10 subnets route-map TEST
 network 11.0.0.0 0.0.0.3 area 0

 Verify routing table on R3:

R3#show ip route ospf
     2.0.0.0/24 is subnetted, 1 subnets
O E2    2.2.2.0 [110/20] via 11.0.0.1, 00:03:09, Ethernet0/1
     10.0.0.0/30 is subnetted, 1 subnets
O E2    10.0.0.0 [110/20] via 11.0.0.1, 00:03:09, Ethernet0/1
     11.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
O E2    11.11.11.0/24 [110/20] via 11.0.0.1, 00:03:09, Ethernet0/1

As you can see, both distribute-lists and route-map accept us to expand configuration depends on requirement. They use ACL and prefix-list for reference so you can set various settings in ACL to have the best configuration.

OSPF Virtual Link

1. Introduction to Virtual link

OSPF design requires all areas must be physically connected to backbone area (Area 0) to communicate with each other. In some cases, the backbone area is separated by non-backbone area or a non-backbone area can not directly connect to backbone area - see figure below.

Virtual link is a connection from Area 2 to Area 0 through Area 29. Now, Area 29 is called Transit area. Transit area must have following requirements:

• Have full routing information.
• Not a stub area.

2. How it works

When virtual link configured, all routers know how to reach each other through virtual link. At this time, packets are transmitted through two ends of virtual link are not multicast packets, they are unicast packets on virtual link.
OSPF uses IP protocol 89 to transport, so if there is a firewall between virtual link, firewall should allow OSPF packets.
When routers become adjacent via virtual link, R3 now thinks itself as an ABR because it has a connection with Area 0, R3 then creates a LSA type 3 for its networks and advertises to Area 0 and Area 29. SPF processes calculate their best routes normally, using virtual link as a point-to-point link in Area 0.

3. Configuring OSPF Virtual link

Virtual link will be configured on R2 and R3, Area 29 will be transit area.

OSPF Configuration on R2:

R2#show run | section ospf
router ospf 1
 log-adjacency-changes
 area 29 virtual-link 10.0.2.1 <<
 network 1.1.1.0 0.0.0.255 area 0
 network 2.2.2.0 0.0.0.255 area 29 

R2#show ip ospf virtual-links
Virtual Link OSPF_VL0 to router 10.0.2.1 is up
  Run as demand circuit
  DoNotAge LSA allowed.
  Transit area 29, via interface FastEthernet0/1, Cost of using 10
  Transmit Delay is 1 sec, State POINT_TO_POINT,
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    Hello due in 00:00:07
    Adjacency State FULL (Hello suppressed)
    Index 2/3, retransmission queue length 0, number of retransmission 0
    First 0x0(0)/0x0(0) Next 0x0(0)/0x0(0)
    Last retransmission scan length is 0, maximum is 0
    Last retransmission scan time is 0 msec, maximum is 0 msec

OSPF Configuration on R3:

R3#show run | section ospf
router ospf 1
 log-adjacency-changes
 area 29 virtual-link 2.2.2.1 <<< R2's Router ID
 network 2.2.2.0 0.0.0.255 area 29
 network 10.0.0.0 0.0.0.255 area 2
 network 10.0.1.0 0.0.0.255 area 2
 network 10.0.2.0 0.0.0.255 area 2

You can configure authentication for virtual link either.
Another post about Virtual link ( by VietNamese)

EIGRP load balancing over unequal-cost paths

Previous post covered about load balancing over equal-cost paths. This post will explain how to load balance traffics over UNequal-cost paths.
In the case there is only one route is installed into routing table, other feasible successor routes are kept in topology table and will be refered when successor route failed. To enable load sharing over unequal-cost paths, it requires the feasible successor route is installed into routing table. A value called VARIANCE is configured to achieve this goal.
Variance is a number in range 1 to 128, where 1 is default means load balancing over equal-cost paths. Variance will be multiplied by current best metric (successor's FD) and compare with feasible successor's FD to decide whether it is useful or not. The comparison is:

If feasible successor's FD < successor's FD * variance = route will be installed into routing table.

 In this figure, R1-R4-R5 is feasible successor route for R1 to reach 1.1.1.0/24.
Feasible successor's FD is entire metric calculated from R1-1.1.1.0/24, it means 27+7+12=46
Successor's FD is: 10+5+6=21.
With variance value is 3, route R1-R4-R5 will be installed into routing table because it satisfies the condition.

For demonstration, the bandwidth in R1's s0/0 is changed to 700. Now, R1 only uses s0/1 to forward traffic to 5.5.5.0/24

R1#show ip route | section 5.5.5
D       5.5.5.0 [90/2323456] via 2.2.2.2, 00:00:04, Serial0/1

 In topology table of R1, it still keeps route via R2 to reach 5.5.5.0/24 with higher metric:

R1#show ip eig to 5.5.5.0/24
...
  2.2.2.2 (Serial0/1), from 2.2.2.2, Send flag is 0x0
      Composite metric is (2323456/409600), Route is Internal
      Vector metric:
        Minimum bandwidth is 1544 Kbit
       ...
  1.1.1.2 (Serial0/0), from 1.1.1.2, Send flag is 0x0
      Composite metric is (4322560/409600), Route is Internal
      Vector metric:
        Minimum bandwidth is 700 Kbit
       ...

To use unequal-cost load balancing over these routes, go to eigrp process and configure variance value is 2:

R1(config)#router eigrp 10
R1(config-router)#variance 2

  Now, both 2 routes are appeared in routing table:

R1#show ip route eig | section 5.5.5
     3.0.0.0/24 is subnetted, 1 subnets
D       5.5.5.0 [90/2323456] via 2.2.2.2, 00:01:08, Serial0/1
                [90/4322560] via 1.1.1.2, 00:01:08, Serial0/0

 R1#show ip route 5.5.5.5
Routing entry for 5.5.5.0/24
  Known via "eigrp 10", distance 90, metric 2323456, type internal
  Redistributing via eigrp 10
  Last update from 1.1.1.2 on Serial0/0, 00:02:17 ago
  Routing Descriptor Blocks:
    2.2.2.2, from 2.2.2.2, 00:02:17 ago, via Serial0/1
      Route metric is 2323456, traffic share count is 80
      Total delay is 26000 microseconds, minimum bandwidth is 1544 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 2
  * 1.1.1.2, from 1.1.1.2, 00:02:17 ago, via Serial0/0
      Route metric is 4322560, traffic share count is 43
      Total delay is 26000 microseconds, minimum bandwidth is 700 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 2

EIGRP load balancing over equal-cost paths

When router learned routes from other routing protocols, it will choose a best route to install to routing table. This route is the route with lowest  Administrative Distance, this value is assigned to each routing protocol.
In case there are multiple routes learned from a single routing protocol, metric will be considered and route with the lowest metric wins. If those routes have the same metric values, load balancing can be occur (EIGRP, OSPF). EIGRP even allows load balance over unequal-cost paths.

By default, EIGRP will load balance over 4 equal-cost paths and can be increased to 16 paths. EIGRP does not perform load balancing by itself, switching technologies handle it.

CEF is a layer 3 switching technology and enabled by default on IOS, and when CEF is enabling, load balancing will occur on per-destination basis. That means, all packets reach to a destination will use the same output interface.

In topology table:

R1#show ip eigrp to
IP-EIGRP Topology Table for AS(10)/ID(1.1.1.1)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status
...
P 3.3.3.0/24, 2 successors, FD is 435200
        via 10.0.0.2 (435200/409600), Ethernet0/0
        via 13.0.0.2 (435200/409600), Ethernet0/1
...

There are two successor routes to reach 3.3.3.0/24 from R1 with the same FD 435200. In this case, CEF is enabled on R1. so load balancing will occur in per-destination basis.

R1#show run | section cef
ip cef

 In per-destination basis, all traffics reach a destination will use the same output interface:

 When cef is disabled, packets are distributed over both two routes:

 Alternatetively, per-packet load balancing can be happen while CEF is enabled by configuring load sharing on outgoing interfaces.

R1(config)#ip cef
R1(config)#int e0/0
R1(config-if)#ip load-sharing per-packet
R1(config-if)#int e0/1
R1(config-if)#ip load-sharing per-packet

EIGRP Terminologies

In this post, I will explain some terminologies related to EIGRP, include:

• Feasible distance and reported/administrative distance (FD and AD).
• Successors and feasible successor routes.

1.Feasible Distance and Reported Distance - FD and RD


Feasible Distance (FD): is the metric of best route from local router to destination subnet. Best route is the route with the lowest metric.

Reported Distance (RD): is the metric advertised by the neighbor/next hop for that route. Local router knows this information because they exchange their topology tables together. 

In this example, let consider the route from R1 to 1.1.1.0/24.
There are two routes from R1 to reach 1.1.1.0/24:

1. R1-R2-R3-dest: metric is 10+15+7 = 32.
2. R1-R4-R5-dest: metric is 12+9+12 = 33.

In this scenario, R1 will choose 1st route with lower metric. The FD in here is 32 because it is the best metric.

Reported Distance is the value of next hop router to destination, in here, next hop router of R1 is R2, and RD of this route is the metric calculated from R2 to destination: 15+7 = 22.

2. Successor and Feasible successor routes

Successor route is the best route choosen to install into routing table, in above example is R1-R2-R3 route.
Feasible successor route is the backup route for successor route in case feasible successor route down.

By default, EIGRP only keeps one best route to install to routing table, but it still keeps the less-than-optimal routes in topology table.

To become a feasible route, a route must be qualified the stuff called feasibility condition. The condition is:

• The route must be loop-free. This means, the RD of that route from local router must less than the local best metric (FD).

So, in above diagram, what is the feasible successor route of the best route from R1 to 1.1.1.0/24?
As explained before, the best route from R1 to 1.1.1.0/24 is R1-R2-R3 with FD is 32. Another route to reach 1.1.1.0/24 is R1-R4-R5 with metric is 33.
If R1-R4-R5 route wants to become feasible successor route, its RD must be less than current FD of R1.
In this example, the RD of R1-R4-R5 is calculated from R4 to 1.1.1.0/24 so it is 21.

With this RD value (21 < 32), this route is feasible successor route.