EXECUTIVE SUMMARY
BGP is a key protocol in exchanging all kinds of routing information within an Autonomous System (AS) and among various AS. Internally, all routers, configured with iBGP, needs to be connected as full mesh topology in order to make discoveries such as selection of root node and the exchange of information. A full mesh topology becomes cumbersome and hard to manage as a network grows. However, for large networks instead of full mesh approach, concept of route reflectors and BGP confederation is used to mitigate the networking overheads but both these alternatives face the problems of network inconsistencies in some cases.
The concept of Central Routing is an alternative solution, where the root node in an Autonomous System will be responsible for all the control and management operations such as maintaining routing tables and calculating paths.
This report will implement Central Routing and will also evaluate its scalability even in the large networks as compared to other approaches in iBGP.
LIST OF TABLES
4.2.1 FIRST SAMPLE ITERATION 10
4.2.2 SECOND SAMPLE ITERATION 10
4.2.3 FINAL SAMPLE ITERATION 11
5.1 DATABASE OF CENTRAL NODE OF SAMPLE NETWORK 13
LIST OF FIGURES
1.1 BGP’s relation with AS internally and externally 1
2.1.1 The analysis of BGP routing table growth 1998-01 2
2.1.2 The analysis of BGP routing table growth 1991-2015 3
2.2.1 iBGP with mesh topology and route reflector 4
2.3.1 Concept of BGP confederation 5
4.1.1 Flowchart for updating routing table 7
4.2.1 Flowchart for updating shortest path search 9
5.1 Sample Network 12
5.2 Output of program 13
LIST OF FLOW CHART SYMBOLS
Start / End
Input / Output
Processing Flow
Decision
Connector
Control Flow Lines
LIST OF ABBREVIATIONS
BGP Border Gateway Protocol
iBGP Interior Border Gateway Protocol
eBGP Exterior Border Gateway Protocol
AS Autonomous System
ASN Autonomous System Number
NLRI Network Layer Reachability Information
1. INTRODUCTION
In a ubiquitous network such as an Internet the management is a key factor. A vast number of standard protocols have been designed so far for each layer of TCP/IP model. BGP or Border Gateway Protocol is one of these standardized protocols which are basically implemented on gateway routers, sitting on the edge of any network. This network region or area is known as an Autonomous System.
An Autonomous System (AS) is a network or a group of networks which is usually owned or controlled by a single administrative entity such as a business firm, university, college or a school, any government or non-government organisation, etc.
BGP is configured on all the edge routers of an AS to exchange the routing information between them. BGP is actually divided into two groups, eBGP or Exterior Border Gateway Protocol and iBGP or Interior Border Gateway Protocol.
Figure 1.1: BGP’s relation with AS internally and externally [1]
1.1 Working of BGP
As stated above that BGP is used to exchange the routing information between and within ASs, this information is specifically identified as Network Layer Reachability Information (NLRI) and for that routers have to maintain TCP connections among them using port 179.
BGP enabled routers maintaining TCP connections are known as neighbours or peers. Initially entire routing table is exchanged between peers and then only updates are sent whenever any.
2. CHALLENGES IN IBGP
2.1 Problem in iBGP and current solutions
In case of iBGP, that is, all the BGP enabled routers should be connected each other with a mesh topology. Although there don’t need to be connected directly but forming a mesh topology becomes cumbersome as the numbers of routers grow within an AS. Moreover, each router in network will exchange full routing table with all other routers in an AS, which results in dramatic growth in the size of the routing table. Studies have also shown that from past few years there have been recorded an exponential growth in the size of the routing table and as a result some old and less capable routers cannot deal with memory requirements and processor load, consequently cannot act as an effective gateway which leads to up gradation of routers which is once again costly. Due to impractical approach of mesh topology, administrators of large networks use alternative concepts identified as Route Reflector and BGP confederation.
Figure 2.1.1: The analysis of BGP routing table growth 1998-01 [2]
Figure 2.1.2: The analysis of BGP routing table growth 1991-2015 [3]
2.2 Route Reflector
When iBGP routers are connected via mesh topology, each router needs to maintain TCP session with all other iBGP routers in an autonomous system. So whenever a router has any update to send, it has to send to all other routers in an AS. So if a router is connected to all other routers through one link, that link will be overloaded with all TCP traffic whenever there is any update. This arises a question of network scalability.
On the other hand route reflector is a technique in which distribution of information is done without the need of routers being connected in full mesh topology which results in lowering network overheads. Actually one router in an AS is selected as a concentration router or a route reflector which is connected to all other iBGP routers and will send updates to all other routers on behalf of the sender router.
In the diagram shown below, in first part, in case of mesh topology, router 3 is having update and it is sending all the other routers whereas in second part router 1 is a route reflector and when router 3 has some update, it will send to 1 and therafter router 1 will distribute these updates to all other routers in an AS.
Figure 2.2.1: iBGP with mesh topology and route reflector
The drawback with this approach is that it increases the overheads on concentration router and also if not configured properly, it may result in routing loops and unstable network. Moreover route reflector have a single path for each destination but this can create inconsistency when there are more than one route reflectors in an AS as they may have different routes for a single destination which may once again result in routing loops. Also, the path selected by route reflectors would not necessary be the same as any of its client would have selected in case of full mesh.
2.3 BGP Confederation
In BGP confederation, AS with large number of routers are divided into sub ASs. Each AS is identified globally by its number known as ASN. Grouping one big AS into smaller ASs with different ASN will increase the cost of purchasing ASN and also it is not pragmatic to do so as ASN are limited resources. But sub ASs in BGP confederation overcome these problems as sub ASs are not visible to the outside world and still any router of all sub ASs are identified as a member of main AS.
Figure 2.3.1: Concept of BGP Confederation
In figure 3, AS 1000 is the actual AS number whereas AS 64550, AS 64551 and AS 64552 are the private ASNs which are not visible to the outside world. Private ASN can range from 64512 to 65535.
Routers in a sub AS maintains iBGP session within the same sub AS and as already discussed, routers in iBGP needs to be connected through mesh topology. Routers in different sub AS maintain eBGP sessions, but it is quite different from real eBGP session and is known as Intraconfederation eBGP session.
Though BGP confederation is a nice way to overcome the drawbacks of iBGP and route reflectors, but it increases the processing and information complexity within and outside AS. In other words, a virtual BGP world is created within an AS and that works like actual BGP. In many networks BGP confederations works in conjunction with route reflectors.
Overall both the solutions, that is, route reflectors and BGP confederations may not select the same feasible path as in case of mesh topology, cannot overcome the problem of exponential growth of routing tables. Also whenever there are any updates, no matter what approach is used, they have to be sent to each and every other router which again results in network overheads.
3. PROPOSED SYSTEM
3.1 Central Routing
The concept of Central Routing which is a proposed alternative approach in iBGP, provides the accuracy of mesh topology and scalability of route reflectors.
In central routing, the path selection from source to destination is programmatically decided by the root router. When any iBGP router shows up in an AS, it will send its directly connected iBGP routers to the central node and central node will update its routing table accordingly.
Only central node will have information regarding all the iBGP routers in an AS, apart from central node, all other iBGP routers will have information about their directly connected neighbours only.
The discussion in this report is based on certain very pragmatic assumptions and the algorithms are designed in such a way that with the implementation of simple interface, the stated approach can be achieved.
3.2 Pragmatic Assumptions
‘ Election of Central Node will be done by network administrator and there is only one central node per AS, however this limitation can be conquered by making certain changes in algorithms according to the principles of backup and security features implemented on any router in any network.
‘ The programming logic is installed on central node and an interface between program and message packet is capable of extracting and delivering information correctly.
‘ The central node will not take part in any activity other than accepting peering information updates and calculating path between source and destination.
‘ The cost on each link is same.
4. ALGORITHMS AND PROGRAMS
4.1 Algorithm for updating routing table
Step 1: Search for source and peer id combination in the routing table
Step 2: If no match is found, make entry in table else discard it
Step 3: Goto Step 1 until all source-peer combinations are checked
Step 4: End
Figure 4.1.1: Flowchart for updating routing table
4.1.1 Description of Algorithm 4.1
To add new routes, Java class xadd_routes is used and logic is designed in such a way that there exist no redundancy, for example if router 1 has their neighbours as router 2 and router 3, then router 1 will send this information to the central node and central node will update its database accordingly. Later on if router 2 sends its information as router 1 and router 4 as its neighbouring routers, then this time xadd_routes class will only add a single entry as source router 2 and destination router 4 and no entry for destination 1 will be inserted as the combination of 1-2 and 2-1 is treated equally and thus redundancy is eliminated.
Besides this, logic is also designed to avoid duplicate entries and reducing the size of the database at central node as shown in Table 4 ahead in the Testing section.
This concept looks similar to route reflectors but actually it is not. In route reflectors, all the iBGP routers within an AS sends updates to the concentration router and concentration router will advertises these updates to all other routers, eventually same update all over the network to all other routers. In central routing, though all routers send update to the central node, but central node will keep all these updates with it and will advertise only when any router demands for it.
Secondly in router reflectors both data and control planes are inseparable whereas in central routing, the control plane is separated from data plane and is controlled by a software program.
4.2 Algorithm for shortest path search
Step 1: Discover all the neighbours of source and destination
Step 2: If no neighbours for either source or destination found, goto Step 10
Step 3: Enter all neighbours row wise, separate for source and destination
Step 4: Search for common element between source row and destination row entities
Step 5: If match found, goto Step 9 else goto Step 4 until all combinations are checked
Step 6: Select next undiscovered element from start of matrix and discover its peers
Step 7: Discard already discovered neighbours
Step 8: Goto Step 3
Step 9: Return path string
Step 10: Return ‘No Match Found’
Step 11: End
Figure 4.2.1: Flowchart for shortest path search
4.2.1 Description of Algorithm 4.2
Searching for the best possible path between source and destination is done by Java class xsearch_path. This class will search for the shortest path between source and destination and will return the entire string of every router’s id between source and destination.
In case of more than one least hop count path between source and destination, the first match path in database will be selected.
To search for the least hop count between source and destination, xget_path method of xsearch_path class will accept two parameters, that is, source id and destination id.
Method xget_path will check whether the source id and destination id are same or not. If they are not same, then it will first discover all the neighbours of both source and destination and will arrange them in two dimensional matrix. The size of matrix will be calculated by the number of nodes in an AS and number of highest connected neighbours to a router.
Now all the entries will be matched with each other and if match is found then path will be returned. If match is not found then starting from the start of the matrix all the nodes will be explored and their neighbours will be discovered and will be arranged in new row in matrix and one by one each of them will be matched with their opposite nodes (source and destination neighbouring nodes are considered to be opposite nodes). For example consider routers in any AS as shown below in figure 4.
Consider the sample network shown in figure 4 in testing section. Router 11 is source and router 14 is the destination. So router 6 is the neighbour of source router and routers 13 and 9 are the neighbours of destination. So in the first iteration matrix will look as show in Table 1 below.
TABLE 4.2.1: FIRST SAMPLE ITERATION
S 11 6 0
D 14 9 13
Along with matrix from router ids, xget_path method will also maintain a separate array to keep track of router’s id whether they belong to source or destination denoting by ‘S’ and ‘D’ respectively and also that first column in the matrix will not be included in searching, they will be instead needed only when match is found between S and D to form a path between source and destination. Also during the exploration the nodes which are repeating and already searched or discovered will not be added again.
As there is no match between S and D, first element of S, that is, 6 will be selected and its neighbours will be discovered and will be matched with all the elements of D and then matrix will look as
TABLE 4.2.2 SECOND SAMPLE ITERATION
S 11 6 0 0
D 14 9 13 0
S 6 5 7 12
Search and adding of new rows will be continued between S and D rows until the match is found. Logic in xget_path method in such a manner to avoid the search between S-S and D-D, it will always between S and D.
Finally keeping on discovering neighbours of both source and destination, the matrix looks as table below. As shown below a match id between source and destination is 7 which is marked in yellow. All the cells marked in green are path towards source and that in blue are path towards destination.
TABLE 4.2.3 FINAL SAMPLE ITERATION
S 11 6 0 0
D 14 9 13 0
S 6 5 7 12
D 9 1 8 0
D 13 7
5. TESTING
To support and evaluate the all point in the favour of Central Routing, consider the following sample network in the figure below. Assume that this sample network consists of total of 17 iBGP nodes of the same AS.
In conventional iBGP, no matter mesh topology or route reflector is used, each node will keep track of all other routers in AS. So on every node, routing table will have atleast 16 entries, one for each neighbour. In this way there would be 17 routing table and all with about 16 entries will make total of 272 records. Moreover the growth of routing table will be exponential as newer and newer nodes are added so the size of routing tables can be imagined in case of medium to very large networks.
But unlike these traditional approaches, in proposed system there is a sharp plunged in the size of the routing tables at each node. The only node which will be having a heavy routing table is the central node, remaining all other nodes will have comparatively very small routing tables with the entries of immediate neighbours only. The routing table of the central node of the sample network is shown in Table 4 below.
Figure 5.1: Sample Network
Figure 5.2: Output of program
TABLE 5.1 DATABASE OF CENTRAL NODE OF SAMPLE NETWORK
source_id dest_id
1 9
1 2
1 18
2 17
2 8
2 3
3 15
3 4
4 5
5 6
6 12
6 11
6 7
7 13
7 8
8 9
9 14
13 14
15 16
6. CONCLUSION
BGP is one of the key protocols used in networks. Full mesh topology in iBGP needs a router to establish a connection with all other routers in AS which can cause serious problems such as memory shortage, high networking overheads, heavy traffic over a link and overload on processor. The concept of router reflectors can overcome these issues upto much extent but is also not fully scalable and faces problems of forwarding loops. However, none of them can overcome to the problem of the rapid growth of the routing tables.
The idea of Central Routing not only combines the benefits of mesh topology and route reflectors both, but also dramatically reduces the size of routing table.
As the demand of effective, scalable and economic networks is growing, in future majority of network components will be controlled by software defined networks and cost of network management will fall.
APPENDIX A
Java class to add new nodes and paths to the central router
import java.sql.*;
import java.util.Scanner;
class xadd_routes
{
Scanner scan = new Scanner(System.in);
void xadd_neighbor()
{
int cnt;
Connection conn=null;
System.out.println("Please enter router’s id: ");
int node_router = scan.nextInt();
System.out.println("Please specify number of neighbors: ");
int cnt_nei=scan.nextInt();
int[] nei=new int[cnt_nei];
int del_cnt=0;
System.out.println("Please enter neighbor’s ids: ");
try
{
conn=DriverManager.getConnection("jdbc:derby:db_cen_rtng");
Statement s= conn.createStatement();
for(cnt=0;cnt<cnt_nei;cnt++)
{
nei[cnt]=scan.nextInt();
ResultSet rs=s.executeQuery("select count(*) from tb_root where source_id="+node_router+" and "+"dest_id="+nei[cnt]);
rs.next();
if(rs.getInt(1)==0)
{
ResultSet rs1=s.executeQuery("select count(*) from tb_root where source_id="+nei[cnt]+" and "+"dest_id="+node_router);
rs1.next();
if(rs1.getInt(1)==0)
{
conn.createStatement().execute("insert into tb_root values("+node_router+","+nei[cnt]+")");
}
}
}
ResultSet rs=s.executeQuery("select dest_id from tb_root where source_id="+node_router+" union select source_id from tb_root where dest_id="+node_router);
while(rs.next())
{
for(cnt=0;cnt<cnt_nei;cnt++)
{
if(rs.getInt(1)==nei[cnt])
break;
else
del_cnt++;
}
if(del_cnt>=cnt_nei)
{
conn.createStatement().execute("delete from tb_root where source_id="+node_router+" and dest_id="+rs.getInt(1));
conn.createStatement().execute("delete from tb_root where dest_id="+node_router+" and source_id="+rs.getInt(1));
}
del_cnt=0;
}
}
catch(Exception e)
{
System.out.println("Error occurred during adding routes");
}
}
}
APPENDIX B
Java class to search the shortest possible path between source and destination
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.ResultSet;
import java.sql.Statement;
class xsearch_path
{
String xget_path(int src,int dest)
{
if(src==dest)
return "Source and destination are same";
try
{
Connection conn = null;
conn = DriverManager.getConnection("jdbc:derby:db_cen_rtng");
Statement s=conn.createStatement();
conn.createStatement().execute("create view v1(id,interface) as select source_id,count(source_id) from tb_root group by source_id union select dest_id,count(dest_id) from tb_root group by dest_id");
ResultSet rs=s.executeQuery("select count(interface) from v1 where id="+dest);
rs.next();
if (rs.getInt(1)<1)
{
s.executeUpdate("drop view v1");
return "No path exist";
}
rs=s.executeQuery("select count(interface) from v1 where id="+src);
rs.next();
if (rs.getInt(1)<1)
{
s.executeUpdate("drop view v1");
return "No path exist";
}
rs=s.executeQuery("select sum(interface) from v1 group by id");
int colmax=0;
while(rs.next())
{
if(rs.getInt(1)>colmax)
{
colmax=rs.getInt(1);
}
}
s.executeUpdate("drop view v1");
rs=s.executeQuery("select count(distinct(source_id)) from tb_root");
rs.next();
int rowmax=rs.getInt(1);
rowmax=rowmax*colmax;
int[][] matrix=new int[rowmax][colmax+1];
char[] state=new char[rowmax];
for(int col=0;col<rowmax;col++)
state[col]=’x’;
int col=1;
matrix[0][0]=src;
state[0]=’s’;
matrix[1][0]=dest;
state[1]=’d’;
rs=s.executeQuery("select dest_id from tb_root where source_id="+src+" union select source_id from tb_root where dest_id="+src);
while(rs.next())
{
matrix[0][col]=rs.getInt(1);
col++;
}
col=1;
rs=s.executeQuery("select dest_id from tb_root where source_id="+dest+" union select source_id from tb_root where dest_id="+dest);
while(rs.next())
{
matrix[1][col]=rs.getInt(1);
col++;
}
int i=1,j=1,k=0,z=1,p=0,q=0,r=0,c=0,d=0;
char st=’s’,sd=’d’;
String source="",destination="",status="not done";
while(j<=colmax && matrix[i][j]>0)
{
while(k<=colmax && matrix[i-1][k]>0)
{
if(matrix[i][j]==matrix[i-1][k])
{
if(k==0)
{
z=-5;
return src+"."+dest;
}
else
{
z=-5;
return src+"."+matrix[i][j]+"."+dest;
}
}
k++;
}
if(z==-5)
break;
j++;
k=0;
}
if(z!=-5){
z=1;
for(i=0;i<rowmax;i++)
{
st=state[i];
while(state[i]==st && z<=colmax && matrix[i][z]>0)
{
while(state[k]!=’x’){k++;}
state[k]=state[i];
rs=s.executeQuery("select dest_id from tb_root where source_id="+matrix[i][z]+" union select source_id from tb_root where dest_id="+matrix[i][z]);
j=1;
matrix[k][0]=matrix[i][z];
while(rs.next())
{
for(c=0;c<k;c++)
{
for(d=0;d<=colmax;d++)
{
if(rs.getInt(1)==matrix[c][d] && state[c]==state[k])
{
status="present";
break;
}
}
}
if(status!="present")
{
matrix[k][j++]=rs.getInt(1);
}
status="absent";
}
r=0;
p=i+1;
q=0;
while(r<=colmax && matrix[k][r]>0)
{
while(p<=k-1 && matrix[k][r]>0 && state[p]!=state[k])
{
while(q<=colmax && matrix[p][q]>0)
{
if(matrix[k][r]==matrix[p][q])
{
status="done";
break;
}
if(status=="done")
break;
q++;
}
if(status=="done")
break;
r++;
q=0;
}
if(status=="done")
break;
p++;
r=0;
if(p>=k)
break;
}
if(status=="done")
break;
z++;
}
if(status=="done")
break;
z=1;
}
}
if(z!=-5){
int dc=0;
if(state[k]==’s’)
{
c=k;
d=p;
dc=q;
}
else
{
d=k;
dc=r;
c=p;
}
int[] s1=new int[rowmax];
int count=1;
s1[0]=matrix[c][0];
z=c;
for(i=c-1;i>=0;i–)
{
for(j=0;j<=colmax;j++)
{
if(state[i]==state[c] && matrix[i][j]==matrix[z][0])
{
s1[count++]=matrix[i][0];
z=i;
break;
}
}
}
z=d;
destination=destination+matrix[d][dc]+"."+matrix[d][0];
for(i=d-1;i>=0;i–)
{
for(j=0;j<=colmax;j++)
{
if(state[i]==state[d] && matrix[i][j]==matrix[z][0])
{
destination=destination+"."+matrix[i][0];
z=i;
break;
}
}
}
count–;
for(i=count;i>=0;i–)
{
source=source+s1[i]+".";
}
return source+destination;
}
}
catch(Exception e)
{
System.out.println("No valid path exist");
}
return;
}
}
References
[1]. http://wiki.mikrotik.com/wiki/Manual:BGP_Case_Studies (13/04/14 10:51 A.M.)
[2]. http://www.cisco.com/web/about/ac123/ac147/images/ipj/ipj_4-1/fig-5a.gif (19/04/14 9:42 A.M.)
[3]. http://upload.wikimedia.org/wikipedia/commons/c/ce/BGP_Table_growth.svg (19/04/14 9:45 A.M.)