1Net::BGP::Peer(3)     User Contributed Perl Documentation    Net::BGP::Peer(3)
2
3
4

NAME

6       Net::BGP::Peer - Class encapsulating BGP-4 peering session state and
7       functionality
8

SYNOPSIS

10           use Net::BGP::Peer;
11
12           $peer = Net::BGP::Peer->new(
13               Start                => 1,
14               ThisID               => '10.0.0.1',
15               ThisAS               => 64512,
16               PeerID               => '10.0.0.2',
17               PeerAS               => 64513,
18               PeerPort             => 1179,
19               ConnectRetryTime     => 300,
20               HoldTime             => 60,
21               KeepAliveTime        => 20,
22               Listen               => 0,
23               Passive              => 0,
24               AnnounceRefresh      => 1,
25               SupportCapabilities  => 1,
26               SupportMBGP          => 1,
27               SupportAS4           => 1,
28               OpenCallback         => \&my_open_callback,
29               KeepaliveCallback    => \&my_keepalive_callback,
30               UpdateCallback       => \&my_update_callback,
31               NotificationCallback => \&my_notification_callback,
32               ErrorCallback        => \&my_error_callback
33           );
34
35           $peer = renew Net::BGP::Peer("$peer");
36
37           $peer->start();
38           $peer->stop();
39
40           $peer->update($update);
41           $peer->refresh($refresh);
42
43           $version = $peer->version();
44
45           $this_id = $peer->this_id();
46           $this_as = $peer->this_as();
47           $peer_id = $peer->peer_id();
48           $peer_as = $peer->peer_as();
49
50           $i_will  = $peer->support_capabilities();
51
52           $i_mbgp  = $peer->support_mbgp();
53
54           $i_can   = $peer->this_can_refresh();
55           $peer_can= $peer->peer_can_refresh();
56
57           $peer_as4= $peer->peer_can_as4();
58
59           $listen  = $peer->is_listener();
60           $passive = $peer->is_passive();
61           $estab   = $peer->is_established();
62
63           $trans   = $peer->transport($trans);
64           @trans   = $peer->transports;
65
66           $string  = $peer->asstring();
67
68           $peer->set_open_callback(\&my_open_callback);
69           $peer->set_established_callback(\&my_established_callback);
70           $peer->set_keepalive_callback(\&my_keepalive_callback);
71           $peer->set_update_callback(\&my_update_callback);
72           $peer->set_notification_callback(\&my_notification_callback);
73           $peer->set_error_callback(\&my_error_callback);
74
75           $peer->add_timer(\&my_minute_timer, 60);
76           $peer->remove_timer(\&my_minute_timer);
77

DESCRIPTION

79       This module encapsulates the state and functionality associated with a
80       BGP peering session. Each instance of a Net::BGP::Peer object
81       corresponds to a peering session with a distinct peer and presents a
82       programming interface to manipulate the peering session state and
83       exchange of routing information. Through the methods provided by the
84       Net::BGP::Peer module, a program can start or stop peering sessions,
85       send BGP routing UPDATE messages, and register callback functions which
86       are invoked whenever the peer receives BGP messages from its peer.
87

CONSTRUCTOR

