Protocol configuration

The Border Gateway Protocol (BGP) is used to track the flows from ingress to egress through the network. To take local decisions into account, BENOCS Analytics needs to be configured as a route reflector client to any BGP router it is connected to.

We recommend connecting BENOCS Analytics directly to all routers which send NetFlow and which have external (eBGP) connections. Any router without external (eBGP) connections can be ignored.

All routers that export a flow need to establish an iBGP session with the ce00 node. All established iBGP sessions will use the same ASN as the customer network. BENOCS is configured as a route-reflector client for all sessions. Although we support actual route reflectors, using these would greatly reduce visibility and accuracy of the analysis. For this reason, we recommend the direct connection mentioned above.

Core Engine (CE) and the ce00 node

BENOCS Analytics requires the Core Engine to be part of the customer’s internal BGP (iBGP). To achieve this integration, the ce00 node must receive an address that makes it part of the customer’s network / autonomous system. The CE does not peer with the customer; instead, it become part of the customer’s iBGP itself.

Any edge router that should be analyzed by BENOCS Analytics must add the ce00 node as a BGP route reflector client (rr-Client). As an rr-Client, the CE receives the full forwarding information base (FIB) of a desired edge router, which means that it can see local routing decisions that are unique to the router.

Optimize FIB for CE

This detailed visibility through the rr-Client configuration comes at a price of holding large amounts of BGP state. To reduce load on state handling and hardware resources, the CE can de-duplicate the routing information it receives and stores it in highly efficient data structures. To take advantage of these capabilities, the customer is advised to configure the route announcements sent to the CE to use the loopback addresses of the network entities in the announcements rather than their interface IP addresses. To send only loopback addresses and avoid sending interface IP addresses we advise using the BGP next-hop-self for any route that originates from any router within the network. Furthermore, setting this option enables the network edge detection to work efficiently.

Example Cisco Configuration:

router bgp xxxx
neighbor xxx.xxx.xxx.xxx
use neighbor-group BENOCS-NEIGHBOR-GROUP
description TO-BENOCS-1
!
neighbor-group BENOCS-NEIGHBOR-GROUP
remote-as xxxx # ibgp required
password encrypted SOMETHING
description BENOCS-LISTENER-ONLY Client to receive full routing table, nothing send
update-source Loopback0
address-family ipv4 unicast
route-policy BENOCS-Listener-in in
route-reflector-client
next-hop-self
soft-reconfiguration inbound always
!
address-family ipv6 unicast
update-source Loopback0
route-policy BENOCS-Listener-in in
route-reflector-client
next-hop-self
!
route-policy BENOCS-Listener-in
drop
end-policy
!

BENOCS accommodates all major flow protocols such as sFlow, NetFlow, IPFIX, cflow, jflow, netstream, etc. from all edge routers, i.e. all routers holding an eBGP session or terminating for customers and all flow protocols are to be directed towards the NetFlow00. The recommend sampling rates are between 1:100 and 1:10000, depending on the network throughput. Please provide your current default profile in the Technical Questionnaire.

BENOCS Analytics uses flow information for a wide variety of tasks. As such, flow information is one of the two mandatory data sources that needs to be supplied. Due to internal data processing, BENOCS Analytics requires traffic to be sampled at the ingress router.

Sampling rate

All flow protocols use a sampling rate to estimate a router’s traffic. BENOCS Analytics allows its users to define their desired sampling rates on a per-router basis and suggests a rate between 1:1000 and 1:10000, depending on the router’s traffic throughput.

Sampling rates under 1:1000 are useful if the throughput for a router is below 5Gbit/s. It is possible to accommodate sampling rates more precise than 1:1000 for higher-capacity routers, but such settings require a considerable amount of hardware for marginally more accurate information.

Sampling direction

Traffic that enters a router is called ingress traffic and traffic that is forwarded away from a router is called egress traffic. BENOCS Analytics can be configured to work with either ingress and egress traffic or only ingress traffic. It automatically detects and removes double entries to make sure that traffic counts are as accurate as possible.

Interface types

For BENOCS Analytics to provide the high resolution traffic overviews and analyses, as well as enabling automated link classification, we recommend that customers enable sampling on all edge-router interfaces. Receiving data from interfaces connected to routers within the network (internal) as well as interfaces connected to routers in other networks (external) also improves features such as automated link classification.

Example Cisco configuration:

flow exporter-map BENOCS_EXPORTER_MAP

version 9
transport UDP port 2055
source Loopback0
destination xxx.xxx.xxx.xxx
!
flow monitor-map BENOCS_IPv4_MONITOR_MAP
record ipv4
exporter BENOCS_EXPORTER_MAP
!
flow monitor-map BENOCS_IPv6_MONITOR_MAP
record ipv6
exporter BENOCS_EXPORTER_MAP
!
sampler-map BENOCS_SAMPLER_MAP
                random 1 out-of 1000 (as to Customer’s preference)
                !

