This file is indexed.

/usr/share/doc/pmacct/examples/lpref.map.example is in pmacct 1.7.0-1.

This file is owned by root:root, with mode 0o644.

The actual contents of the file can be viewed below.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
! 
! bgp_src_local_pref_map: BGP source local preferecence map 
!
! File syntax is key-based. Read full syntax rules in 'pretag.map.example' in
! this same directory.
!
! nfacctd, sfacctd: valid keys: id, ip, in, bgp_nexthop, src_mac.
!
! list of currently supported keys follow:
!
! 'id'			ID value to assign to a matching packet or flow. Other
!			than hard-coded local preference values, this field also
!			accepts the 'bgp' keyword which triggers a BGP lookup
!			and returns its result: useful to handle exceptions.
! 'ip'                  In nfacctd it's compared against the source IP address
!                       of the device which is originating NetFlow packets; in
!                       sfacctd this is compared against the AgentId field of
!                       received sFlow samples.
! 'in'                  Input interface.
! 'bgp_nexthop'         BGP next-hop of the flow source IP address (RPF-like).
!                       This value is compared against the corresponding BGP
!                       RIB of the exporting device.
! 'peer_dst_as'         First AS hop within the AS-PATH of the source IP address
!                       (RPF-like). This value is compared against the BGP RIB
!                       of the exporting device (see 'bgp_daemon' configuration
!                       directive).
! 'src_mac'             Source MAC address of the flow. Requires NetFlow v9,
!			IPFIX or sFlow.
!
! A few examples follow. Let's define: LP=100 identifies customers, LP=80 identifies peers
! and LP=50 identifies IP transit.
!
! Customer connected to router with IP address 192.168.2.1, SNMP ifIndex 7 
!
id=100		ip=192.168.2.1	in=7

! A way to model multiple services, ie. IP transit and peering, off the same interface.
! Realistically services should be delivered off different sub-interfaces, but still ... 
! 
id=50		ip=192.168.1.1 	in=7	bgp_nexthop=1.2.3.4
id=80		ip=192.168.1.1 	in=7	bgp_nexthop=1.2.3.5