Giter Site home page Giter Site logo

exa-networks / exabgp Goto Github PK

View Code? Open in Web Editor NEW
2.0K 137.0 439.0 14.48 MB

The BGP swiss army knife of networking

License: Other

Shell 0.94% Python 98.75% Perl 0.10% Dockerfile 0.07% Makefile 0.14%
python bgp ddos-protection health-check ipv6 mpls vpls flowspec ipv4 exabgp

exabgp's Introduction

ExaBGP has been used to:

  • provide cross-datacenters failover solutions migrating /32 service IP.
  • mitigate network attacks, centrally deploying network-level filters (blackhole and/or flowspec)
  • gather network information ( using BGP-LS, or BGP with Add-Path)

More information is available on the wiki.

Installation

zipapp

From the source folder, it is possible to create a self-contained executable which only requires an installed python3 interpreter

> git clone https://github.com/Exa-Networks/exabgp exabgp-git

> cd exabgp-git
> release binary /usr/local/sbin/exabgp
> /usr/local/sbin/exabgp --version

which is a helper function and creates a python3 zipapp

> git clone https://github.com/Exa-Networks/exabgp exabgp-git

> cd exabgp-git
> python3 -m zipapp -o /usr/local/sbin/exabgp -m exabgp.application:main  -p "/usr/bin/env python3" src
> /usr/local/sbin/exabgp --version

git main

In case of issues, we are asking users to run the latest code directly for a local git clone.

> git clone https://github.com/Exa-Networks/exabgp exabgp-git

> cd exabgp-git
> ./sbin/exabgp --version
> ./sbin/exabgp --help

> ./sbin/exabgp --run healthcheck --help
> env PYTHONPATH=./src python3 -m exabgp healthcheck --help
> ./bin/healthcheck --help

It is then possible to change git to use any release (here 4.2.18)

> git checkout 4.2.18
> ./sbin/exabgp --version

docker

You can also use the repository to create a docker image

> git clone https://github.com/Exa-Networks/exabgp exabgp-git

> cd exabgp-git
> docker build -t exabgp ./
> docker run -p 179:1790 --mount type=bind,source=`pwd`/etc/exabgp,target=/etc/exabgp -it exabgp -v /etc/exabgp/parse-simple-v4.conf

It is possible to add your configuration file within the docker image and/or use the container like the exabgp binary. You can also use the Docker.remote file to build it using pip (does not require any other file)

pip releases

The latest version is available on pypi, the Python Package Index

> pip install exabgp

> exabgp --version
> exabgp --help

> exabgp --run healthcheck --help
> python3 -m exabgp healthcheck --help

GitHub releases

It is also possible to download releases from GitHub

> curl -L https://github.com/Exa-Networks/exabgp/archive/4.2.18.tar.gz | tar zx

> cd exabgp-4.2.18
> ./sbin/exabgp --version
> ./sbin/exabgp --help

> ./sbin/exabgp --run healthcheck --help
> env PYTHONPATH=./src python3 -m exabgp healthcheck --help
> ./bin/healthcheck --help

OS packages

The program is packaged for many systems such as Debian, Ubuntu, ArchLinux, Gentoo, FreeBSD, OSX.

RHEL users can find help here.

Many OS provide old, not say ancient, releases but on the plus side, the packaged version will integrate with systemd.

As it is often the recommended way to get software onto the server, feel free to use them. However, we recommend a pip installation as it will install the latest stable version. should you encounter any issues, we will ask you to install the latest code (the main branch).

pick and choose

Multiple versions can be used simultaneously without conflict when ExaBGP is run from extracted archives, docker, and/or local git repositories.

Upgrade

ExaBGP is self-contained and easy to upgrade/downgrade by:

  • replacing the downloaded release folder for releases download
  • running git pull in the repository folder for installation using git main
  • running pip install -U exabgp, for pip installations
  • running apt update; apt upgrade exabgp for Debian/Ubuntu

If you are migrating your application from ExaBGP 3.4 to 4.x please read this wiki entry.

The configuration file and API format may change occasionally, but every effort is made to ensure backward compatibility is kept. However, users are encouraged to read the release note/CHANGELOG and check their setup after any upgrade.

Support

ExaBGP is supported through Github's issue tracker. So should you encounter any problems, please do not hesitate to report it so we can help you.

During "day time" (GMT/BST) feel free to contact us on Slack. We will try to respond if available.

The best way to be informed about our progress/releases is to follow us on Twitter.

If there are any bugs, we'd like to ask you to help us fix the issue using the main branch. We may then backport the fixes to the 4.2 stable branch.

Please remove any non git main installations if you are trying the latest release to prevent running the wrong code by accident; it happens more than you think, and verify the binary by running exabgp version.

We will nearly systematically ask for the FULL output exabgp with the option -d.

Development

ExaBGP 3.4 and previous versions are Python 2 applications. ExaBGP 4.0 had support for both Python 2 and 3. The current version of ExaBGP (4.2 and main) targets Python 3 only. The code should work with all recent versions (>= 3.7), but the requirement is set to 3.8.1 as some of the tooling now requires it (such as flake8).

ExaBGP is nearly as old as Python3. A lot has changed since 2009; the application does not use Python3 'new' async-io (as we run a homemade async core engine). It may never do as development slowed, and our primary goal is ensuring reliably for current and new users.

The main branch (previously the master branch) will now be ExaBGP 5.0.x. The program command line arguments have already been changed and are no longer fully backwards compatible with versions 3 and 4. We recommend using the 4.2 releases in production, but running master is sometimes required.

Documentation

You may want to look at these related projects.

The documentation is known to be imperfect. One could even say wanting, limited, insufficient and lacking. Therefore, any contribution (however small) toward its improvement is genuinely welcomed.

Other users did however do a fair bit of documentation, just not on the wiki. 😭

To understand how ExaBGP should be configured, please have a look into the etc/exabgp folder of the repository where a great many examples are available.

exabgp --help is also a treasure trove of information.

Features

RFC support includes ASN4, IPv6, MPLS, VPLS, Flow, Graceful Restart, Enhanced Route Refresh, Extended Next-Hop, "BGP-LS" and AIGP among others. More information can be found here

