Sentinel BGP Peering

How to configure Traffic Sentinel to BGP peer with a route-reflector to learn routing tables, AS-Paths and Communities.

Feature Overview

If your routers fully implement the sFlow "Extended Gateway" extension (see sFlow Specification), this peering connection is not needed. Otherwise this feature can be used to learn the routing tables and use them to splice in the CIDR, ASPath and Communities fields so they are available in the traffic database just as if they were fields decoded from packet headers or flow records.

Database Fields

The traffic database fields that can be populated by this feature include:

  • bgpdestinationaspath
  • bgpsourceas
  • bgpdestinationas
  • bgpsourcepeeras
  • bgpdestinationpeeras
  • bgpas
  • bgpcommunities
  • bgplocalpref
  • bgpnexthop
  • bgpnexthop6
  • ipsourcesubnet
  • ip6sourcesubnet
  • ipdestinationsubnet
  • ip6destinationsubnet
  • ipclientsubnet
  • ip6clientsubnet
  • ipserversubnet
  • ip6serversubnet
  • ipnexthoprouter
  • ip6nexthoprouter

Configuration Steps

In global.prefs (File>Configure>Edit>Edit Files>global.prefs), add lines to identify the peering connection:


Configure the route-reflector, (on in this example), to expect a BGP client connection from this server. Here is some example configuration for the popular bird routing daemon:

protocol bgp peer_SENTINEL {
  table peers;
  local as 12345;
  neighbor as 65500;
  import none;
  export all; 
  error wait time 1,10;
  error forget time 10;

Next, test the peering connection by logging into Traffic Sentinel and running /usr/local/inmsf/scripts/runBgpmon. You should see routing updates emitted as ASCII lines. Like this:

+,,,,IGP,35908 1299 3356 3549,,
+,,,,IGP,35908 1299 3356 3549,,
+,,,,IGP,35908 1299 3356 3549,,
+,,,,IGP,35908 1299 3356 3549,,
+,,,,IGP,35908 1299 3356 3549,,
+,,,,IGP,35908 1299 3356 3549,,
+,,,,IGP,35908 1299 3356 3549,,
+,,,,IGP,35908 1299 3356 3549,,
+,,,,IGP,35908 1299 3356 3549,,

It may take a minute or two for the whole routing table to scroll by (could be 600,000 routes), but after that you should only see a steady trickle of announcements and withrawals. Hit control-c to end the test.

Finally, stop and start data collection under File>Control. You should now see that the process "inxsazd" has a child process running the script:

  \_ inxtomcat -t 1580432484
  |   \_ java -Djava.awt.headless=true -Xmx2G -javaagent:sflowagent.jar -Dsflow.hostname=jvm-inmsf -Ds
  \_ inxtskd -t 1580432484
      \_ inxsazd -t 1580432484 -u inmsf -R
      |   \_ /usr/bin/perl /usr/local/inmsf/inx/bin/../../scripts/ -l 65
      \_ inxpoll -t 1580432484 -H 1
      \_ inxADSweep -t 1580432484

Using Exabgp

If you install the exabgp package you can configure Traffic Sentinel to use it by adjusting the global.prefs settings. For example:


Now if you stop and start data collection under File>Control the runBgpmon script will execute exabgp instead. The configuration file will be exabgp.conf, generated from exabgp_conf.m4, and the translation from JSON is performed in (all in the /usr/local/inmsf/scripts/ directory).


  • You may find that you need to install the package m4 as a prerequistite.
  • You may have to make the script executable, with:
    sudo chmod 755
  • Running the runBgpmon script manually is the best way to test the peering connection before using it. Error messages are logged to /usr/local/inmsf/log/bgpmon.log.

  • Please contact support if you run into difficulties.

Related Topics