Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Peering Matrix Overview
The peering matrix system builds up a list of who is interconnected to whom on the IXP. There are two primary data sources: the route server database and sflow. It is assumed that all IXP participants who connect to the route server have an open peering policy.
NB: You must check the Peering Matrix option when editing VLANs for that VLAN to be included in the peering matrix on the frontend.
Route Server database
Route server peerings are automatically read from the peering matrix back-end database as necessary. No operator input is required for this.
Configuring sflow BGP session detection
IXP Manager can pick out active BGP sessions from an sflow data feed. This is handled using the
sflow-detect-ixp-bgp-sessions script. As this is a perl script, it is necessary to install all the perl modules listed in the
Sflow is a packet sampling mechanism, which means that it will take some while before the peering database is populated. After 24 hours of operation, the peering database should be relatively complete.
Sflow data fan-out
sflow-detect-ixp-bgp-sessions needs its own dedicated sflow data need, so it is necessary to set up sflow data fan-out using the
sflowtool as described in the sflow fan-out instructions. INEX normally uses udp port 5501 for its bgp detection sflow feed.
In addition to the correct SQL configuration for the
sflow-detect-ixp-bgp-sessions needs the following options set in the
<ixp> section of
sflowtool: the location of the
sflowtool_bgp_opts: command line arguments for
<ixp> # location of sflow executable sflowtool = /usr/local/bin/sflowtool # sflow listener to p2p rrd exporter, listening on udp port 5500 sflowtool_opts = -4 -p 5500 -l # sflow listener for BGP peering matrix, listening on udp port 5501 sflowtool_bgp_opts = -4 -p 5501 -l </ixp>
Testing the daemon
The system can be tested using
sflow-detect-ixp-bgp-sessions --debug. If it starts up correctly, the script should occasionally print out peering sessions like this:
DEBUG: [2001:db8::ff]:64979 - [2001:db8::7]:179 tcpflags 000010000: ack. database updated. DEBUG: [192.0.2.126]:30502 - [192.0.2.44]:179 tcpflags 000010000: ack. database updated. DEBUG: [2001:db8::5:0:1]:179 - [2001:db8::4:0:2]:32952 tcpflags 000011000: ack psh. database updated.
Running the daemon in production
control-sflow-detect-ixp-bgp-sessions should be copied (and edited if necessary) to the operating system startup directory so that
sflow-detect-ixp-bgp-sessions is started as a normal daemon.
- The script doesn't print anything when in debug mode
This probably means that it's not getting an sflow feed. Check to ensure that sflowtool is feeding the script correctly by using the
sflow-detect-ixp-bgp-sessions --insanedebug. This should print out what the script is reading from sflowtool. Under normal circumstances, this will be very noisy.
- The script prints
ignored - no address match in databasewhen in debug mode
If the IP addresses match those on the IXP's peering LAN, then the IP address database is not populated correctly. This can be fixed by entering the IXP's addresses in the
IP Addressing menu of the web UI.