Interface configuration:

flow ipv4 monitor BENOCS_IPv4_MONITOR_MAP sampler BENOCS_SAMPLER_MAP ingress
flow ipv6 monitor BENOCS_IPv6_MONITOR_MAP sampler BENOCS_SAMPLER_MAP ingress
optional:
flow ipv4 monitor BENOCS_IPv4_MONITOR_MAP sampler BENOCS_SAMPLER_MAP egress
flow ipv6 monitor BENOCS_IPv6_MONITOR_MAP sampler BENOCS_SAMPLER_MAP egress

Supported protocols: sFlow, NetFlow, IPFIX
Exported records should include ipv4 and ipv6 unicast.

BENOCS Analytics can also gather information via telemetry protocols. SNMP is the most common protocol supported, but it is not limited to this protocol. When enabled, additional information such as link byte counters, bundles, and external BGP connections are regularly queried from all routers that export NetFlow towards BENOCS Analytics. By combining the traffic recorded by flow protocols with traffic reported by telemetry BENOCS Analytics can provide more accurate information on the state of a network.

SNMP information is required to display capacity, utilization, cross-validation and the Capacity Planning module.

BENOCS Analytics uses SNMP/Telemetry information to:

• Overlay interface-bitcount with NetFlow traffic
• Obtain interface name and interface label (e.g. ASN)
• Obtain capacity to calculate utilization
• Display 5-min SNMP overlay on 60-mins NetFlow
• Provide billing-grade multi-dimensional traffic data

SNMP queries will originate from our ce00 (CE) node.

When SNMP/Telemetry is configured, we query the following data fields:

• IfName (interface name)
• IfDesc (interface description)
• IF-Speed (interface speed)
• Output-bytes-5 (outgoing interface byte counter)
• Input-bytes-5 (incoming interface byte counter)
• IF-Index (interface index)
• IF-IPv4 (IPv4 address of the interface)
• ConfiguredASN
• ConfiguredASNState
• Hostname

See our help section for a sample of known OIDs of popular router vendors.

Please provide your current default profile in the Technical Questionnaire.

BENOCS Analytics uses IGP information to determine the internal path through the network and to determine auto configuration for several other protocols. This includes, but is not limited to: BGP, SNMP and Telemetry. Major modules supported by IGP are the topology graph, Flow Explorer and Core Planner.

IGP automates almost all functions of BENOCS Analytics. These functions include:

• adding new routers
• bringing up BGP connections
• re-plugging network connectivity
• changing IP addresses.

BENOCS Analytics achieves this automation by using IGP to determine the following information:

• possible topologies for each flow packet
• router adjacency inside the network
• internal path projections

BENOCS supports OSPFv2/v3 and ISIS protocols to export IGP information and establish auto-detect/auto-config and auto-topology. It allows for full flow metric and includes distance/hop count. If a customer uses MPLS then it is possible to configure IGP using label-switched path (LSP).

When IGP information is configured, the ce00 node becomes part of the backbone area, e.g. OSPF Area 0 or ISIS Level 2. It establishes an adjacency just like any other router, not announcing anything itself (unless IGP-based redundancy is required).

If IGP is not available, please provide and update static topology information in the Technical Questionnaire.

Example Cisco ISIS configuration:

router isis 1234
is-type level-2-only
net 49.xxxx.xxxx.xxxx.xxxx.xx
log adjacency changes
lsp-refresh-interval 65000
max-lsp-lifetime 65535
lsp-password text encrypted XXXXXXXXXXXXXX level 1 snp send-only
lsp-password text encrypted XXXXXXXXXXXXXX level 2 snp send-only
address-family ipv4 unicast
metric-style wide
maximum-paths 32
!
interface BENOCSInterface
circuit-type level-2-only
point-to-point
lsp-interval 10
hello-padding disable
address-family ipv4 unicast
metric 10000002 level 2 # some very high metric
mpls ldp sync level 2
!

Optional: address-family ipv6

DNS protocol is required to assign application tags to flows (e.g. video, gaming, software updates and Disney+, Instagram…). Exported fields (cache misses only): query, A-Record/AAAA, CNAME, timestamp & TTL, resolver-IP.

Configuration example:

BENOCS Analytics uses DNS information to identify applications within ASflows by mapping A-Record/AAAA with IPs obtained by NetFlow. The minimal DNS data set required are the cache-misses, i.e. the communication between the operator n  DNS resolvers and the respective authoritative DNSs. Cache misses don’t hold any subscriber data and therefore are not covered by data-protection restrictions. DNS data shall be exported in DNSTAP protocol as documented in https.//dnstap.info.