ExaBGP does not perform any FIB manipulation. If this is what you need, you may consider another open source BGP daemon such as BIRD or Quagga.

RFC compliance details the latest developments.

Development

Debug environment variable

The following "unsupported" options are available to help with development:

  exabgp.debug.configuration  to trace with pdb configuration parsing errors
  exabgp.debug.pdb            enable python debugger on runtime errors (be ready to use `killall python` to handle orphaned child processes)
  exabgp.debug.route          similar to using decode but using the environment

Test suite

If you want to check any code changes, the repository comes with a qa folder, which includes many way to check code integrity.

ExaBGP comes with a set of functional tests, each test starts an IBGP daemon expecting a number of per recorded UPDATEs for the matching configuration file.

You can see all the existing tests running ./qa/bin/functional encoding --list. Each test is numbered and can be run independently (please note that 03 is not the same as 3).

# ./qa/bin/functional encoding    # (run all the test)
# ./qa/bin/functional encoding A  # (run test 03 as reported by listing)

You can also manually run both the server and client for any given test:

shell1# ./qa/bin/functional encoding --server A
shell2# ./qa/bin/functional encoding --client A

A test suite is also present to complement the functional testing. (pip3 install pytest pytest-cov)

# env exabgp_log_enable=false pytest --cov --cov-reset ./tests/*_test.py

You can decode UPDATE messages using ExaBGP decode option.

# env exabgp_tcp_bind='' ./sbin/exabgp decode -c ./etc/exabgp/api-open.conf FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF:003C:02:0000001C4001010040020040030465016501800404000000C840050400000064000000002001010101
{ "exabgp": "4.0.1", "time": 1560371099.404008, "host" : "ptr-41.212.219.82.rev.exa.net.uk", "pid" : 37750, "ppid" : 10834, "counter": 1, "type": "update", "neighbor": { "address": { "local": "127.0.0.1", "peer": "127.0.0.1" }, "asn": { "local": 1, "peer": 1 } , "direction": "in", "message": { "update": { "attribute": { "origin": "igp", "med": 200, "local-preference": 100 }, "announce": { "ipv4 unicast": { "101.1.101.1": [ { "nlri": "1.1.1.1/32", "path-information": "0.0.0.0" } ] } } } } } }

exabgp's People

Contributors

benagricola avatar borjam avatar brijohn avatar chantra avatar clwluvw avatar cooperlees avatar dependabot[bot] avatar elindsey avatar garci66 avatar habbie avatar he32 avatar job avatar lazy404 avatar leleobhz avatar lochiiconnectivity avatar louis-6wind avatar paddy01 avatar proelbtn avatar ruissalo avatar slankdev avatar solidgoldbomb avatar takehaya avatar tehnerd avatar thomas-mangin avatar tinusf avatar tmmorin avatar v-kamerdinerov avatar vincentbernat avatar wavezhang avatar wmiltenburg avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

exabgp's Issues

Perl example for an external process

From ryanpsteinmetz on November 28, 2012 20:06:09

If you do not configure STDOUT to be unbuffered, your perl watchdog/dynamic script will not work properly.

Below is an example that should probably be included in the distribution:

!/usr/bin/perl

use strict;
use warnings;

Ignore Control C

$SIG{'INT'} = sub {};

make STDOUT unbuffered

select STDOUT; $| = 1;

while (1) {
sleep 10;

without name exabgp will use the name of the service as watchdog name

print "withdraw watchdog\n";
sleep 5;

print "announce watchdog\n";
sleep 5;
}

Original issue: http://code.google.com/p/exabgp/issues/detail?id=15

Invalid python interpreter

From [email protected] on December 08, 2011 01:25:42

On archlinux, python 2.7 interpreter is call python2 an not python. In previous version (pre 2.x.y), interpreter was detected setup.py caller and set correctly.

In new version, exabpg is become a script shell and interpreter is detected by a which python. It's python 3 on archlinux.

Can we have a way to define current python interpreter path correctly ?

Original issue: http://code.google.com/p/exabgp/issues/detail?id=3

feature request : disable caching

From thomas.mangin on November 16, 2012 08:24:24

ExaBGP is currently parse all received route, generate python structures for the attributes seen and cache them to improve performance (many routes on the global routing table received from the same transit providers share many attributes).
Daniel Piekacz asked for a way to turn this caching off, on his machine with multiple transit providers, the caching can take several 100s of Mb of memory and he prefers to have slower route parsing and save the memory.

Original issue: http://code.google.com/p/exabgp/issues/detail?id=12

Command parsing regression in certain versions

From [email protected] on August 22, 2013 14:11:32

The issue:

Thu, 22 Aug 2013 09:09:54 | INFO | 6603 | processes | Command from process service-2 : announce route 192.0.2.1 next-hop 10.0.0.1 community [ no-export ]
Thu, 22 Aug 2013 09:09:54 | WARNING | 6603 | supervisor | Command could not parse route in : announce route 192.0.2.1 next-hop 10.0.0.1 community [ no-export ]

Versions with the issue:
It looks like:

3.1.4+: bug
3 .1.3: OK Could reproduce the problem on the latest development version ? No!

3.2.0: bug
3 .2.1+: ok
tip: ok How we could reproduce the problem? echo "announce route 192.0.2.1 next-hop 10.0.0.1 community [ no-export ]" Please provide any additional information below. Changing the process to do

echo "announce route 192.0.2.1 next-hop 10.0.0.1 community [no-export]"

is a workaround for the released exabgp versions.

According to hg bisect:

The first good revision is:
changeset: 1435:5da0b0b616bb
user: Thomas Mangin [email protected]
date: Tue Jul 16 23:03:57 2013 +0100
files: CHANGELOG lib/exabgp/configuration/file.py
description:
fix bug with extra spaces in the configuration file

but I see that that related code changed a number of times, and I keep making a mess of hg bisect trying to figure out just what the problem/fix was.

Not sure what the fix here would be.. The workaround is fine for me, but others might run into this if they upgrade from an older version to 3.1.x like I did.

Original issue: http://code.google.com/p/exabgp/issues/detail?id=47

Connections closed by peer cause ExaBGP to spin CPU

From [email protected] on August 07, 2012 20:51:17