89       new() - create a new Net::BGP::Peer object
90
91       This is the constructor for Net::BGP::Peer objects. It returns a
92       reference to the newly created object. The following named parameters
93       may be passed to the constructor. Once the object is created, only the
94       callback function references can later be changed.
95
96   Start
97       Setting this parameter to a true value causes the peer to initiate a
98       session with its peer immediately after it is registered with the
99       Net::BGP::Process object's add_peer() method. If omitted or set to a
100       false value, the peer will remain in the Idle state until the start()
101       method is called explicitly by the program. When in the Idle state the
102       peer will refuse connections and will not initiate connection attempts.
103
104   ThisID
105       This parameter sets the BGP ID (IP address) of the Net::BGP::Peer
106       object. It takes a string in IP dotted decimal notation.
107
108   ThisAS
109       This parameter sets the BGP Autonomous System number of the
110       Net::BGP::Peer object. It takes an integer value in the range of a
111       16-bit unsigned integer.
112
113   PeerID
114       This parameter sets the BGP ID (IP address) of the object's peer. It
115       takes a string in IP dotted decimal notation.
116
117   PeerAS
118       This parameter sets the BGP Autonomous System number of the object's
119       peer.  It takes an integer value in the range of a 16-bit unsigned
120       integer.
121
122   PeerPort
123       This parameter sets the TCP port number on the peer to which to
124       connect. It must be in the range of a valid TCP port number.
125
126   ConnectRetryTime
127       This parameter sets the BGP ConnectRetry timer duration, the value of
128       which is given in seconds.
129
130   HoldTime
131       This parameter sets the BGP Hold Time duration, the value of which is
132       given in seconds.
133
134   KeepAliveTime
135       This parameter sets the BGP KeepAlive timer duration, the value of
136       which is given in seconds.
137
138   Listen
139       This parameter specifies whether the Net::BGP::Peer will listen for and
140       accept connections from its peer. If set to a false value, the peer
141       will only initiate connections and will not accept connection attempts
142       from the peer (unless the Passive parameter is set to a true value).
143       Note that this behavior is not specified by RFC 1771 and should be
144       considered non-standard. However, it is useful under certain
145       circumstances and should not present problems as long as one side of
146       the connection is configured to listen.
147
148   Passive
149       This parameter specifies whether the Net::BGP::Peer will attempt to
150       initiate connections to its peer. If set to a true value, the peer will
151       only listen for connections and will not initate connections to its
152       peer (unless the Listen parameter is set to false value). Note that
153       this behavior is not specified by RFC 1771 and should be considered
154       non-standard.  However, it is useful under certain circumstances and
155       should not present problems as long as one side of the connection is
156       configured to initiate connections.
157
158   Refresh
159       This parameter specifies whether the Net::BGP::Peer will annonce
160       support for route refresh ('soft re-configure' as specified by RFC
161       2918). No support for route refresh is implemented - only the
162       RefreshCallback function.  This has no effect if SupportCapabilities is
163       FALSE.
164
165   SupportCapabilities
166       This parameter specifies whether the Net::BGP::Peer will attempt to
167       negotiate capabilities.  You can set this to FALSE if talking to an old
168       BGP speaker that doesn't support it (you'll get a notification message
169       for an unsupported capability if this is the case).  This defaults to
170       TRUE.
171
172   SupportMBGP
173       This parameter specifies whether the NET::BGP::Peer will attempt to
174       negotiate MBGP.  Quagga (and probably others) need this if you want to
175       send the REFRESH capability. Today this just indicates support for IPv4
176       Unicast.  This defaults to TRUE.  This has no effect if
177       SupportCapabilities is FALSE.
178
179   SupportAS4
180       This paramemter specifies whether outgoing connections from
181       NET::BGP::Peer will attempt to negotiate AS4 (32 bit ASNs). For
182       received connections, this parameter has no effect - it only determines
183       whether or not AS4 is negotiated during outgoing connection.  For
184       received connections, this will be changed to TRUE (on the listening
185       connection) whenever the appropriate OPEN capability is received.  Note
186       that the SupportCapabilities must be true for this to be sent.  This
187       defaults to FALSE.
188
189   OpenCallback
190       This parameter sets the callback function which is invoked when the
191       peer receives an OPEN message. It takes a subroutine reference. See
192       "CALLBACK FUNCTIONS" later in this manual for further details of the
193       conventions of callback invocation.
194
195   KeepaliveCallback
196       This parameter sets the callback function which is invoked when the
197       peer receives a KEEPALIVE message. It takes a subroutine reference.
198       See "CALLBACK FUNCTIONS" later in this manual for further details of
199       the conventions of callback invocation.
200
201   UpdateCallback
202       This parameter sets the callback function which is invoked when the
203       peer receives an UPDATE message. It takes a subroutine reference. See
204       "CALLBACK FUNCTIONS" later in this manual for further details of the
205       conventions of callback invocation.
206
207   RefreshCallback
208       This parameter sets the callback function which is invoked when the
209       peer receives a REFRESH message. It takes a subroutine reference. See
210       "CALLBACK FUNCTIONS" later in this manual for further details of the
211       conventions of callback invocation.
212
213   NotificationCallback
214       This parameter sets the callback function which is invoked when the
215       peer receives a NOTIFICATION message. It takes a subroutine reference.
216       See "CALLBACK FUNCTIONS" later in this manual for further details of
217       the conventions of callback invocation.
218
219   ErrorCallback
220       This parameter sets the callback function which is invoked when the
221       peer encounters an error and must send a NOTIFICATION message to its
222       peer. It takes a subroutine reference. See "CALLBACK FUNCTIONS" later
223       in this manual for further details of the conventions of callback
224       invocation.
225
226       renew - fetch the existing Net::BGP::Peer object from the "object
227       string".
228
229       This "reconstructor" returns a previeus constructed object from the
230       perl genereted string-context scalar of the object, eg.
231       Net::BGP::Peer=HASH(0x820952c).
232

