IDENTIFYING LINK FAILUERS

The Project Report is submitted in partial fulfillment of the

requirements for the award of the degree of
Master of Computer Applications

Submitted by:
VADAPALLI MADHAVI VENKATA VISALAKSHI
2385351066
Under the Esteemed Guidance of
K R RAJESWARI
B.V. Raju College
Vishunupur::Bhimavaram

Submitted to
DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING
COLLEGE OF ENGINEERING
ADIKAVI NANNAYA UNIVERSITY
RAJAHMAHENDRAVARAM
2024-2025
 B.V. RAJUCOLLEGE (AUTONOMOUS)
(Re-Accredited with ‘B++’ Grade by NAAC)

Department of MCA
Vishnupur :: Bhimavaram

CERTIFICATE

This is to certify that this project entitled “IDENTIFYONG LINK FAILURES”

submitted in partial fulfillment of the degree of MASTER OF COMPUTER
APPLICATIONS to Adikavi Nanayya University from 7I TECH Solution through
B.V. Raju College, done by VADAPALLI MADHAVI VENKATA VISALAKSHI
Regd. No. 2385351066 is an authentic work carried out by her during the Academic
Year 2024-2025 at under my guidance. The matter embodied in this project work has not
been submitted earlier for award of any degree or diploma to the best of my knowledge
and belief.

Internal Guide Head of the Department

External Examiner Principal

 ACKNOWLEDGEMENT

The satisfaction and euphoria that accompany the successful completion of any
task would be incomplete without the mention of people who made it possible, whose
constant guidance and encouragement crowned our efforts with success. It is a pleasant
aspect that I have now the opportunity to express my gratitude for all of them.
The first person I would like to thank Dr.I.R. krishnam Raju, Principal MCA,
B V Raju College, Bhimavaram. His wide knowledge and logical way of thinking have
made a deep impression on me. His understanding, encouragement and personal guidance
have provided the basis for this thesis. He is a source of inspiration for innovative ideas
and his kind support is well known to all his students and colleagues.
I wish to thank Dr. V. BHASKARA MURTHY, Professor& HOD, Dept of
MCA. His support and valuable suggestions for the successful completion of this project.
I wish to thank my guide [Link], Assistant Professor, Dept. of MCA his
support and valuable suggestions for the successful completion of this Project.

VADAPALLI MADHAVI VENKATA VISALAKSHI

2385351066
 DECLARATION

This is to certify that the project report entitled “IDENTIFYING LINK

FAILURES” is done by me is an authentic work carried out for the partial
fulfillment of the requirements for the award of the degree of Master of
Computer Applications under the guidance of [Link] Assistant
Professor, Dept. of MCA. The matter embodied in this project work has not
been submitted earlier for award of any degree or diploma to the best of my
knowledge and belief.

Signature of the student

VADAPALLI MADHAVI VENKATA VISALAKSHI
2385351066
[Link] College.
 INDEX
Chapter Page No

1. INTRODUCTION 1-6

1.1 Distinctions between BGP monitoring and this model 1

1.2 Identifying Faults Using a Single Vantage Point 2-6

2. PROBLEM SPECIFICATION 7

3. SOFTWARE REQUIREMENTS SPECIFICATION 9-12

3.1 Existing System 10

3.2 Proposed System 10

3.3 System Requirements 10

3.4 Functional Requirements 11

3.5 Non-Functional Requirements 12

4. SYSTEM DESIGN 13-17

4.1 Use Case Diagram 14

4.2 Class Diagram 15

4.3 Sequence Diagram 16

4.4 Activity Diagram 17

5. SYSTEM IMPLEMENTATION 18-24

6. SCREENS 25-38

7. TESTING 39-40

8. CONCLUSION 41-42

9. BIBILIOGRAPHY 43-44
INTRODUCTION
 [Link]

