DetectingRoutingViolations

Detecting routing violations

Detecting routing violations (or revenue leaks in more management language style) is integral part of the day-to-day monitoring of an internet service provider backone that is transiting public internet IPv4/IPv6 traffic. Violations can occur due to a number of reasons including pointing of default routes, erroneous routing configurations, and advertisement of more specific routes in combination with BGP scoping services.

pmacct is able to create traffic matrices of custom spatial and temporal resolution, can integrate telemetry data (IPFIX, NetFlow, sFlow) with BGP prefix information. As a result can efficiently support such monitoring activity. Assuming capturing is done inbound for traffic entering the observed routing domain, the following two elements can be used for the purpose:

local preference value
input interface, physical or logical

Say a purposelly built traffic matrix encompasses the following aggregation method:

pre_tag_map: /path/to/inbound.map
aggregate: tag, local_pref

Say the Local Preference values used in the observed routing domain are essentially three:

LP=80 for upstream transits
LP=100 for peers, private and public
LP=120 for customers

Say a 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>

The resulting traffic matrix will be on these lines:

mysql> SELECT agent_id AS tag, local_pref FROM <table>;
+-----+------------+
| tag | local_pref |
+-----+------------+
| 100 |        120 |
| 100 |        120 |
| 100 |        120 |
| 120 |         80 |
| 100 |        100 | <-- violation
| 100 |        120 |
| 100 |        120 |
| 100 |        120 |
| 100 |        120 |
| 120 |        100 |
+-----+------------+

This is just a typical scenario in which the Local Preference is set as LPtransit < LPpeer < LPcustomer. As we have just described, it's possible to tag the ingress interfaces in the exact same fashion, INtransit < INpeer < INcustomer. To detect a violation a quick check can be run against the traffic matrix to see whether any flow is transiting through the observed routing-domain connecting any two peers, upstream providers or combination of these:

IF (IN < INcustomer AND LP < LPcustomer) THEN
{
  // Violation occurred
}

Futher enriching the traffic matrix, ie. specifying the aggregation method below, can intuitively show not only the fact that there has been a violation but also highlight the tributary traffic aggregates responsible for such violation.

pre_tag_map: /path/to/inbound.map
aggregate: tag, src_as, peer_src_as, src_net, local_pref
bgp_peer_src_as_type: bgp

+-----+--------+-------------+----------------+------------+
| tag | as_src | peer_as_src | peer_ip_src    | local_pref |
+-----+--------+-------------+----------------+------------+
| 100 |     J0 |          K0 | x.x.x.x        |        120 |
| 100 |     J1 |          K1 | x.x.x.x        |        120 |
| 100 |     J2 |          K2 | x.x.x.x        |        120 |
| 120 |     J3 |          K3 | x.x.x.x        |         80 |
| 100 |     J4 |          K4 | x.x.x.x        |        100 | <-- violation
| 100 |     J5 |          K5 | x.x.x.x        |        120 |
| 100 |     J6 |          K6 | x.x.x.x        |        120 |
| 100 |     J7 |          K7 | x.x.x.x        |        120 |
| 100 |     J8 |          K8 | x.x.x.x        |        120 |
| 120 |     J9 |          K9 | x.x.x.x        |        100 |
+-----+--------+-------------+----------------+------------+