Establishing settlement-free peering links does not always guarantees that all traffic from that peer will be received over those links. Indeed, some traffic from settlement-free peers might arrive over transit provider links. Detecting and measuring this traffic helps operators to correctly manage their peering relationships.

pmacct can integrate telemetry data (IPFIX, NetFlow, sFlow) with policy information to monitor this type of traffic. In this document, we explain how to do it assuming that capturing is done inbound for traffic entering the observed routing domain, and using mysql as a storage backend.

The steps required to identify this traffic are two:

  1. Identify transit input interfaces, physical or logical
  2. Identify settlement-free peering neighbors

For the first requirement, a pre_tag_map can be used to identify the type of link. Let us assume that the pre_tag_map is filled as follows:

! Transit port id=80       ip=<x.x.x.x>      in=<I> 
! Peer port id=100      ip=<y.y.y.y>      in=<J> 
! Customer port id=120      ip=<z.z.z.z>      in=<K>

Also, remember to add <tag> into the aggregate primitives.

For the second requirement, the type of neighbor can be stored in a separate mysql table relating each ASes with their type. This table can have a simple scheme:

Create table as_to_type
asn INT(4) UNSIGNED NOT NULL,
peer_type INT(1) UNSIGNED NOT NULL,
PRIMARY KEY (asn))

The table can be created manually, or by help of BGP information (LP, peer_src_as). Let us assume that settlement-free peers are identified with a <peer_type> of 90.

The next query could be then used to find the peering traffic over transit links:

Select * from <flow_table> as a join as_to_type as b on a.tag = 80 and a.src_as = b.asn and b.peer_type = 90;

pmacct Wiki: FindingPeersOverTransit (last edited 2015-10-24 16:49:31 by paolo)