In this project a formal approach for analyzing routing data to identify the origin of
routing changes is provided. Using a simplified model of BGP and a graph model of the Internet,
FindChange algorithm set is presented. Note that even a single link failure or link addition can
result in large number of BGP path changes, but finding this change without knowledge of the
underlying topology can be a challenge. As a algorithms for understanding internet route
changes, identifying the single link failure or addition that caused an observed set of changes is
focused. This approach takes snapshots of routing tables collected from vantage points, at two
different time instances, and without knowing the underlying topology, locates the link that
initiated the routing changes, as precisely as possible.
1.1 Distinctions between BGP monitoring and this model

The general problem of understanding BGP behavior based on observed updates is an open
challenge. As a first step, a few simplifying assumptions are made in this formal model.

 The edge between two nodes in VN is modeled as a single link EN and assume this link is
either available or has failed. But in actual BGP operations, the link between two AS can
be many physical connections. For example, networks of large ISPs are connected at
many places (packets can be exchanged at any of these connection points) and only some
of these many physical connections are likely to fail at once.
 An AS is modeled as a node in VN and assume each node has one “best” path. In practice,
a large AS node is not a single atomic entity and different contiguous portions of the AS,
may select and advertise different best paths.
Despite these simplifications, the formal model still presents an interesting challenge. The
techniques used to find faults in this model can be applied to the actual BGP monitoring data, taking the
above assumptions into consideration when reviewing the results.

1
1.2 Identifying Faults Using a Single Vantage Point

Considering only the view from a single monitoring point M, and an algorithm is provided that
gives a possible explanation for the routing changes observed at M. More formally, two path trees rooted
at M: T0 = (V0, E0)is the path tree at time t o and T1 = (V1, E1) is the path tree at time t 1are given. Both
T0andT1 were computed in some unspecified graph G = (V, E) and if T 0≠ T1,some link(s) in G = (V, E)
must have failed (or recovered). Objective of this model is to identify some scenario of failed (and/or
recovered) links that explain the change from T0to T1. Toward this end, an algorithm that assigns labels
to each edge and identifies one possible scenario for the route change event is presented. Later it is
shown how the output of this algorithm can be easily extended to identify every possible single-event
scenario and how to use the view from single monitoring point to identify, as precisely as possible, the
failed (or recovered) link.
Algorithm Find Change takes trees T0 = (V0, E0) and T1 = (V1, E1) as input and labels each edge
in E0U E1 as either unchanged, vanished, or appeared. A vanished link is present in T0, but not present in
T1. This can occur due to the failure of the link or the link may vanish as a consequence of some other
change. The actual failed edges are distinguished from the other vanished edges by labeling failed edges
as failed. Similarly, edges that recovered or whose additions caused route changes are marked added.
Note that edges marked appeared may not have changed state (from down to up), but simply became part
of the path tree as a consequence of some other event.
Conceptually, the algorithm is relatively simple. To identify a link failure, the algorithm
combines T0and T1 and then starts by calculating a path tree, T fail in this combined graph. Note that if
only a link failure has occurred, T fail=T0and the algorithm progressively transforms T fail by removing
links that are absent in [Link] failed links are those whose removal changes Tfail and we adjust Tfail after
each change. Similarly in the case of a link recovery, Tadd= T1 is transformed to get T0, to identify the
restored link. It is not given whether a link failure or link recovery (or both) have occurred, but it can be
observed that the two steps can be run in parallel as shown in Algorithm.

2
ALGORITHM: FindChange(T0, T1)
Input:T0 = (V0, E0) : The PT from M at t0 ;
T1 = (V1, E1) ; The PT from M at t1 ;
Output: Marked edges: unchanged, vanished, failed, added ;
Let V = V0 U V1, Eadd = Efail = E = E0 U E1 ;
Let Tfail = Tadd= PT(V,E) ;
For each e є E do
if e є E0 ∩ E1 then
e = unchanged;
else if e є E0 then
e = vanished
if e є Tfail
then e =
failed;
Efail = Efail – e;
Tfail = PT(V,
Efail); else if e є E1
then
e = appeared;
if e є Tadd then
e = added;
Eadd = Eadd – e;
Tadd = PT(V, Eadd);

