| line |
stmt |
bran |
cond |
sub |
pod |
time |
code |
|
1
|
|
|
|
|
|
|
#!/usr/bin/perl |
|
2
|
|
|
|
|
|
|
|
|
3
|
|
|
|
|
|
|
package Net::BGP; |
|
4
|
|
|
|
|
|
|
|
|
5
|
3
|
|
|
3
|
|
2216
|
use strict; |
|
|
3
|
|
|
|
|
5
|
|
|
|
3
|
|
|
|
|
136
|
|
|
6
|
3
|
|
|
3
|
|
14
|
use vars qw( $VERSION ); |
|
|
3
|
|
|
|
|
5
|
|
|
|
3
|
|
|
|
|
224
|
|
|
7
|
|
|
|
|
|
|
|
|
8
|
|
|
|
|
|
|
## Inheritance and Versioning ## |
|
9
|
|
|
|
|
|
|
|
|
10
|
|
|
|
|
|
|
$VERSION = '0.16'; |
|
11
|
|
|
|
|
|
|
|
|
12
|
|
|
|
|
|
|
## End Code Section ## |
|
13
|
|
|
|
|
|
|
|
|
14
|
|
|
|
|
|
|
=pod |
|
15
|
|
|
|
|
|
|
|
|
16
|
|
|
|
|
|
|
=head1 NAME |
|
17
|
|
|
|
|
|
|
|
|
18
|
|
|
|
|
|
|
Net::BGP - Border Gateway Protocol version 4 speaker/listener library |
|
19
|
|
|
|
|
|
|
|
|
20
|
|
|
|
|
|
|
=head1 SYNOPSIS |
|
21
|
|
|
|
|
|
|
|
|
22
|
|
|
|
|
|
|
use Net::BGP::Process; |
|
23
|
|
|
|
|
|
|
use Net::BGP::Peer; |
|
24
|
|
|
|
|
|
|
|
|
25
|
|
|
|
|
|
|
$bgp = Net::BGP::Process->new(); |
|
26
|
|
|
|
|
|
|
$peer = Net::BGP::Peer->new( |
|
27
|
|
|
|
|
|
|
Start => 1, |
|
28
|
|
|
|
|
|
|
ThisID => '10.0.0.1', |
|
29
|
|
|
|
|
|
|
ThisAS => 64512, |
|
30
|
|
|
|
|
|
|
PeerID => '10.0.0.2', |
|
31
|
|
|
|
|
|
|
PeerAS => 64513 |
|
32
|
|
|
|
|
|
|
); |
|
33
|
|
|
|
|
|
|
|
|
34
|
|
|
|
|
|
|
$bgp->add_peer($peer); |
|
35
|
|
|
|
|
|
|
$peer->add_timer(\&my_timer_callback, 60); |
|
36
|
|
|
|
|
|
|
$bgp->event_loop(); |
|
37
|
|
|
|
|
|
|
|
|
38
|
|
|
|
|
|
|
=head1 DESCRIPTION |
|
39
|
|
|
|
|
|
|
|
|
40
|
|
|
|
|
|
|
This module is an implementation of the BGP-4 inter-domain routing protocol. |
|
41
|
|
|
|
|
|
|
It encapsulates all of the functionality needed to establish and maintain a |
|
42
|
|
|
|
|
|
|
BGP peering session and exchange routing update information with the peer. |
|
43
|
|
|
|
|
|
|
It aims to provide a simple API to the BGP protocol for the purposes of |
|
44
|
|
|
|
|
|
|
automation, logging, monitoring, testing, and similar tasks using the power |
|
45
|
|
|
|
|
|
|
and flexibility of perl. The module does not implement the functionality of |
|
46
|
|
|
|
|
|
|
a RIB (Routing Information Base) nor does it modify the kernel routing table |
|
47
|
|
|
|
|
|
|
of the host system. However, such operations could be implemented using the |
|
48
|
|
|
|
|
|
|
API provided by the module. |
|
49
|
|
|
|
|
|
|
|
|
50
|
|
|
|
|
|
|
The module takes an object-oriented approach to abstracting the operations |
|
51
|
|
|
|
|
|
|
of the BGP protocol. It supports multiple peering sessions and each peer |
|
52
|
|
|
|
|
|
|
corresponds to one instance of a B object. The details of |
|
53
|
|
|
|
|
|
|
maintaining each peering session are handled and coordinated by an instance |
|
54
|
|
|
|
|
|
|
of a B object. BGP UPDATE messages and the routing |
|
55
|
|
|
|
|
|
|
information they represent are encapsulated by B objects. |
|
56
|
|
|
|
|
|
|
Whenever protocol errors occur and a BGP NOTIFICATION is sent or received, |
|
57
|
|
|
|
|
|
|
programs can determine the details of the error via B |
|
58
|
|
|
|
|
|
|
objects. |
|
59
|
|
|
|
|
|
|
|
|
60
|
|
|
|
|
|
|
The module interacts with client programs through the paradigm of callback |
|
61
|
|
|
|
|
|
|
functions. Whenever interesting protocol events occur, a callback function |
|
62
|
|
|
|
|
|
|
supplied by the user is called and information pertaining to the event is |
|
63
|
|
|
|
|
|
|
passed to the function for examination or action. For instance, whenever an |
|
64
|
|
|
|
|
|
|
UPDATE message is received from a peer, the module handles the details of |
|
65
|
|
|
|
|
|
|
decoding the message, validating it, and encapsulating it in an object and |
|
66
|
|
|
|
|
|
|
passing the object to the specific callback function supplied by the user |
|
67
|
|
|
|
|
|
|
for UPDATE message handling. The callback function is free to do whatever |
|
68
|
|
|
|
|
|
|
with the object - it might send a Net::BGP::Update object to other peers |
|
69
|
|
|
|
|
|
|
as UPDATE messages, perhaps after modifying some of the UPDATE attributes, |
|
70
|
|
|
|
|
|
|
log the routing information to a file, or do nothing at all. The |
|
71
|
|
|
|
|
|
|
possibilities for implementing routing policy via such a mechanism are |
|
72
|
|
|
|
|
|
|
limited only by the expressive capabilities of the perl language. It should |
|
73
|
|
|
|
|
|
|
be noted however that the module is intended for the uses stated above and |
|
74
|
|
|
|
|
|
|
probably would not scale well for very large BGP meshes or routing tables. |
|
75
|
|
|
|
|
|
|
|
|
76
|
|
|
|
|
|
|
The module must maintain periodic protocol keep-alive and other processes, |
|
77
|
|
|
|
|
|
|
so once control is passed to the module's main event loop, control flow |
|
78
|
|
|
|
|
|
|
only passes back to user code whenever one of the callback functions is |
|
79
|
|
|
|
|
|
|
invoked. To provide more interaction with user programs, the module allows |
|
80
|
|
|
|
|
|
|
user timers to be established and called periodically to perform further |
|
81
|
|
|
|
|
|
|
processing. Multiple timers may be established, and each is associated with |
|
82
|
|
|
|
|
|
|
a single peer. Whenever the timers expire, a user supplied function is called |
|
83
|
|
|
|
|
|
|
and the timer is reset. The timer callback functions can perform whatever |
|
84
|
|
|
|
|
|
|
actions are necessary - sending UPDATEs, modifying the state of the peering |
|
85
|
|
|
|
|
|
|
session, house-keeping, etc. |
|
86
|
|
|
|
|
|
|
|
|
87
|
|
|
|
|
|
|
=head1 BUGS |
|
88
|
|
|
|
|
|
|
|
|
89
|
|
|
|
|
|
|
The connection collision resolution code is broken. As currently implemented, |
|
90
|
|
|
|
|
|
|
whenever a connection is received from a peer, the B object |
|
91
|
|
|
|
|
|
|
is cloned and each peer object proceeds through the session establishment |
|
92
|
|
|
|
|
|
|
process until the collision resolution procedure is reached. At this point, if |
|
93
|
|
|
|
|
|
|
the cloned object is chosen by the collison resolution procedure, the original |
|
94
|
|
|
|
|
|
|
peer object is destroyed, leaving the cloned object. Unfortunately, a user |
|
95
|
|
|
|
|
|
|
program will only have a reference to the original peer object it created and |
|
96
|
|
|
|
|
|
|
will have no way of accessing the cloned object. It is therefore recommended |
|
97
|
|
|
|
|
|
|
that B objects be instantiated with the B parameter |
|
98
|
|
|
|
|
|
|
set to a false value. This prevents the peer object from receiving connections |
|
99
|
|
|
|
|
|
|
from its BGP peer, although it will continue actively attempting to establish |
|
100
|
|
|
|
|
|
|
sessions. This problem will be addressed in a future revision of B. |
|
101
|
|
|
|
|
|
|
|
|
102
|
|
|
|
|
|
|
As an initial revision, the code has not been subjected to a thorough security |
|
103
|
|
|
|
|
|
|
audit. It is possible and likely that exploitable code exists in the packet |
|
104
|
|
|
|
|
|
|
decoding routines. Therefore, it is recommended that the module only be used |
|
105
|
|
|
|
|
|
|
to establish peering sessions with trusted peers, particularly if programs |
|
106
|
|
|
|
|
|
|
using the module will be run with root priviliges (which is necessary if |
|
107
|
|
|
|
|
|
|
programs want to modify the kernel routing table or bind to the well-known |
|
108
|
|
|
|
|
|
|
BGP port 179). |
|
109
|
|
|
|
|
|
|
|
|
110
|
|
|
|
|
|
|
=head1 SEE ALSO |
|
111
|
|
|
|
|
|
|
|
|
112
|
|
|
|
|
|
|
RFC 1771, and the perldocs for Net::BGP::Process, Net::BGP::Peer, Net::BGP::Update, |
|
113
|
|
|
|
|
|
|
and Net::BGP::Notification |
|
114
|
|
|
|
|
|
|
|
|
115
|
|
|
|
|
|
|
=head1 AUTHOR |
|
116
|
|
|
|
|
|
|
|
|
117
|
|
|
|
|
|
|
Stephen J. Scheck |
|
118
|
|
|
|
|
|
|
|
|
119
|
|
|
|
|
|
|
=cut |
|
120
|
|
|
|
|
|
|
|
|
121
|
|
|
|
|
|
|
## End Package Net::BGP ## |
|
122
|
|
|
|
|
|
|
|
|
123
|
|
|
|
|
|
|
1; |