bgpd-users Mailing List for bgpd.pl
Status: Alpha
Brought to you by:
stevenh
Menu
▾
▴
bgpd-users — Discussions about using bgpd.pl to monitor BGP information
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
(6) |
Sep
|
Oct
(6) |
Nov
|
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
(3) |
Oct
(1) |
Nov
|
Dec
(2) |
| 2003 |
Jan
(2) |
Feb
(4) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
|
From: Steven <st...@xs...> - 2004-09-22 15:01:10
|
Hi Andrew,
Thanks for the patch! 0.07 was actually released. a bit more then a year
ago. I'll see if I can dig up the sources and my SF password somewhere
and make a new release. As you may have guessed, I haven't been spending
a lot of time on developing bgpd.pl lately :-).
- Steven
Andrew - Supernews wrote:
>>>>>>"Steven" == Steven Hessing <st...@xs...> writes:
>>>>>>
>>>>>>
>
> Steven> 0.07 won't be released until I've chased another bug report I
> Steven> received last week (keep them coming, it's nice to know that
> Steven> people are using the software!)
>
>Hm, a year and a half later... :-)
>
>Here is another bug in PathAttribute in 0.06 that causes the session
>to be aborted typically with Notification 3/1 any time an unknown
>attribute is seen; $bytes_read wasn't being updated in this case, so
>the unknown attribute's data was being parsed as more attributes.
>(Someone's leaking a NEW_AS_PATH into the backbone at the moment,
>apparently due to a misconfiguration rather than any legitimate use of
>a 32-bit ASN.)
>
>--- PathAttribute.pm.orig Mon Sep 13 01:44:21 2004
>+++ PathAttribute.pm Mon Sep 13 01:44:57 2004
>@@ -629,6 +629,7 @@
> # unknown optional non-transitive attributes
> # can be discarded
> }
>+ $bytes_read += $attribute_length;
> } else {
> # If this is a well-known attribute then we have
> # to raise an error and send a NOTIFICATION.
>
>
>
>
|
|
From: Andrew - S. <an...@su...> - 2004-09-13 01:00:16
|
>>>>> "Steven" == Steven Hessing <st...@xs...> writes:
Steven> 0.07 won't be released until I've chased another bug report I
Steven> received last week (keep them coming, it's nice to know that
Steven> people are using the software!)
Hm, a year and a half later... :-)
Here is another bug in PathAttribute in 0.06 that causes the session
to be aborted typically with Notification 3/1 any time an unknown
attribute is seen; $bytes_read wasn't being updated in this case, so
the unknown attribute's data was being parsed as more attributes.
(Someone's leaking a NEW_AS_PATH into the backbone at the moment,
apparently due to a misconfiguration rather than any legitimate use of
a 32-bit ASN.)
--- PathAttribute.pm.orig Mon Sep 13 01:44:21 2004
+++ PathAttribute.pm Mon Sep 13 01:44:57 2004
@@ -629,6 +629,7 @@
# unknown optional non-transitive attributes
# can be discarded
}
+ $bytes_read += $attribute_length;
} else {
# If this is a well-known attribute then we have
# to raise an error and send a NOTIFICATION.
--
Andrew, Supernews
http://www.supernews.com
|
|
From: Benno L. <ben...@id...> - 2004-05-03 07:15:45
|
Dear Open Source developer I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate. You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it. With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development. With many thanks for your participation, Benno Luthiger PS: The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/. We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_de.html for registration to this mailing list. _______________________________________________________________________ Benno Luthiger Swiss Federal Institute of Technology Zurich 8092 Zurich Mail: benno.luthiger(at)id.ethz.ch _______________________________________________________________________ |
|
From: Petr K. <pk...@nu...> - 2003-11-21 07:46:21
|
-----Urspr=FCngliche Nachricht-----=20 Von: "Steven Hessing" <st...@xs...> An: <vin...@ta...>; <pk...@nu...> Gesendet: Donnerstag, 31. Juli 2003 08:53 Betreff: Your subscription to the bgpd.pl mailing list. > Hi, > > Welcome to the bgpd.pl mailing-list. There is very little traffic on the > list because little development is being done. The existing release > basically provides the described functionality without too much (any?) bugs. > > If you have some questions, bug reports or code that implements new > functionality, feel free to ask them to the list or to me directly. > > Cheers, > > - Steven > is it soon possible to read via pipermail too? http://sourceforge.net/mailarchive/forum.php?forum=3Dbgpd-users is not so bad, but i like pipermail ;-) greets Petr |
|
From: Edwin D. V. <ed...@as...> - 2003-05-14 10:26:47
|
Anyone in this list who has a hands-on experience in utilizing the = University of Oregon's Route Views using the bgpd to query and produce = AS maps? =20 best regards, edwin =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D If others think ten minutes ahead; Filipinos must think 10 years ahead; -- Edwin D. Vinas Science Research Specialist I Advanced Science and Technology Institute UP Technopark Complex, CP Garcia Ave, Diliman, Quezon City Philippines ed...@as... http://www.geocities.com/edwin_vinas =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This communication is intended only for the person or entity to which it = is addressed and may contain confidential and/or privileged material. If = you are not the intended recipient, please note that any review, = retransmission, dissemination, copying or other use of, or taking of any action in = reliance upon, this information by you or by persons or entities other than the intended recipient is prohibited. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
|
From: Steven H. <st...@xs...> - 2003-02-25 21:13:27
|
Hi Terra,
Thanks for the bug report! We'll need to remove the initial unpack in the
assigment to $originator_id. The same bug re-occurs at the AGGREGATOR and
ADVERTISER path attributes. Values should be stored in network byte order
and converted to strings for logging purposes.
I think I've fixed this in 0.07, for now the patch is included below.
Unfortunately I can't test it right now but you're free to let me know
whether the patch works for you :-)
0.07 won't be released until I've chased another bug report I received last
week (keep them coming, it's nice to know that people are using the software!)
- Steven
Here's the patch that will be in 0.07:
diff -u -r bgpd.pl-0.06/BGP/PathAttribute.pm bgpd.pl-0.07/BGP/PathAttribute.pm
--- bgpd.pl-0.06/BGP/PathAttribute.pm 2002-10-01 07:03:13.000000000 +0200
+++ bgpd.pl-0.07/BGP/PathAttribute.pm 2003-02-25 06:51:50.000000000 +0100
@@ -419,7 +419,7 @@
my $next_hop = substr($buff, $bytes_read,
$attribute_length);
# TODO: check $next_hop on both syntactic as symantic
# correctness and add the different error responses.
- my $nh_ip = inet_ntoa (substr($buff, $bytes_read, 4));
+ my $nh_ip = inet_ntoa ($next_hop);
# This is a well-known mandatory attribute
if (defined $attribute_flag{optional}
|| !defined
$attribute_flag{transitive}) {
@@ -502,8 +502,7 @@
}
my $aggr_as = unpack('n',
substr($buff,$bytes_read, 2));
- my $aggr_host = unpack('N',
- substr($buff,$bytes_read + 2, 4));
+ my $aggr_host = substr($buff,$bytes_read + 2, 4);
# This is a well-known discretionary attribute
according to RFC1771
# Cisco sends it as an optional attribute so
that's how we accept it
if (!defined $attribute_flag{optional} ||
@@ -516,8 +515,7 @@
BGP_ERRSC_Attribute_Length_Error,
$attribute);
}
$pa->set_aggregator ($aggr_as, $aggr_host);
- my $aggr_host_ip = inet_ntoa
- (substr($buff, $bytes_read + 2, 4));
+ my $aggr_host_ip = inet_ntoa ($aggr_host);
$bytes_read += 6;
$neighbor->log (2, 256,
"AGGREGATOR AS: $aggr_as, host:
$aggr_host_ip");
@@ -543,6 +541,7 @@
$neighbor->log (2, 256, "Communities:",
@communities);
}
+ # RFC2796: ORIGINATOR_ID, type code 9
if ($attribute_type_code ==
BGP_UPDATE_Path_Attribute_ORIGINATOR_ID) {
$attribute .= substr($buff, $bytes_read,
$attribute_length);
@@ -557,7 +556,7 @@
return (BGP_ERRC_UPDATE_Message_Error,
BGP_ERRSC_Attribute_Length_Error,
$attribute);
}
- my $originator_id = unpack ('N', substr ($buff,
$bytes_read, 4));
+ my $originator_id = substr($buff, $bytes_read, 4);
$pa->set_originatorid ($originator_id);
$bytes_read += $attribute_length;
@@ -577,12 +576,12 @@
return (BGP_ERRC_UPDATE_Message_Error,
BGP_ERRSC_Attribute_Length_Error,
$attribute);
}
- my @cluster_list = unpack ('N*', substr($buff,
$bytes_read,
+ my @cluster_list = unpack ('L*', substr($buff,
$bytes_read,
$attribute_length));
$bytes_read += $attribute_length;
$pa->set_clusterlist (\@cluster_list);
$neighbor->log (2, 256, "Cluster list:",
- @cluster_list);
+ unpack('N*', substr($buff, $bytes_read,
$attribute_length)));
}
if ($attribute_type_code ==
BGP_UPDATE_Path_Attribute_ADVERTISER) {
$attribute .= substr($buff, $bytes_read,
$attribute_length);
@@ -597,9 +596,9 @@
return (BGP_ERRC_UPDATE_Message_Error,
BGP_ERRSC_Attribute_Length_Error,
$attribute);
}
- my $advertiser = unpack ('N', substr ($buff,
$bytes_read, 4));
+ my $advertiser = substr ($buff, $bytes_read, 4);
- $pa->set_advertiserr ($advertiser);
+ $pa->set_advertiser ($advertiser);
$bytes_read += $attribute_length;
$neighbor->log (2, 256, "Advertiser:",
inet_ntoa($advertiser));
diff -u -r bgpd.pl-0.06/CHANGES bgpd.pl-0.07/CHANGES
--- bgpd.pl-0.06/CHANGES 2002-10-01 07:04:04.000000000 +0200
+++ bgpd.pl-0.07/CHANGES 2003-02-25 06:40:20.000000000 +0100
@@ -1,3 +1,6 @@
+- Removed unpack ORIGNATOR_ID path attribute, the value should be stored
+ in network byte order (Report by Terra (mli...@Fu...)
+
RELEASE bgpd.pl-0.06 released on October 1st 2002
- Fixes provided by Andrew of Supernews <an...@su...> for the
route selection algorithm used to select for a route announced by two or
At 12:39 PM 2/18/2003 -0500, Terra wrote:
>Greetings,
>
>The players:
>1) zebra-0.93b
>2) bgpd-0.6
>
>Upon receiving an attribute_type_code of
>'BGP_UPDATE_Path_Attribute_ORIGINATOR_ID', an error is quickly hit on line: 564
>
>Error:
>Bad arg length for Socket::inet_ntoa, length is 10, should be 4 at
>BGP/PathAttribute.pm line 564
>
> From a quick patch:
>printf("OrigID: %d, %d\n", $originator_id, length($originator_id));
>
>returns:
>OrigID: 1117200388, 10
>
>I went ahead and decided to reverse the prior unpack, instead of stuffing
>away the substr, then unpack step after...
>Patch to repair:
>--- bgpd.pl-0.06/BGP/PathAttribute.pm-virgin Tue Oct 1 01:03:13 2002
>+++ bgpd.pl-0.06/BGP/PathAttribute.pm Tue Feb 18 12:27:56 2003
>@@ -562,7 +562,7 @@
> $pa->set_originatorid ($originator_id);
> $bytes_read += $attribute_length;
> $neighbor->log (2, 256, "Originator ID:",
>- inet_ntoa($originator_id));
>+ inet_ntoa(pack('N',$originator_id)));
> }
> if ($attribute_type_code ==
> BGP_UPDATE_Path_Attribute_CLUSTER_LIST) {
> $attribute .= substr($buff, $bytes_read,
> $attribute_length);
>
>
>Thanks Steven for maintaining a wonderful base of perl, that can slice and
>dice raw BGP packets, for which has helped me to understand the BGP4
>protocol in much more depth and detail... It is also proven itself to be
>a terrific debugging aid, especially when your eBGP peers refuse to
>provide looking glass services to their clients...
>
>--
>Terra
>sysAdmin
>FutureQuest
>
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by:ThinkGeek
>Welcome to geek heaven.
>http://thinkgeek.com/sf
>_______________________________________________
>Bgpd-users mailing list
>Bgp...@li...
>https://lists.sourceforge.net/lists/listinfo/bgpd-users
|
|
From: Steven H. <st...@xs...> - 2003-02-19 11:15:23
|
Hi Rosen, Can you tell me a bit more about your setup? What version of bgpd.pl are you using? How have you configured bgpd.pl? Who are the peers, what kind of devices are the peers and what software versions are they running? How did you configure thos peers? Cheers, - Steven At 10:46 AM 2/19/2003, Rosen Mitev - Multicom Ltd. wrote: >I can't establish 2 ot more paralel BGP4 sessions ... > >-- >---------------------------------------- >Rosen Mitev - Network Administrator >---------------------------------------- >Multicom Ltd. >Sofia 1000, Bulgaria >57 Tzar Simeon Str. >tel. +359-2-9835969 >fax: +359-2-9835297 >http://www.multicom.bg >e-mail: ro...@mu... > > > > >------------------------------------------------------- >This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. >The most comprehensive and flexible code editor you can use. >Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. >www.slickedit.com/sourceforge >_______________________________________________ >Bgpd-users mailing list >Bgp...@li... >https://lists.sourceforge.net/lists/listinfo/bgpd-users > |
|
From: Rosen M. - M. Ltd. <ro...@mu...> - 2003-02-19 08:46:35
|
I can't establish 2 ot more paralel BGP4 sessions ... -- ---------------------------------------- Rosen Mitev - Network Administrator ---------------------------------------- Multicom Ltd. Sofia 1000, Bulgaria 57 Tzar Simeon Str. tel. +359-2-9835969 fax: +359-2-9835297 http://www.multicom.bg e-mail: ro...@mu... |
|
From: Terra <mli...@Fu...> - 2003-02-18 17:41:18
|
Greetings,
The players:
1) zebra-0.93b
2) bgpd-0.6
Upon receiving an attribute_type_code of 'BGP_UPDATE_Path_Attribute_ORIGINATOR_ID', an error is quickly hit on line: 564
Error:
Bad arg length for Socket::inet_ntoa, length is 10, should be 4 at BGP/PathAttribute.pm line 564
From a quick patch:
printf("OrigID: %d, %d\n", $originator_id, length($originator_id));
returns:
OrigID: 1117200388, 10
I went ahead and decided to reverse the prior unpack, instead of stuffing away the substr, then unpack step after...
Patch to repair:
--- bgpd.pl-0.06/BGP/PathAttribute.pm-virgin Tue Oct 1 01:03:13 2002
+++ bgpd.pl-0.06/BGP/PathAttribute.pm Tue Feb 18 12:27:56 2003
@@ -562,7 +562,7 @@
$pa->set_originatorid ($originator_id);
$bytes_read += $attribute_length;
$neighbor->log (2, 256, "Originator ID:",
- inet_ntoa($originator_id));
+ inet_ntoa(pack('N',$originator_id)));
}
if ($attribute_type_code == BGP_UPDATE_Path_Attribute_CLUSTER_LIST) {
$attribute .= substr($buff, $bytes_read, $attribute_length);
Thanks Steven for maintaining a wonderful base of perl, that can slice and dice raw BGP packets, for which has helped me to understand the BGP4 protocol in much more depth and detail... It is also proven itself to be a terrific debugging aid, especially when your eBGP peers refuse to provide looking glass services to their clients...
--
Terra
sysAdmin
FutureQuest
|
|
From: Steven H. <st...@xs...> - 2003-01-20 11:34:27
|
Hi Anand, bgpd.pl doesn't send UPDATE messages nor does it support the BGP FSM. So as a stand-alone simulator I would imagine it is of limited use. - Steven At 11:47 PM 1/17/2003, Anand Bapat wrote: >Hi, > Can I use bgpd as a BGP simulator on a stand alone Linux machine? >Sorry if this has already been mentioned in the documentation.. > >regards > >Anand > > >_____________________________________________________________ >Want a new web-based email account ? ---> http://www.firstlinux.net > >_____________________________________________________________ >Select your own custom email address for FREE! Get yo...@yo... w/No >Ads, 6MB, POP & more! http://www.everyone.net/selectmail?campaign=tag > > >------------------------------------------------------- >This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will >allow you to extend the highest allowed 128 bit encryption to all your >clients even if they use browsers that are limited to 40 bit encryption. >Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en >_______________________________________________ >Bgpd-users mailing list >Bgp...@li... >https://lists.sourceforge.net/lists/listinfo/bgpd-users |
|
From: Anand B. <ba...@fi...> - 2003-01-17 22:47:42
|
Hi, Can I use bgpd as a BGP simulator on a stand alone Linux machine? Sorry if this has already been mentioned in the documentation.. regards Anand _____________________________________________________________ Want a new web-based email account ? ---> http://www.firstlinux.net _____________________________________________________________ Select your own custom email address for FREE! Get yo...@yo... w/No Ads, 6MB, POP & more! http://www.everyone.net/selectmail?campaign=tag |
|
From: Steven H. <st...@xs...> - 2002-12-05 18:18:12
|
Bgpd.pl should be installed on a unix host. Through configuration of the bgpd.conf file you can set up a iBGP or eBGP connection to your router. Yours, - Steven Hessing At 06:03 PM 12/5/2002 +0900, ta...@sf... wrote: >I have a question about how to use bgpd.pl. > >Should we use bgpd.pl in real BGP router? >Or,should we use in the host and establish connection >between the BGP router and the host where "bgpd.pl" run ? > >The documentation is unclear in this viewpoint. > >Please teach me. > >best regards. > > >------------------------------------------------------- >This sf.net email is sponsored by:ThinkGeek >Welcome to geek heaven. >http://thinkgeek.com/sf >_______________________________________________ >Bgpd-users mailing list >Bgp...@li... >https://lists.sourceforge.net/lists/listinfo/bgpd-users |
|
From: <ta...@sf...> - 2002-12-05 09:29:36
|
I have a question about how to use bgpd.pl. Should we use bgpd.pl in real BGP router? Or,should we use in the host and establish connection between the BGP router and the host where "bgpd.pl" run ? The documentation is unclear in this viewpoint. Please teach me. best regards. |
|
From: Steven H. <st...@xs...> - 2002-10-01 18:22:43
|
Based on the patches as provided by Andrew <an...@su...> I've put a new release of bgpd.pl (0.06) on sourceforge: https://sourceforge.net/project/showfiles.php?group_id=29181&release_id=113869 - Steven |
|
From: Andrew - S. <an...@su...> - 2002-09-27 19:01:12
|
>>>>> "Steven" == Steven Hessing <st...@xs...> writes: Steven> Hey Andrew, Steven> This is excellent! As you may have guessed I haven't been Steven> able to obtain multiple peers that send me updates. Can you Steven> tell me anything about CPU and memory usage with the two Steven> feeds coming in? in my case it's not significantly different, but that's because in my situation I'm effectively getting half (or so) of the routes from each (internal) peer rather than getting multiple full views. -- Andrew, Supernews http://www.supernews.com |
|
From: Steven H. <st...@xs...> - 2002-09-27 18:46:53
|
Hey Andrew, This is excellent! As you may have guessed I haven't been able to obtain multiple peers that send me updates. Can you tell me anything about CPU and memory usage with the two feeds coming in? I'll patch in the code and make a new release on sourceforge this Sunday. - Steven At 07:03 PM 9/27/2002 +0100, Andrew - Supernews wrote: >the following patch fixes some simple errors in LocalRib.pm, which >otherwise kill the daemon any time that route selection is performed >(only happens with multiple peers). > >With these, I'm now running iBGP to both my cores (Ciscos) without any >problems that I've found so far. > >-- >Andrew, Supernews >http://www.supernews.com > > > >*** BGP/LocalRib.pm 18 Jun 2002 13:46:55 -0000 1.2 >--- BGP/LocalRib.pm 25 Jul 2002 17:35:50 -0000 1.4 >*************** >*** 148,154 **** > } > > sub is_better_route { >! my ($prefix, $len, $adjRIBin, $bgprouter, $curpeer, $trypeer); > > my $attr1 = $adjRIBin->get_pathattribute ($prefix, $len, $curpeer); > my $attr2 = $adjRIBin->get_pathattribute ($prefix, $len, $trypeer); >--- 148,154 ---- > } > > sub is_better_route { >! my ($prefix, $len, $adjRIBin, $bgprouter, $curpeer, $trypeer) = @_; > > my $attr1 = $adjRIBin->get_pathattribute ($prefix, $len, $curpeer); > my $attr2 = $adjRIBin->get_pathattribute ($prefix, $len, $trypeer); >*************** >*** 200,206 **** > $med2 = $temp; > } > $bgprouter->log (256, 256, "MED $med1 vs MED $med2"); >! return 1 if ($$med1 > $med2); > > # Rule 8: Prefer closest IGP neighbor. > # We don't do IGP >--- 200,206 ---- > $med2 = $temp; > } > $bgprouter->log (256, 256, "MED $med1 vs MED $med2"); >! return 1 if ($med1 > $med2); > > # Rule 8: Prefer closest IGP neighbor. > # We don't do IGP > > > >------------------------------------------------------- >This sf.net email is sponsored by:ThinkGeek >Welcome to geek heaven. >http://thinkgeek.com/sf >_______________________________________________ >Bgpd-users mailing list >Bgp...@li... >https://lists.sourceforge.net/lists/listinfo/bgpd-users |
|
From: Andrew - S. <an...@su...> - 2002-09-27 18:03:26
|
the following patch fixes some simple errors in LocalRib.pm, which otherwise kill the daemon any time that route selection is performed (only happens with multiple peers). With these, I'm now running iBGP to both my cores (Ciscos) without any problems that I've found so far. -- Andrew, Supernews http://www.supernews.com *** BGP/LocalRib.pm 18 Jun 2002 13:46:55 -0000 1.2 --- BGP/LocalRib.pm 25 Jul 2002 17:35:50 -0000 1.4 *************** *** 148,154 **** } sub is_better_route { ! my ($prefix, $len, $adjRIBin, $bgprouter, $curpeer, $trypeer); my $attr1 = $adjRIBin->get_pathattribute ($prefix, $len, $curpeer); my $attr2 = $adjRIBin->get_pathattribute ($prefix, $len, $trypeer); --- 148,154 ---- } sub is_better_route { ! my ($prefix, $len, $adjRIBin, $bgprouter, $curpeer, $trypeer) = @_; my $attr1 = $adjRIBin->get_pathattribute ($prefix, $len, $curpeer); my $attr2 = $adjRIBin->get_pathattribute ($prefix, $len, $trypeer); *************** *** 200,206 **** $med2 = $temp; } $bgprouter->log (256, 256, "MED $med1 vs MED $med2"); ! return 1 if ($$med1 > $med2); # Rule 8: Prefer closest IGP neighbor. # We don't do IGP --- 200,206 ---- $med2 = $temp; } $bgprouter->log (256, 256, "MED $med1 vs MED $med2"); ! return 1 if ($med1 > $med2); # Rule 8: Prefer closest IGP neighbor. # We don't do IGP |
|
From: Steven H. <st...@xs...> - 2002-06-20 19:44:12
|
Hi all, I received a patch yesterday from Andrew <an...@su...>. I've integrated this patch into the 0.04 code and released bgpd.pl-0.05. It's available at http://sourceforge.net/projects/bgpd/ Here's the excerpt from the changelog: RELEASE bgpd.pl-0.05 released on June 20th 2002 - Fixes provided Andrew of Supernews <an...@su...> His coments included below: -------------------- - (critical) the logic of BGP::Neighbor::receive was completely wrong, leading to failure of the session (and many perl warnings) any time that the data returned from sysread() was shorter than expected, which is something that TCP-based applications must _always_ expect and handle. - (annoying) router-id in the config file didn't work at all - (serious) updates where the AS-PATH was present but empty (which is normal for local routes from iBGP peers) were treated as though the AS-PATH were missing (killing the session) - (trivial) changed the dump output format to eliminate whitespace in the prefix output for prefixes smaller than /10 - (performance) most of the time taken to take in a full routing table was being eaten by BGP::Neighbor::log due to doing significant processing before checking the log level. The change I did results in about a 2x speedup with most logging turned off I also changed the logfile open to use append mode, not really a bug but probably more useful in most cases. Stuff I didn't fix: your daemonize function uses a method that would have been archaic 10 years ago, and closing stdin/out/err without reopening them again is a dangerous practice. Check out POSIX::setsid. (I'm not currently using daemon mode for various reasons) ------------------- |
|
From: Steven <st...@xs...> - 2001-12-09 11:23:44
|
I'm happy to announce that bgpd.pl is being maintained once again after nearly 6 months of inactivity. This release is a bug-fix only release. The new release is available as always from: http://sourceforge.net/projects/bgpd/ Excerpt from CHANGELOG: - fixed bug in AdjRibIn.pm where `!=' was used to compare packed IP addresses, bug report by Thomas Tam (tho...@be...) - fixed bug Neighbor.pm where UPDATES with unfeasable routes would not have their new routes processed - fixed bug Neighbor.pm where the closure of a BGP session would not undefine the filehandle, causing errors in socket processing - fixed & redesigned logging Logging settings are now configured in the bgpd.conf file instead of on the command-line, see bgpd.conf.sample. Someone has reported that a BGP session between bgpd.pl and zebra crashed the zebra process. However, this has not been confirmed or reproduced. It is advisable ofcourse to not connect bgpd.pl to a router in your production network. - Steven Hessing |
|
From: Rosen M. <ro...@mu...> - 2001-10-22 10:31:07
|
sorry ... this is just a test |
|
From: Stephane B. <bor...@ga...> - 2001-10-22 08:51:54
|
On Sun, Oct 21, 2001 at 05:20:17PM -0700, Kunihiro Ishiguro <kun...@ze...> wrote a message of 10 lines which said: > Would you mind to give me more detailed information about this. > I'll try between bgpd.pl and Zebra-0.92 bgpd (and CVS version bgpd). Zebra 0.91a+cvs.20010422 (Debian package in Debian's "testing", although "testing" now has 0.92a). Full feed (104 kroutes). Running on Debian "testing", kernel Linux 2.4.9. bgpd-perl 0.03 Three hours after bgpd-perl was launched (during this time, the state of the connection switched permanently between Active and Established): Zebra's bgpd died: 2001/10/21 01:13:01 BGP: 80.67.162.6 send UPDATE 208.161.108.0/24 nexthop 213.248.70.37, origin i, mp_nexthop ::, localpref 100, path 1299 1833 701 14460 2001/10/21 01:13:01 BGP: 80.67.162.6 send UPDATE 208.161.109.0/24 nexthop 213.248.70.37, origin i, mp_nexthop ::, localpref 100, path 1299 1833 701 14460 2001/10/21 01:13 [The log stops abruptly here.] The Zebra configuration for that peer is: router bgp 20766 network 80.67.160.0/21 network 80.67.176.0/20 neighbor 80.67.162.6 remote-as 20766 neighbor 80.67.162.6 update-source eth0 neighbor 80.67.162.6 prefix-list spy-in in ip prefix-list spy-in deny any I cannot easily reproduce it: it was my main router :-( I'll try to install a route server somewhere so I can crash it under gdb :-) |
|
From: Kunihiro I. <kun...@ze...> - 2001-10-22 00:20:18
|
>Now, a serious warning: using it in front of a Zebra 0.91 crashes
>Zebra's bgpd in a few hours. Zebra is probably not robust enough. But
>the Zebra box was peering with other Zebras, 20 different Ciscos and a
>few Junipers for several months without problems so I assume bgpd-perl
>does something really nasty :-{
Would you mind to give me more detailed information about this.
I'll try between bgpd.pl and Zebra-0.92 bgpd (and CVS version bgpd).
--
Kunihiro Ishiguro
|
|
From: Steven H. <st...@xs...> - 2001-10-21 20:32:05
|
Stephane, Thanks for the warning. Unfortunately I have lost access to my development environment a while ago so I can't test (or fix) the problem that you have encountered. (this is also the reason why no newer versions of bgpd.pl have appeared) Just a quick note to the Zebra developers wanting to fix this problem: bgpd.pl never sends any Update messages. It only sends Open, Keepalive and Notification messages. - Steven At 21:46 21-10-01 +0200, Stephane Bortzmeyer wrote: >An interesting implementation of BGP (in Perl, yes), which is not >suitable for a router but may be used to monitor routes, gather >statistics, etc. > >http://bgpd.sourceforge.net/ > >Now, a serious warning: using it in front of a Zebra 0.91 crashes >Zebra's bgpd in a few hours. Zebra is probably not robust enough. But >the Zebra box was peering with other Zebras, 20 different Ciscos and a >few Junipers for several months without problems so I assume bgpd-perl >does something really nasty :-{ > >So, if you want to participate in bgpd-perl's development, do not peer >with your real routers. > > > >_______________________________________________ >Bgpd-users mailing list >Bgp...@li... >https://lists.sourceforge.net/lists/listinfo/bgpd-users |
|
From: Steven H. <st...@xs...> - 2001-10-21 20:27:06
|
Stephane, Thanks for the warning. Unfortunately I have lost access to my development environment a while ago so I can't test (or fix) the problem that you have encountered. (this is also the reason that no newer versions of bgpd.pl have appeared) Just a quick note to the Zebra developers wanting to fix this problem: bgpd.pl never sends any Update messages. It only sends Open, Keepalive and Notification messages. - Steven At 21:46 21-10-01 +0200, Stephane Bortzmeyer wrote: >An interesting implementation of BGP (in Perl, yes), which is not >suitable for a router but may be used to monitor routes, gather >statistics, etc. > >http://bgpd.sourceforge.net/ > >Now, a serious warning: using it in front of a Zebra 0.91 crashes >Zebra's bgpd in a few hours. Zebra is probably not robust enough. But >the Zebra box was peering with other Zebras, 20 different Ciscos and a >few Junipers for several months without problems so I assume bgpd-perl >does something really nasty :-{ > >So, if you want to participate in bgpd-perl's development, do not peer >with your real routers. > > > >_______________________________________________ >Bgpd-users mailing list >Bgp...@li... >https://lists.sourceforge.net/lists/listinfo/bgpd-users |
|
From: Stephane B. <bor...@ga...> - 2001-10-21 19:47:03
|
An interesting implementation of BGP (in Perl, yes), which is not suitable for a router but may be used to monitor routes, gather statistics, etc. http://bgpd.sourceforge.net/ Now, a serious warning: using it in front of a Zebra 0.91 crashes Zebra's bgpd in a few hours. Zebra is probably not robust enough. But the Zebra box was peering with other Zebras, 20 different Ciscos and a few Junipers for several months without problems so I assume bgpd-perl does something really nasty :-{ So, if you want to participate in bgpd-perl's development, do not peer with your real routers. |