Figure below provides an example showing the execution of the algorithm. Three prefixes, P1,P2
and P3are advertised from AS-4, AS-6 and AS-5 (respectively). Figure 1 shows T1, the path tree at time
t1. Note that the path to prefix P 3 has not changed, but an event has changed the paths from M to prefixes
P1 and P2. The algorithm will label each edge as unchanged, vanished, or appeared and will select one
edge as the cause.

3
 Figure 1: Input Graphs

The algorithm first combines the two trees T0 and T1 to obtain the graph shown in Figure
2 and computes a new path tree in this combined graph. Each edge is tested and labeled accordingly.
Edge (M, 1) appears in both graphs and is labeled unchanged. Edge (1, 2) appears only in T 0 and is
labeled as vanished. Furthermore, edge (1,2) is in the PT Tfail and thus edge (1, 2) is marked as a failed
link and anew PT Tfailis computed after excluding edge
(1, 2), as shown in Figure 3. Each of the additional edges are tested and are either present in both trees
and labeled as unchanged or not present in T fail(or Tadd) and labeled as vanished or appeared. Note that
for edges (5, 4) and (5, 6), since they are present in T 1, their membership has to be checked in T add and
not Tfail. The resulting labels are shown in Figure 4, where F denotes failed, A denotes appeared, V
denotes vanished, and U denotes unchanged.

4
Figure 2: Graph after merging

Figure 3: Removing failed edges

5
 Figure 4: Labeling edges

In this figure
‘F’ represents failed
‘U’ represents
unchanged ‘A’
represents available

Here, the algorithm identified link (1, 2) as failed link. All other links did not change state,
though they moved into or out of the path tree as a consequence of this single failure. While this scenario
is a feasible explanation for the change observed at M, it is not the only possible explanation. The failure
of only link (2, 4) could have also caused the change fromT 0 toT1. In addition, a variety of multi-
failure/recovery events could have caused the change, such as the recovery of link (4, 5) combined with
failure of links (4, 6) and link (2, 4). Any one of these events is a plausible explanation and the exact
cause cannot be determined from only T0 and T1.

6
PROBLEM SPECIFICATION

7
 2. PROBLEM SPECIFICATION

This system provides an approach to identify link failures along with links that are restored and the links
unchanged by implementing an algorithm called Find change using graph theory of internet.
Here, two snapshots of a network is taken as input in the form of graphs, at two different timings with
each vertex indicating a system and each edge indicating link between two systems.
These two graphs are compared and a new graph is formed by merging these two graphs. Now each
edge in the merged graph is taken and checked if it is present in both the graphs which have been taken
as input, if yes then label that edge as an unchanged edge, else if the edge is present in the first graph
then label it as failed link, else if the edge is present in second graph then label as restored link.
Finally, the links which are failed, restored and unchanged are displayed.

8
SOFTWARE REQUIREMENTS SPECIFICATION

9
 3. SOFTWARE REQUIREMENTS SPECIFICATION
3.1 Existing System:

An ad-hoc combination of intuition, experience, and informal analysis is often used to speculate
the causes of large swings in BGP updates. In addition to the challenge of scale, the underlying Internet
topology is not known precisely and the monitoring points provide views from only a limited set of
geographic locations. In such an environment, ad-hoc techniques are limited by the expertise of the
administrator and it is not easy to identify the underlying events that cause BGP changes. To provide
dependable global data delivery, analysis tools are needed that can help us to understand the BGP system
and pinpoint the exact cause of connectivity changes.
3.2 Proposed System:

A formal approach is provided to identify the link failures which are supposed to cause route changes
and pinpoint exact connectivity changes. Along with the links failed, the links which are restored or
newly added, the links which remains unchanged are identified and the number of links failed, restored,
unchanged.
3.3 System Requirements:
Software Requirements

OS : Windows
Project Platform : Java
Software : JDK1.5
User Interface :
Frames

Hardware Requirements
Key Board : Standard Key Board with 101
Keys Processor : Pentium IV
Monitor : SVGA Color
Monitor Hard disk : 20 GB