ACCESSOR METHODS

234       start() - start the BGP peering session with the peer
235
236           $peer->start();
237
238       This method initiates the BGP peering session with the peer by
239       internally emitting the BGP Start event, which causes the peer to
240       initiate a transport-layer connection to its peer (unless the Passive
241       parameter was set to a true value in the constructor) and listen for a
242       connection from the peer (unless the Listen parameter is set to a false
243       value).
244
245       stop() - cease the BGP peering session with the peer
246
247           $peer->stop();
248
249       This method immediately ceases the peering session with the peer by
250       sending it a NOTIFICATION message with Error Code Cease, closing the
251       transport-layer connection, and entering the Idle state.
252
253       update() - send a BGP UPDATE message to the peer
254
255           $peer->update($update);
256
257       This method sends the peer an UPDATE message. It takes a reference to a
258       Net::BGP::Update object. See the Net::BGP::Update manual page for
259       details on setting UPDATE attributes.
260
261       refresh() - send a BGP REFRESH message to the peer
262
263           $peer->refresh($refresh);
264
265       This method sends the peer a REFRESH message. It takes a reference to a
266       Net::BGP::Refesh object. If no argument is provided, a default
267       Net::BGP::Refresh object is constructed. See the Net::BGP::Refresh
268       manual page for details on setting REFRESH attributes.
269
270       transport()
271
272       Returns the active transport object to the peer - See
273       Net::BGP::Transport.
274
275       transports()
276
277       Return a list of transport objects. The list will contain one or two
278       elements.  The first will always be the primary transport object. If
279       there are two sessions (e.g. collision detection hasn't removed one of
280       them), the sibling will be returned as the second element of the list.
281
282       this_id()
283
284       this_as()
285
286       peer_id()
287
288       peer_as()
289
290       this_can_refresh()
291
292       support_capabilities()
293
294       support_mbgp()
295
296       is_listener()
297
298       is_passive()
299
300       version()
301
302       These are accessor methods for the corresponding constructor named
303       parameters.  They retrieve the values set when the object was created,
304       but the values cannot be changed after object construction. Hence, they
305       take no arguments.
306
307       is_established()
308
309       This accessor method returns true if the peer has a established
310       transport connection - e.g. the peering is up.
311
312       peer_can_refresh()
313
314       This accessor method returns a true value if connected to a peer that
315       supports refresh messages - otherwise a false value.
316
317       asstring()
318
319       This accessor method returns a print friendly string with the local and
320       remote IP and AS numbers.
321
322       set_open_callback()
323
324       set_established_callback()
325
326       set_keepalive_callback()
327
328       set_update_callback()
329
330       set_refresh_callback()
331
332       set_reset_callback()
333
334       set_notification_callback()
335
336       set_error_callback()
337
338       These methods set the callback functions which are invoked whenever the
339       peer receives the corresponding BGP message type from its peer, or, in
340       the case of set_established_callback, transitions to the relevant
341       state. They can be set in the constructor as well as with these
342       methods. These methods each take one argument, which is the subroutine
343       reference to be invoked.  A callback function can be removed by calling
344       the corresponding one of these methods and passing it the perl undef
345       value. For callback definition and invocation conventions see "CALLBACK
346       FUNCTIONS" later in this manual.
347
348       add_timer() - add a program defined timer callback function
349
350           $peer->add_timer(\&my_minute_timer, 60);
351
352       This method sets a program defined timer which invokes the specified
353       callback function when the timer expires. It takes two arguments: the
354       first is a code reference to the subroutine to be invoked when the
355       timer expires, and the second is the timer interval, in seconds. The
356       program may set as many timers as needed, and multiple timer callbacks
357       may share the same interval. Program timers add an asynchronous means
358       for user code to gain control of the program control flow - without
359       them user code would only be invoked whenever BGP events exposed by the
360       module occur. They may be used to perform any necessary action - for
361       example, sending UPDATEs, starting or stopping the peering session,
362       house-keeping, etc.
363
364       remove_timer() - remove a program defined timer callback function
365
366           $peer->remove_timer(\&my_minute_timer);
367
368       This method removes a program defined timer callback which has been
369       previously set with the add_timer() method. It takes a single argument:
370       a reference to the subroutine previously added.
371

CALLBACK FUNCTIONS