What version of ExaBGP you are using? 2.0.8 On which OS ? Linux - Debian testing with Python 2.7.3rc2 Could reproduce the problem on the latest development version ? I haven't actually tested the latest version, but looking at the code in SVN it appears the issue still exists. What steps will reproduce the problem? 1. Connect ExaBGP to a peer (I am using a Cisco router)
2. On the peer, cause the TCP connection to be closed. (On a Cisco router: clear bgp all )

What is the expected output?
ExaBGP notices the connection was closed and reestablishes it.

What do you see instead?
ExaBGP spins up to 100% CPU utilization calling recv on the socket. Please provide any additional information below. According to the Python Socket Programmin HOWTO: "When a recv returns 0 bytes, it means the other side has closed (or is in the process of closing) the connection. You will not receive any more data on this connection. Ever."

The return value of recv is not checked, however, so the connection is never closed. The attached patch is very basic but worked for me.

Attachment: connection-closed.patch

Original issue: http://code.google.com/p/exabgp/issues/detail?id=6

log rotation fails

From thomas.mangin on September 08, 2012 16:57:11

What steps will reproduce the problem? 1. start ExaBGP as daemon using a logfile
2. be unlucky (it does not happen all the time at all !)
3. see that the child process died
4. strace -f -s 1000 -p
5. noticed with child process dead, do not know if it is related What is the expected output? What do you see instead? The log to be rotated and the deamon to run
Instead the logging just stops Please use labels and text to provide additional information. The following is being printed to /dev/null