10
RAM : 256 MB

11
3.4 Functional Requirements:

Input:

1. Entering initial graph in csv file format with first value in each line
representing vertex followed by its edges separated by commas.
2. Entering final graph in csv file format with first value in each line
representing vertex followed by its edges separated by commas.

12
 Generating Graph:
1. Generate graphs based on the input given in files
2. Next merge the two input graphs into a single

Detecting Changes:
Comparison of each edge in merged graph with edges in both initial and final graph gives
links
1. Unchanged
2. Failed
3. Restored

3.5 Non-Functional Requirements

In systems engineering and requirements engineering, non-functional requirements are

requirements which specify criteria that can be used to judge the operation of a system, rather than
specific behaviors.
The non functional requirements the system should satisfy are
1. Usability
2. Scalability
3. Validated inputs

13
SYSTEM DESIGN

14
SYSTEM DESIGN

3.6 Use case Diagram

Figure 5: Use case diagram

15
3.7 Class Diagram

Figure 6: Class diagram

16
3.8 Sequence Diagram

Figure 7: Sequence diagram

17
3.9 Activity Diagram:

18
SYSTEM IMPLEMENTATION

19
 4. SYSTEM IMPLEMENTATYION

Code For Identifying Link Failures:

import [Link].*;
import [Link].*;
public class ilink
{
vertex vroot,vp,vt,vroot2,vp2,vt2,vroot3,vp3,vt3,vp4,vroot4;
edge eroot,ep,et,eroot2,ep2,et2;
Vector rawData,rawData2;
String initLinks="",finalLinks="";
String
unchangedLinks="",failedLinks="",addedLinks=""; int
uc=0,fc=0,ac=0;
/** taking input files as ipath and fpath and generating initial ad final graphs as input
given by the user*/
ilink(String ipath,Stringfpath)
{
vroot=GenInitGraph(vroot,ipath); //generating intial graph and storing
vroot2=GenInitGraph(vroot,fpath); // generating final graph and storing
[Link]("For Merging..");
vroot3=MergeGraph(vroot,vroot2);//merging two graphs into one
[Link]("VROOT");
vroot=GenInitGraph(vroot,ipath);
showVertex(vroot,1); //displays the vertices and edges of initial graph
[Link]("VROOT2");
showVertex(vroot2,2); //displays the vertices and edges of final graph
[Link]("MVROOT");
showVertex(vroot3,3); //displays the vertices and edges of merged graph
[Link]("Analysis");
isVertexFound(); //checks whether edge of a vertex

20
}

21
 if(edr==null)
{
edr=et;
}
else
{

ep=edr; while([Link]!
=null)
{
ep=[Link];
}
[Link]=et;
}
e1=[Link];
}
while(e2!=null)
{
if(!isFound(edr,e2.e))
{
et=new edge();
et.e=e2.e;
[Link]=null;
[Link]("xx " + e2.e);
if(edr==null)
{
edr=et;

}
else
{

22
 while([Link]!=null)
{
ep=[Link];
}
[Link]=et;
}
}
e2=[Link];
}

[Link]("edge..");
//showEdge(edr);
[Link]("end edge..");
return edr;
}
//Code for checking edges of a vertex:
void isVertexFound()
{
vp=vroot3; while(vp!
=null)
{
[Link](vp.v);
ep=vp.e; while(ep!
=null)
{
[Link](" " + ep.e);
boolean f=isInitEdgeFound(vp.v,ep.e);
boolean f2=isFinalEdgeFound(vp.v,ep.e);
if(f==true && f2==true)
{

23
 unchangedLinks+=vp.v + " --> " + ep.e "\n"; uc+
+;
}
else if(f==true)
{
failedLinks+=vp.v + " --> " + ep.e+"\n"; fc+
+;
}
else
{
addedLinks+=vp.v + " --> " + ep.e+"\n";
ac++;
}

ep=[Link];
}
vp=[Link];
}
}
//code for checking edge in initial graph:
booleanisInitEdgeFound(String v,String e)
{
vp3=vroot; while(vp3!
=null)
{
if([Link](v))
{
ep2=vp3.e; while(ep2!
=null)
{

24
if([Link](e))

25
 return true;
ep2=[Link];
}
}
vp3=[Link];
}
return false;
}
//code for checking edge in final graph:
booleanisFinalEdgeFound(String v,String e)
{
vp3=vroot2; while(vp3!
=null)

return false;
}

