Add feature to generate IP filters with statistics to count traffic to/from given AS, based on prefix list matches

[jbemmel]

Sample usage:

jeroen@host~$ ./bgpq4 -n -c AS13335 -lCloudFlare
/configure filter match-list
delete ip-prefix-list "AS13335"
ip-prefix-list "AS13335" {
    prefix 1.0.0.0/24 { }
    prefix 1.1.1.0/24 { }
    prefix 8.6.112.0/24 { }
    prefix 8.6.144.0/24 { }
    prefix 8.6.145.0/24 { }
    ... etc ...
    prefix 223.27.48.0/20 { }
}
/configure filter md-auto-id { filter-id-range { start 1 end 65535 } }
/configure filter ip-filter "CloudFlare-in" {
default-action accept
entry 13335 { match { src-ip { ip-prefix-list "AS13335" } }
action accept }
}
/configure filter ip-filter "CloudFlare-out" {
default-action accept
entry 13335 { match { dst-ip { ip-prefix-list "AS13335" } }
action accept }
}

The generated filters "CloudFlare-in" and "CloudFlare-out" can be assigned as ingress/egress filters to interfaces, to count traffic to/from CloudFlare (based on IRR prefix list matches)

That way, peering operators can gain insight into the amount of traffic (packets/bytes) they are sending/receiving to a given AS, for example to optimize transit peering arrangements

[jbemmel]

To illustrate:

[gl:/configure router "Base"]
A:admin@sros# info
    autonomous-system 50266
    interface "i1/1/c1/1" {
        port 1/1/c1/1
        egress {
            filter {
                ip "NN-out"
            }
        }
        ingress {
            filter {
                ip "NN-in"
            }
        }

Once applied, statistics can be obtained per AS:

[gl:/configure router "Base"]
A:admin@sros# info /state filter ip-filter "NN-in" entry 48105 
    inserted-by fixed
    num-sub-entries 6
    num-cam-entries-fp2 6
    num-cam-entries-fp4 6
    log-instantiated false
    sticky-dest-hold-remain 0
    statistics {
        ingress-hit-pkt 0
        ingress-hit-byte 0
        egress-hit-pkt 0
        egress-hit-byte 0
        card 1 {
            ingress-hit-pkt 0
            ingress-hit-byte 0
            egress-hit-pkt 0
            egress-hit-byte 0
        }
    }
    action {
        pbr-target-status unknown
    }

[forkwhilefork]

Outside of bgpq4, I'm not sure this is the best way to obtain this information. Flow sampling is more robust and gives you more information.

[jbemmel]

Outside of bgpq4, I'm not sure this is the best way to obtain this information. Flow sampling is more robust and gives you more information.

I think there are use cases for both approaches. IP filters are more accurate, they count every byte in every packet - so if you're trying to match DNS traffic, or some other specific application or attack for example, you get a more detailed view. Plus, the stats can readily be displayed on a Grafana dashboard when you already have gNMI infrastructure in place.

I'd say let users try it in practice, and see if it helps them. We may have to evolve it a bit to target more specific use cases - this is just a starting point to hint at what's possible

[deltadragon]

Then just use fastnetmon or similar software. Use case of bgpq4 is completely different than traffic accounting.
One more thing is you could do whatever IP filters with user using -F defined format aswell.

[MrHamel]

@jbemmel The point isn't what's possible, it's that your feature request does not match the goals set for this software. Use Kentik or other flow monitoring solutions, and write the applicable ACLs yourself.