write(2, "Traceback (most recent call last):\n", 35) = 35
write(2, " File "/usr/lib/python2.6/logging/handlers.py", line 71, in emit\n", 66) = 66
stat("/usr/lib/python2.6/logging/handlers.py", {st_dev=makedev(8, 7), st_ino=919107, st_mode=S_IFREG|0644, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=88, st_size=44354, st_atime=2012/01/05-14:46:35, st_mtime=2010/04/16-15:41:16, st_ctime=2012/01/05-14:47:00}) = 0
write(2, " if self.shouldRollover(record):\n", 36) = 36
write(2, " File "/usr/lib/python2.6/logging/handlers.py", line 145, in shouldRollover\n", 77) = 77
stat("/usr/lib/python2.6/logging/handlers.py", {st_dev=makedev(8, 7), st_ino=919107, st_mode=S_IFREG|0644, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=88, st_size=44354, st_atime=2012/01/05-14:46:35, st_mtime=2010/04/16-15:41:16, st_ctime=2012/01/05-14:47:00}) = 0
write(2, " self.stream.seek(0, 2) #due to non-posix-compliant Windows feature\n", 72) = 72
write(2, "ValueError: I/O operation on closed file\n", 41) = 41
stat("/etc/localtime", {st_dev=makedev(8, 1), st_ino=1225, st_mode=S_IFREG|0644, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=8, st_size=3661, st_atime=2012/03/13-15:54:17, st_mtime=2012/03/13-15:54:17, st_ctime=2012/03/13-15:54:17}) = 0
write(2, "Traceback (most recent call last):\n", 35) = 35
write(2, " File "/usr/lib/python2.6/logging/handlers.py", line 71, in emit\n", 66) = 66
stat("/usr/lib/python2.6/logging/handlers.py", {st_dev=makedev(8, 7), st_ino=919107, st_mode=S_IFREG|0644, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=88, st_size=44354, st_atime=2012/01/05-14:46:35, st_mtime=2010/04/16-15:41:16, st_ctime=2012/01/05-14:47:00}) = 0
write(2, " if self.shouldRollover(record):\n", 36) = 36
write(2, " File "/usr/lib/python2.6/logging/handlers.py", line 145, in shouldRollover\n", 77) = 77
stat("/usr/lib/python2.6/logging/handlers.py", {st_dev=makedev(8, 7), st_ino=919107, st_mode=S_IFREG|0644, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=88, st_size=44354, st_atime=2012/01/05-14:46:35, st_mtime=2010/04/16-15:41:16, st_ctime=2012/01/05-14:47:00}) = 0
write(2, " self.stream.seek(0, 2) #due to non-posix-compliant Windows feature\n", 72) = 72
write(2, "ValueError: I/O operation on closed file\n", 41) = 41
select(5, [4], [], [], {0, 495882}^C <unfinished ...>

Original issue: http://code.google.com/p/exabgp/issues/detail?id=9

exabgp 3.0.11 and tcpserver behaviour

From [email protected] on February 18, 2013 08:43:28

Hello Thomas.
1rst of all, congraatulations for exaBGP tool creation. Brilliant idea! Thanks.

I'm quite new to exaBGP. Testing release 3.0.11 and I've found a different behaviour between announcing routes using static config and passing same routes throught tcpserver.
My question is: Is this behavioour normal? Am I doing something wrong using tcpserver?
In attach txt I've tried to document what I've found.
Thanks in advance,
Lorenzo

Attachment: 20130217_issue_report___exabgp_3.0.11_and_tcpserver_behaviour.txt

Original issue: http://code.google.com/p/exabgp/issues/detail?id=22

exabgp can block when connecting to a peer

From [email protected] on August 16, 2013 19:39:03

See the proposed patch.

socket.connect() may block when the peer is unreachable for some
reason (network down for example). We need to pass the socket to async
mode before connecting. Therefore, we don't get the appropriate return
code right now. We intercept it during the first attempt to write with
socket.getsockopt() and we translate this to an error.

Nothing is done when reading but for BGP, we always send an OPEN
message after connect. If we wanted to ensure correct handling on both reading and writing, we should use the self.established flag. If connect is successful, we set self.established to true. From reading and writing, we call an helper function that will check if self.established is True. If not, we select on write and check if there is an error with getsockopt(). For Incoming, self.established will be set to True from the beginning.

I can propose a patch for this approach if you want.

Attachment: 0001-Don-t-block-when-connecting-to-a-peer.patch

Original issue: http://code.google.com/p/exabgp/issues/detail?id=43

self configuring neighbors

From thomas.mangin on July 25, 2013 09:14:42

It would be practical when accepting many connections from many peers from a trusted range to not have to specify the details of the connection.

A BGP speaker receiving a connection can extract from the OPEN message sent from the peer all the information it needs to reply. Only the router-id need to be configured locally to prevent collision.

Practically it could look like :

neighbor 4.3.2.1 {
reflection;
router-id 10.20.30.40;
}

Original issue: http://code.google.com/p/exabgp/issues/detail?id=38

peer removal crashes

From [email protected] on December 23, 2012 18:12:22

What version of ExaBGP you are using? 3.0.11 / TIP Could reproduce the problem on the latest development version ? Yes What steps will reproduce the problem? 1. start exabgp
2. remove a peer
3. HUP exabgp What is the expected output? What do you see instead? the peer should be removed, but a key error is raised due to:

if key not in self.configuration.neighbor.keys():
    neighbor = self.configuration.neighbor[key]

Attachment: peer_remove.patch

Original issue: http://code.google.com/p/exabgp/issues/detail?id=18

Enhancement: add fifo for external checks

From [email protected] on June 05, 2013 11:52:03

Hello, exabgp is a great tool. Using processes checks is also very useful. Any way is there a simple way to add a fifo that would be checked (such as processes output) to add or withdraw routes?

The goal is to use an external monitoring system such as nagios event handler to control exabgp according check results.

A hugely workaround is to do something like:

echo "announce 10.1.2.3/32 next-hop 10.10.2.3" > /proc/cat /var/run/exabgp/exabgp.pid/fd/$(lsof -p cat /var/run/exabgp/exabgp.pid |grep FIFO | sed -n 's/.([0-9]+)r./\1/p' | head -n1)

It would be simpler to add a control fifo (such as /var/run/exabgp/control) and send commands directly to it.

Thanks in advance for your support. What version of ExaBGP you are using? 3.x.x On which OS ? Linux

Original issue: http://code.google.com/p/exabgp/issues/detail?id=28

Problem with OpenBSD 4.7 OpenBGPD

From [email protected] on October 27, 2010 15:42:24

When ExaBGP (v 1.0.2) try to connect to OpenBGPD (OpenBSD v4.7) and say:
300 16:34:40 OpenBGPPeerIP/ 41157 -> OPEN version=4 asn=41157 hold_time=180 router_id=ExaBGPIP capabilities=[Multiprotocol for IPv4 unicast, 4Bytes AS 41157]
300 16:34:41 OpenBGPPeerIP/ 41157 Sending Notification (2,0) [OPEN message error: Unspecific.] bad length for OPEN capability (size mismatch)
300 16:34:43 OpenBGPPeerIP/ 41157 -> OPEN version=4 asn=41157 hold_time=180 router_id=ExaBGPIP capabilities=[Multiprotocol for IPv4 unicast, 4Bytes AS 41157]

Here is a tcpdump of the exchange:

16:34:40.641016 ExaBGPIP.38386 > OpenBGPPeerIP.bgp: S 1393923812:1393923812(0) win 16384 <mss 1460,nop,nop,sackOK,nop,wscale 0,nop,nop,timestamp 3190136799 0> (DF)
16:34:40.641149 OpenBGPPeerIP.bgp > ExaBGPIP.38386: S 1446886952:1446886952(0) ack 1393923813 win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp 94785184 3190136799> (DF)
16:34:40.641174 ExaBGPIP.38386 > OpenBGPPeerIP.bgp: . ack 1 win 16384 <nop,nop,timestamp 3190136799 94785184> (DF)
16:34:40.641375 ExaBGPIP.38386 > OpenBGPPeerIP.bgp: P 1:46(45) ack 1 win 16384 <nop,nop,timestamp 3190136799 94785184>: BGP (OPEN: Version 4, AS #41157, Holdtime 180, ID ExaBGPIP, Option length 16 ((CAP MULTI_PROTOCOL [IPv4 Unicast]) (CAP AS4 #41157))) (DF)
16:34:40.641392 OpenBGPPeerIP.bgp > ExaBGPIP.38386: P 1:46(45) ack 1 win 17376 <nop,nop,timestamp 94785184 0>: BGP (OPEN: Version 4, AS #41157, Holdtime 90, ID 81.201.176.8, Option length 16 ((CAP MULTI_PROTOCOL [IPv4 Unicast], CAP ROUTE_REFRESH, CAP AS4 #41157))) (DF) [tos 0xc0]
16:34:40.641533 OpenBGPPeerIP.bgp > ExaBGPIP.38386: P 46:65(19) ack 46 win 17376 <nop,nop,timestamp 94785184 0>: BGP (KEEPALIVE) (DF) [tos 0xc0]
16:34:40.641552 ExaBGPIP.38386 > OpenBGPPeerIP.bgp: . ack 65 win 16320 <nop,nop,timestamp 3190136799 94785184> (DF)
16:34:41.651166 ExaBGPIP.38386 > OpenBGPPeerIP.bgp: P 46:113(67) ack 65 win 16365 <nop,nop,timestamp 3190136801 94785184>: BGP (NOTIFICATION: error OPEN Message Error, subcode #0) (DF)
16:34:41.651217 ExaBGPIP.38386 > OpenBGPPeerIP.bgp: F 113:113(0) ack 65 win 16384 <nop,nop,timestamp 3190136801 94785184> (DF)
16:34:41.651298 OpenBGPPeerIP.bgp > ExaBGPIP.38386: F 65:65(0) ack 113 win 17376 <nop,nop,timestamp 94785186 0> (DF) [tos 0xc0]
16:34:41.651317 ExaBGPIP.38386 > OpenBGPPeerIP.bgp: F 113:113(0) ack 66 win 16384 <nop,nop,timestamp 3190136801 94785186> (DF)
16:34:41.651418 OpenBGPPeerIP.bgp > ExaBGPIP.38386: F 65:65(0) ack 114 win 17376 <nop,nop,timestamp 94785186 0> (DF) [tos 0xc0]
16:34:41.651430 ExaBGPIP.38386 > OpenBGPPeerIP.bgp: . ack 66 win 16384 <nop,nop,timestamp 3190136801 0> (DF)
16:34:41.651540 OpenBGPPeerIP.bgp > ExaBGPIP.38386: . ack 114 win 17376 <nop,nop,timestamp 94785186 0> (DF) [tos 0xc0]
16:34:43.670894 ExaBGPIP.19431 > OpenBGPPeerIP.bgp: S 529047581:529047581(0) win 16384 <mss 1460,nop,nop,sackOK,nop,wscale 0,nop,nop,timestamp 597536024 0> (DF)
16:34:43.671025 OpenBGPPeerIP.bgp > ExaBGPIP.19431: S 3918725717:3918725717(0) ack 529047582 win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp 1978500141 597536024> (DF)
16:34:43.671045 ExaBGPIP.19431 > OpenBGPPeerIP.bgp: . ack 1 win 16384 <nop,nop,timestamp 597536024 1978500141> (DF)
16:34:43.671128 ExaBGPIP.19431 > OpenBGPPeerIP.bgp: P 1:46(45) ack 1 win 16384 <nop,nop,timestamp 597536024 1978500141>: BGP (OPEN: Version 4, AS #41157, Holdtime 180, ID ExaBGPIP, Option length 16 ((CAP MULTI_PROTOCOL [IPv4 Unicast]) (CAP AS4 #41157))) (DF)
16:34:43.671270 OpenBGPPeerIP.bgp > ExaBGPIP.19431: F 1:1(0) ack 46 win 17376 <nop,nop,timestamp 1978500141 597536024> (DF)
16:34:43.671289 ExaBGPIP.19431 > OpenBGPPeerIP.bgp: . ack 2 win 16384 <nop,nop,timestamp 597536024 1978500141> (DF)
16:34:43.975324 ExaBGPIP.19431 > OpenBGPPeerIP.bgp: F 46:46(0) ack 2 win 16384 <nop,nop,timestamp 597536025 1978500141> (DF)
16:34:43.975456 OpenBGPPeerIP.bgp > ExaBGPIP.19431: . ack 47 win 17376 <nop,nop,timestamp 1978500142 597536025> (DF)

Merci.

Manuel

Original issue: http://code.google.com/p/exabgp/issues/detail?id=1

Configuration parse improvement for groups

From [email protected] on February 06, 2013 11:06:51

Hello, As per our chat conversation here I report you the bug related to config parsing. Could you please indicate : What version of ExaBGP you are using? 3.x.x On which OS ? Linux Could reproduce the problem on the latest development version ? Yes What steps will reproduce the problem? Define different PROCESS in each group of neighbors What is the expected output? What do you see instead? I expect the process been executed only in one group that is defined, but is executed in both. If different processes are configured in different groups, neighbors of group 1 should have process 1 executed for them and neighbors of group 2, process 2. Please provide any additional information below. If you have a ExaBGP dump report, please include it below.

Original issue: http://code.google.com/p/exabgp/issues/detail?id=20

'withdraw' and 'watchdog' options do not seem to work properly

From ryanpsteinmetz on November 25, 2012 15:11:01

What version of ExaBGP you are using? 3.0.10 On which OS ? FreeBSD What steps will reproduce the problem? 1. Load the configuration from ibgp4-watchdog.txt or ibgp4-withdrawn.txt
2. Use the sample processes/watchdog-1.sh script
3. Examine debug log output/RIB on remote router. What is the expected output? What do you see instead? In both cases, exabgp seems to unconditionally announce the route. When the watchdog script sends the withdraw command, we see it in the log "Command from process service-watchdog : withdraw watchdog test" yet, the routes associated with watchdog test are still being announced.

In the case of routes with the 'withdraw' keyword, exabgp initially decides not to announce, however, seconds later it announces the route without being instructed to do so.

| INFO | 17751 | rib | skipping initial announcement of route 10.7.255.54/32 next-hop 10.7.22.21
| INFO | 17751 | supervisor | Peer 10.7.255.1 ASN 65535 checking for new routes to send
| INFO | 17751 | rib | announcing route 10.7.255.54/32 next-hop 10.7.22.21

Original issue: http://code.google.com/p/exabgp/issues/detail?id=13

Incorrect parsing of mpls ipv4 withdrawn route

Hi,

When an mpls-vpn route withdrawn is received exabgp doesn't appear to parse it correctly.

The API sent the following to my program:

{ "exabgp": "2.0", "time": 1378194060, "neighbor": { "ip": "85.116.180.84", "update": { "withdraw": { "ipv4 mpls-vpn": [ "49.0.0.0/8 label [ 524288 2 ] route-distinguisher ��
��" ] } } } }

When it parsed the withdrawn route it appears to be off by 3 bytes (hence 49.0.0.0/8 and the rd being 8 random bytes as the rd type wasn't 0, 1 or 2. I will email the PCAP (which looks fine in wireshark) separately as can't attach it.

Thanks,

Peter.

Add Support for 4-byte ASNs in x.y Notation

From [email protected] on July 14, 2011 17:31:38

If you attempt to include a 4-byte ASN in the x.y notation, exabgp exits with a traceback.

To see this, include an AS Path that includes an ASN in the x.y notation, such as:

as-path 1.123;

There are two items here:
a) Feature: It doesn't support x.y notation for ASNs.
b) Bug: It doesn't gracefully handle non-numeric ASNs.

The attached patch should add support for ASNs in the x.y notation and also cause exabgp to raise a syntax error when it encounters a non-numeric ASN. I tested it locally and it behaved as expected.

I am using exabgp 1.3.3 on FreeBSD 8.2 with Python 2.6.6.

Attachment: exabgp.patch

Original issue: http://code.google.com/p/exabgp/issues/detail?id=2

Missing argument for NotificationFactory()

From [email protected] on August 16, 2013 19:48:46

Hello, Traceback (most recent call last):
File "/root/code/dailymotion/exabgp/lib/exabgp/reactor/peer.py", line 469, in _run
for event in self._connect():
File "/root/code/dailymotion/exabgp/lib/exabgp/reactor/peer.py", line 319, in _connect
for message in self._out_proto.read_open(self.neighbor.peer_address.ip):
File "/root/code/dailymotion/exabgp/lib/exabgp/reactor/protocol.py", line 158, in read_open
for received_open in self.read_message():
File "/root/code/dailymotion/exabgp/lib/exabgp/reactor/protocol.py", line 138, in read_message
yield NotificationFactory(body)
TypeError: NotificationFactory() takes exactly 2 arguments (1 given)

With the current head.

Attachment: 0002-Fix-NotificationFactory.patch

Original issue: http://code.google.com/p/exabgp/issues/detail?id=44

Do not use SO_REUSEPORT

From [email protected] on July 18, 2013 17:24:10

Hello, When running with a recent enough version of Python to have socket.SO_REUSEPORT but not a recent enough kernel to support that, we get this error in the logs:

Thu, 18 Jul 2013 18:14:07 | INFO | 730 | network | can not write to the peer, reason : Could not create socket

I don't think that you should use SO_REUSEPORT at all. Its purpose is to allow two processes to listen to the same socket at the same time. We don't want that. Connections would be load balanced between the different instances listening to the same port.

Attachment: 0001-Don-t-use-SO_REUSEPORT-option.patch

Original issue: http://code.google.com/p/exabgp/issues/detail?id=34

many dynamic announcements block keepalives

From [email protected] on June 05, 2013 23:09:10

Hello, What version of ExaBGP you are using? 3.1.10, latest clone of repo On which OS ? Fedora 18, Raspbian, OS X ML Could reproduce the problem on the latest development version ? Yes What steps will reproduce the problem? 1. Setup peering with a process
2. Announce or Withdraw many routes (e.g. example tcp server announce route 172.17.0.0/20 next-hop 192.168.2.7 split /32 but depending on hardware, it happens with fewer than these 4k routes)
3. Session drops because keepalives aren't sent What is the expected output? What do you see instead? I expect to see keepalives being sent between parsing route updates, but they aren't. The session eventually drops when the hold timer expires. Please provide any additional information below. If you have a ExaBGP dump report, please include it below. Wed, 05 Jun 2013 18:07:14 | WARNING | 32330 | supervisor | Route added : route 172.17.15.253/32 next-hop 192.168.2.7
Wed, 05 Jun 2013 18:07:14 | WARNING | 32330 | supervisor | Route added : route 172.17.15.254/32 next-hop 192.168.2.7
Wed, 05 Jun 2013 18:07:14 | WARNING | 32330 | supervisor | Route added : route 172.17.15.255/32 next-hop 192.168.2.7
Wed, 05 Jun 2013 18:07:14 | INFO | 32330 | supervisor | Performing dynamic route update
Wed, 05 Jun 2013 18:07:14 | INFO | 32330 | supervisor | Updated peers dynamic routes successfully
Wed, 05 Jun 2013 18:07:14 | INFO | 32330 | supervisor | Peer 192.168.2.1 ASN 65500 checking for new routes to send
Wed, 05 Jun 2013 18:07:14 | ERROR | 32330 | supervisor | Peer 192.168.2.1 ASN 65500 Problem while writing data to the network: [Errno 32] Broken pipe
Wed, 05 Jun 2013 18:07:15 | INFO | 32330 | network | Connected to peer 192.168.2.1 local-ip 192.168.2.7 local-as 65501 peer-as 65500 router-id 192.168.2.7 family-allowed in-open
Wed, 05 Jun 2013 18:07:15 | INFO | 32330 | supervisor | Peer 192.168.2.1 ASN 65500 BUFFERED MESSAGES (7)
Wed, 05 Jun 2013 18:07:16 | INFO | 32330 | supervisor | Peer 192.168.2.1 ASN 65500 BUFFERED MESSAGES (7)

Original issue: http://code.google.com/p/exabgp/issues/detail?id=29

run command is converted to lowercase

From [email protected] on July 18, 2013 17:18:52

Hello, The arguments of the run command are converted to lowercase. If the command use case-sensitive arguments, this could lead to some problem.

In configuration/file.py, Configuration._cleaned is converting everything to lower case. This may also cause problem with some other arguments, like BGP passwords?

Tested with the current development version.

Original issue: http://code.google.com/p/exabgp/issues/detail?id=33

Unhandled exceptions in reactor/protocol.py

From [email protected] on July 18, 2013 17:30:18

Hello, Got this exception:

Traceback (most recent call last):
File "/usr/lib/python2.7/runpy.py", line 162, in _run_module_as_main
"main", fname, loader, pkg_name)
File "/usr/lib/python2.7/runpy.py", line 72, in _run_code
exec code in run_globals
File "/root/code/dailymotion/exabgp/lib/exabgp/debug.py", line 71, in
execfile(sys.argv[0])
File "/root/code/dailymotion/exabgp/lib/exabgp/application/bgp.py", line 397, in
main()
File "/root/code/dailymotion/exabgp/lib/exabgp/application/bgp.py", line 323, in main
run(env,comment,configuration)
File "/root/code/dailymotion/exabgp/lib/exabgp/application/bgp.py", line 361, in run
Reactor(configuration).run()
File "/root/code/dailymotion/exabgp/lib/exabgp/reactor/init.py", line 154, in run
if peer.run() is not True:
File "/root/code/dailymotion/exabgp/lib/exabgp/bgp/peer.py", line 148, in run
rout = self._out_loop.next()
File "/root/code/dailymotion/exabgp/lib/exabgp/bgp/peer.py", line 444, in _run
for event in self._connect():
File "/root/code/dailymotion/exabgp/lib/exabgp/bgp/peer.py", line 330, in _connect
self._out_proto.negotiate()
File "/root/code/dailymotion/exabgp/lib/exabgp/reactor/protocol.py", line 157, in negotiate
raise Notify(2,2,'ASN in OPEN (%d) did not match ASN expected (%d)' % (self.received_open.asn,self.neighbor.peer_as))
AttributeError: 'Protocol' object has no attribute 'received_open'

This can be fixed with the provided patch. Maybe I have missed some other cases.

Attachment: 0002-Fix-some-exception-handling-in-reactor-protocol.py.patch

Original issue: http://code.google.com/p/exabgp/issues/detail?id=35

Hooking SIGHUP while running in foreground

From [email protected] on July 16, 2013 18:12:54

The process is registering a signal handler for SIGHUP even when running foreground.
If the controlling process (sh via screen in this case, though I'd guess the same occurs when ssh drops a non-screen instance) disappears it sends the child processes SIGHUP not SIGINT, so when screen gets killed off exabgp is interpreting it as a request to reload config and then sitting still running in the background.

It might be worth involving a hook of SIGUSR1 or similar for reloading config, depending on how you want to handle consistency between a daemonised instance and foreground instance?

Bug found in Exabgp 3.x.x, confirmed in mercurial tip at time of writing.
Running on ubuntu 64 bit

Regards,
Daniel

Original issue: http://code.google.com/p/exabgp/issues/detail?id=32

traceback just initiating an ibgp v4 or v6 session

From [email protected] on March 13, 2013 17:46:49

Hello, I've found 2 traceback conditions.
I'm using today's version "2013/03/13" pre-3.1.7
The enviroment is: linux fedora 16 connected to juniper-mx
2 tests: 1rst test for ipv6 and 2nd for ipv4
Steps to reproduce the problem are the same: start exabgp and receive attached log.
I repeated the tests and wiresharked the line: ip seems there is a tcp problem (attached jpgs w/ ws_filter (tcp or bgp).
The difference in the environament from other tests reported is that in this case it's a real hardware juniper router and a different server.
By the way, I've tested ping and ping6 connectivity between fedora16 and the juniper-mx and both works correctly.

Regards,
Lorenzo Murillo Could reproduce the problem on the latest development version ? Yes / No What steps will reproduce the problem? 1. 2. 3. What is the expected output? What do you see instead? Please provide any additional information below. If you have a ExaBGP dump report, please include it below.

Attachment: exabgp_v4_traceback___001_impersonalized.log exabgp_v6_traceback___001_impersonalized.log mx480-1_config_impersonalized.txt exabgp_v4_traceback___ws-filter(bgp or tcp)___001_impersonalized.jpg exabgp_v6_traceback___ws-filter(bgp or tcp)___001_impersonalized.jpg

Original issue: http://code.google.com/p/exabgp/issues/detail?id=25

duplicated routes in route list causing several unexpected issues

From [email protected] on September 06, 2012 10:43:08

Hello, Report issue:

  1. identical route can be installed to route list
  2. withdraw can only remove one of identical route instead of all
  3. routes with same NRLI but different attribute can be installed into route list as well. eventually, removing default route object will cause system to send out update instead of withdraw to corresponding neighbor.

Above issues can be found in 3.0.8, 3.0.9, 2.0.9 and 2.0.8.

Analysis: There are 3 susceptive bug along with reported issue
1 . BGP update will be accumulated in tcp-control prompt. Even they are identical. By right, update can override previous route with same prefixes for same neighbor.
2. BGP withdraw action can only remove first route in neighbor route list.
3. BGP withdraw has to match whole route attributes instead of NRLI only.

I have attached several screendump for your reference.

-- Reggie Yam @reggieyam

Attachment: exabgp_bug_report.pdf

Original issue: http://code.google.com/p/exabgp/issues/detail?id=7

next-hop self is unsupported when announced from a process

From [email protected] on July 19, 2013 18:10:03

Hi!

I was expecting that a configuration where a process is outputting "announce 1.1.1.1/32 next-hop self med 1000" was valid. However, this is not the case. When the command is parsed, the local-address is not part of the scope. I realize this may be difficult to implement because there may be several local-addresses available when we use a group.

For example:

group rs {
neighbor 2001:db8:1::4 {
router-id 1.1.1.11;
local-address 2001:db8:6::11;
local-as 65001;
peer-as 65002;
}
neighbor 2001:db8:8::5 {
router-id 1.1.1.11;
local-address 2001:db8:6::11;
local-as 65001;
peer-as 65002;
}

process watch-test {
run echo announce route 2001:db8:39::1/128 next-hop self;
}
}

Original issue: http://code.google.com/p/exabgp/issues/detail?id=37

Daemonization doesn't close file descriptors and redirect to /dev/null

From [email protected] on July 02, 2012 21:47:50

What steps will reproduce the problem? 1. Try to launch the daemon with python.subprocess, using communicate()
2. Notice blocking What is the expected output? What do you see instead? There should be no blocking. Since the daemon doesn't close file descriptors and redirect stdin/stderror to /dev/null, the communicate method waits for output, blocking forever. What version of the product are you using? On what operating system? This issue exists in the head version of exabgp.

Attachment: close-fds.txt

Original issue: http://code.google.com/p/exabgp/issues/detail?id=4

Method for triggering route dump to child process

It would be rather helpful to us to have some method to cause exabgp to provide it's entire route table to the child process.

This would allow a restarted downstream process to have the full table available to it without having to restart exa to force a resend.
As it is, if the child process restarts it is only told about subsequent route changes and thus is unaware of most of the table. This presents a problem if the child process is relaying that data to another process where it is less than ideal to persist the route table to disk.

A possible implementation, if SIGUSR2's current behaviour is as intended, would be to add a config command to the process block, something like "receive-full-at-start" perhaps, which would allow SIGUSR2 to cause the route table to be sent without breaking backward compatibility.
As a bonus, this could also let the child get a full table if it exited for another reason, rather than being killed by SIGUSR2.

Running HG tip on ubuntu 64 bit.

From [email protected] on August 08, 2013 12:42:41
Original issue: http://code.google.com/p/exabgp/issues/detail?id=42

[patch] add TCP_MD5SIG for FreeBSD systems

From ryanpsteinmetz on November 27, 2012 05:46:27

exabgp's documentation should be updated to include the following information:

  1. Recompile your kernel with the following options added and reboot:
    options IPSEC
    options TCP_SIGNATURE
    device crypto
  2. Create /etc/ipsec.conf with the following contents:
    flush;
    add My.IP.Address Peer.IP.Address tcp 0x1000 -A tcp-md5 "password";
  3. Reload the ipsec configuration by running:
    service ipsec restart
  4. In exabgp.conf, add the following to your neighbor{} block:
    md5 yes;
  5. Profit

NOTES:

  • You must set md5 yes; in the neighbor {} block. The MD5 key is set from ipsec.conf. If you try to set the key from exabgp's config file, you will receive the following error:
    FreeBSD requires that you set your MD5 key via ipsec.conf. Please review the documentation.
  • You can add multiple peers to ipsec.conf by adding additional 'add...' lines.
  • My.IP.Address should be the source IP for outbound connections.
  • Peer.IP.Address should be your BGP peer's IP address.

Attachment: patch-lib__exabgp__bgp__connection.py

Original issue: http://code.google.com/p/exabgp/issues/detail?id=14

process checkpoint and fast restart

From [email protected] on July 16, 2013 17:44:32

Running 3.1.10 under "Ubuntu 12.04 LTS" in a service provider context.

It would be advantageous to have a mechanism to checkpoint an exabgp's running process to disk. There have been some discussions around adding a mechanism to serialize the exabgp route information hash table to disk as a json formatted file. Such a checkpoint could also be used at initialization time to populate the route information to provide a fast restart.

Original issue: http://code.google.com/p/exabgp/issues/detail?id=31

issue 20130404 1exabgp-process 2neighbors

From [email protected] on April 05, 2013 05:25:07

Hi Thomas,

I have just configured a lab and found a behaviour I want to report to you.

Summary
1 exabgp process w/ 2 neighbors. For each neighbor I use a different tcp-server control process:

  • 1 ebgp w/ 192.168.101.15 (j0) → tcp-server-9001
  • 1 ibgp w/ 192.168.101.17 (j2) → tcp-server-9002

I execute exabgp normaly w/o any errors. Attached process log mbgp_2peers.process.20130404-1225

When I announce/withdraw a route (example: "announce route 3.0.0.0/16 next-hop 192.168.101.1 med 200 community [3:1]") throught tcp-server-900x, the route is in fact sent to both bgp neighbors instead of only sent to the neighbor in which the tcp-server-900x is configured.

I've logged and attached all activity:

  1. Commands sent thought tcp-server-9001 at mbgp_2peers.tcp-server-9001.20130404-1225.log
  2. Commands sent thought tcp-server-9002 at mbgp_2peers.tcp-server-9002.20130404-1225.log
  3. real traffic in wireshark (I enclose only bgp update packets) ws_vmnet1_vmnet7_20130404-1225_(bgp.type==2).pcapng
    You can view the mentioned effect using the filter 'ip.src==192.168.101.1 and (ip.dst==192.168.101.15 or ip.dst==192.168.101.17)'

Look that for any "announce/withdraw" sent in one of the tcp-server, there's always a bgp update sent over both bgp sessions.

In my opinion, every neighbor bgp session shoud be controled independently by the tcp-server it has specifically configured.

It seems it does not works that way. I wonder if this is simply a bug or a new feature request :-)

Detail:

  • exaBGP version: hg clone at 2013-04-03
  • lab scenario: attached lab_bgp_20130404-1225.jpg
  • exabgp config: attached mbgp_2peers.exabgp
    neighbor 192.168.101.15 {
    description "j0_peer_ebgp_ipv4";
    router-id 192.168.101.1;
    local-address 192.168.101.1;
    local-as 3;
    peer-as 1;

    Syslog server w/ options

    process parsed-route-backend {
    neighbor-changes;
    receive-routes;
    run /opt/exabgp_processes/syslog-1.py;
    encoder json;
    }

    Use the forking watchdog system to run a tcp-server

    process tcp-control-9001 {
    peer-updates;
    run /opt/exabgp_processes/tcp-server-9001;
    }
    }

neighbor 192.168.101.17 {
description "j2_peer_ibgp_ipv4";
router-id 192.168.101.1;
local-address 192.168.101.1;
local-as 2;
peer-as 2;

Syslog server w/ options

process parsed-route-backend {
neighbor-changes;
receive-routes;
run /opt/exabgp_processes/syslog-1.py;
encoder json;
}

Use the forking watchdog system to run a tcp-server

process tcp-control-9002 {
peer-updates;
run /opt/exabgp_processes/tcp-server-9002;
}
}

  • tcp-server processes
    tcp-server-9001 equals to default exabgp tcp-server except:
    #!/usr/bin/env python
    host, port = "localhost", 9001
    ...

tcp-server-9002 equals to default exabgp tcp-server except:

!/usr/bin/env python

host, port = "localhost", 9002
...

I also attach syslog server in case it helps mbgp_2peers.syslog.20130404-1225

Regards,

Lorenzo

Attachment: lab_bgp_20130404-1225.jpg mbgp_2peers.exabgp mbgp_2peers.process.20130404-1225 mbgp_2peers.syslog.20130404-1225 mbgp_2peers.tcp-server-9001.20130404-1225.log mbgp_2peers.tcp-server-9002.20130404-1225.log

Original issue: http://code.google.com/p/exabgp/issues/detail?id=26

Subset CIDR withdraw issue

From [email protected] on November 06, 2012 07:41:06

Hello, Report issue:
Route update is not properly conducted if there is overlapping prefix, let say CIDR 192.168.1.0/24 and its subset CIDR 192.168.1.0/(25..30). Withdrawing 192.168.1.0/24 will only update in Exabgp DB, but failed to send the withdraw message to its peers.

Above issues can be found in 3.1.0, 3.0.9, 2.0.9 and 2.0.8.

I have attached several screendump for your reference. Could reproduce the problem on the latest development version ? Yes What steps will reproduce the problem? Please refer to attached doc What is the expected output? What do you see instead? Expect to withdraw prefix and update the subnet prefix

Attachment: exabgp_bug_report_6-Nov-2012.pdf

Original issue: http://code.google.com/p/exabgp/issues/detail?id=11

High router CPU utilisation on slow script

From thomas.mangin on January 22, 2013 18:48:20

Hi Thomas,

We're playing with exabgp (which we're finding fantastically helpful and useful - so thanks for writing it :-)), however, we're seeing an undesired side effect that hopefully you'll be to help. We run Cisco 6500s, and have an exabgp server (on capable hardware) the problem is, that as we process the routes into a php script, that the route learning process seems to be limited understandably to the rate that this script can read in the data.

The problem however, is that this is causing 100% CPU utilisation on our routers during this learning process. Is there any plan to resolve it, or are you even aware of this? as it's a show stopper for us if we cause our routers to hit 100% utilisation when they're sending their table to exabgp.Hopefully it's a quick fix and an oversight on my part.

Thanks,

James

Original issue: http://code.google.com/p/exabgp/issues/detail?id=19

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.