373       Whenever a Net::BGP::Peer object receives one of the BGP protocol
374       messages - OPEN, KEEPALIVE, UPDATE, REFRESH, or NOTIFICATION - from its
375       peer, or whenever it encounters an error condition and must send a
376       NOTIFICATION message to its peer, the peer object will invoke a program
377       defined callback function corresponding to the event type, if one has
378       been provided, to inform the application about the event. These
379       callback functions are installed as described in the preceding section
380       of the manual. Whenever any callback function is invoked, it is passed
381       one or more arguments, depending on the BGP message type associated
382       with the callback. The first argument passed to all of the callbacks is
383       a reference to the Net::BGP::Peer object which the application may use
384       to identify which peer has signalled the event and to take appropriate
385       action. For OPEN and KEEPALIVE callbacks, this is the only argument
386       passed. It is very unlikely that applications will be interested in
387       OPEN and KEEPALIVE events, since the Net::BGP module handles all
388       details of OPEN and KEEPALIVE message processing in order to establish
389       and maintain BGP sessions. Callback handling for these messages is
390       mainly included for the sake of completeness. For UPDATE and
391       NOTIFICATION messages, however, most applications will install callback
392       handlers.  Whenever an UPDATE, REFRESH, NOTIFICATION, or error handler
393       is called, the object will pass a second argument. In the first two
394       cases, this is a Net::BGP::Update or Net::BGP::Refresh object
395       respectivly encapsulating the information contained in the UPDATE or
396       REFRESH message, while in the latter two cases it is a
397       Net::BGP::Notification object encapsulating the information in the
398       NOTIFICATION message sent or received.
399
400       The RESET and ESTABLISHED callbacks are special, since they are used
401       whenever an established BGP session is reset, even though no message
402       has been recieved or sent.  The REFRESH callback is also special, since
403       it is also called without a REFRESH object whenever a BGP session is
404       established. The two callbacks can be used to clear and retransmit a
405       RIB from/to the peer in question.
406
407       Whenever a callback function is to be invoked, the action occuring
408       internally is the invocation of one of the following methods,
409       corresponding to the event which has occured:
410
411       open_callback()
412
413       established_callback()
414
415       keepalive_callback()
416
417       update_callback()
418
419       refresh_callback()
420
421       reset_callback()
422
423       notification_callback()
424
425       error_callback()
426
427       Internally, each of these methods just checks to see whether a program
428       defined callback function has been set and calls it if so, passing it
429       arguments as described above. As an alternative to providing subroutine
430       references to the constructor or through the set_open_callback(),
431       set_established_callback(), set_keepalive_callback(),
432       set_update_callback(), set_refresh_callback(), set_reset_callback(),
433       set_notification_callback(), and set_error_callback() methods, an
434       application may effect a similar result by sub-classing the
435       Net::BGP::Peer module and overridding the defintions of the above
436       methods to perform whatever actions would have been executed by
437       ordinary callback functions.  The overridden methods are passed the
438       same arguments as the callback functions.  This method might offer an
439       advantage in organizing code according to different derived classes
440       which apply specifc routing policies.
441

ERROR HANDLING

443       There are two possibilities for error handling callbacks to be invoked.
444       The first case occurs when the peer receives a NOTIFICATION messages
445       from its peer. The second case occurs when the peer detects an error
446       condition while processing an incoming BGP message or when some other
447       protocol covenant is violated - for example if a KEEPALIVE or UPDATE
448       message is not received before the peer's Keepalive timer expires. In
449       this case, the peer responds by sending a NOTIFICATION message to its
450       peer. In the former case the notification_callback() method is invoked
451       as described above to handle the error, while in the latter the
452       error_callback() method is invoked to inform the application that it
453       has encountered an error. Both methods are passed a
454       Net::BGP::Notification object encapsulating the details of the error.
455       In both cases, the transport-layer connection and BGP session are
456       closed and the peer transitions to the Idle state.  The error handler
457       callbacks can examine the cause of the error and take appropriate
458       action. This could be to attempt to re-establish the session (perhaps
459       after sleeping for some amount of time), or to unregister the peer
460       object from the Net::BGP::Process object and permanently end the
461       session (for the duration of the application's running time), or to log
462       the event to a file on the host system, or some combination of these or
463       none.
464

SEE ALSO

466       Net::BGP, Net::BGP::Process, Net::BGP::Update, Net::BGP::Transport,
467       Net::BGP::Refresh, Net::BGP::Notification
468

AUTHOR

470       Stephen J. Scheck <code@neurosphere.com>
471
472
473
474perl v5.28.1                      2015-01-27                 Net::BGP::Peer(3)
Impressum