//Code for displaying edges of a vertex:

public void showEdge(edge e,intidx)
{
ep=e;
[Link]("");

while(ep!=null)
{
[Link](" " + ep.e);
if(idx==1)
initLinks+="Edge " +
ep.e; if(idx==2)
finalLinks+="Edge " +
ep.e; ep=[Link];
}
[Link]("");
26
 {

edge ef=isVertexFound(vr,s);
prt="";[Link]("start:");
}

//Code for displaying vertices of a graph:

public void showVertex(vertex root,intidx)
{
vp=root;
if(root==null)
{
initLinks+="no input";
finalLinks+="no input";
}
while(vp!=null)
{
[Link](vp.v);
if(idx==1)
initLinks+="\nVertex " + vp.v
; if(idx==2)
finalLinks+="\nVertex " +
vp.v; showEdge(vp.e,idx);
vp=[Link];
}

27
SCREENS

28
 5. SCREENS

Input graphs:

29
User interface:

30
Taking initial input:

31
Taking final input:

32
Displaying links in initial graph:

33
Displaying links in final graph:

34
Showing links unchanged:

35
Showing links failed:

36
Showing links restored:

37
Path in initial graph:

38
Path in final graph:

39
Input error:

40
Error Detecting Changes:

41
TESTING

42
 5. TESTING

Actual
Test case No: Test Case Expected Result
Result

If we click on
Returns the message
1 detect changes do
“cannot detect : enter
button without
input”
taking input
If we click on
buttons get initial
2 links and get final Returns the message “no input” do
links without
taking
input
If we exited from the
Returns the message “cannot
select file dialog box
3 find text file. Do you want to do
without selecting a
create a new file”
file

43
CONCLUSION

44
 6. CONCLUSION

Utilizing the information collected from Single vantage points, Find Change has pin down the
exact location of the connectivity changes. Connectivity changes such as link failures and link addition
or restoration have been identified. In order to build diagnostic tools for the global routing
infrastructure, FindChange algorithm is used to identify the origin of routing changes caused by a single
link Failure. FindChange represents an important first step towards applying formal methods to inter-
domain routing diagnosis.

FUTURE SCOPE:
Scope for future work includes extending FindChange to apply over information collected from
multiple vantage points and also to cover increasingly more complex failure cases.

45
BIBLIOGRAPHY

46
 [Link]

Book references:
1. “The Complete Reference JAVA 2” by Patrick Naughton and Herbert Schildt
2. “Computer Networks” by [Link]
3. “JAVA: How To Program” by Dietel and Deitel
4. “Software Engineering, A Practitioner’s Approach” by [Link]
5. “Software Engineering” by Sommerville
6. “The Unified Modeling Language User Guide” by Grady Booch, James
Rambaugh, Ivar Jacobson
Web references:
1. [Swings]
[Link]
2. [Object oriented modeling and design]
[Link]
3.[Graph theory of internet]
[Link]
internet-hardware/

Paper references:
1. R. Govindan and H. Tangmunarun kit. Heuristics for internet map discovery. In IEEE
INFOCOM 2000, pages 1471–1380, Tel Aviv, Israel, March 2000. IEEE.
2. Y. Rekhter and T. Li. A border gateway protocol (BGP-
4). Request for Comment (RFC): 1771, Mar. 1995.
3. M. Lad, B. Zhang, X. Zhao, D. Massey, and L. Zhang. Analysis of BGP Update Surge
during Slammer attack. In Proceedings of 5th International Workshop on Distributed Computing,
Dec. 2003.

47