Router Configuration
The configuration of routers, switches, and other network hardware to collect and export data to Kentik is covered in the following topics :
Notes:
- Model-specific configuration settings for devices sending data to Kentik are provided in Device Configs Directory.
- To learn how to register routers on the Kentik system see Device Settings.
- For general information about flow, see Flow Overview.
- For information about host configuration, see Host Configuration.
- As used in this Knowledge Base, the term “router” refers as well to other non-host network devices such as switches.
Router Configuration Overview
The Kentik Data Engine (KDE), Kentik's big data back-end, collects and correlates data from a variety of sources, including routers, switches, and other hardware in your Kentik-monitored network infrastructure. Data from these devices includes flow records (NetFlow, IPFIX, sFlow; see Overview) as well as other network data such as BGP and SNMP.
Enabling Kentik to gather the above data from a given router involves configuration steps on the device itself and also in the Kentik portal using the Device Settings Dialog (accessed via Settings » Devices). Before starting, you'll need to decide which of the following methods you'll use to get the data to Kentik:
- Direct to KDE ingest servers.
- Through a local encryptor/redirector running the Kentik software called “kproxy” (see Kentik Proxy Agent).
The device configuration process varies depending on device manufacturer but is typically performed in “configuration mode” or in a “configuration editor.” Before you start, you’ll need to know the following information:
- IP and port: The destination IP and Port to which the router should send flow data:
- If the flow data is to be sent directly to Kentik, this information (which varies from customer to customer) is found in the General tab of the Device dialog in the Kentik portal (see Device Config Info).
- If the flow data is to be encrypted by kproxy before being sent to Kentik, these values will be the IP and Port you chose on your local encryptor/redirector running kproxy. - Sample rate: The sample rate at which you want to sample flow records (see Flow Sampling). The rate configured on the router should match the rate set for the same device in the Kentik portal (see Device General Settings).
- Ingress or egress: Whether you will examine traffic at ingress or egress (ingress is recommended; see Ingress and Egress).
Once you've gathered the information listed above, you're ready to configure your routers to work with Kentik. Configurations that work on common networking hardware products are covered in Device Configs Directory.
Router BGP Considerations
The following general considerations apply when configuring routers for BGP peering with Kentik:
- The BGP session will be established when Kentik receives a peering request, but session information will not appear in the Kentik portal until flow data is received from the device.
- Kentik peers as an iBGP rr-client (same ASN as the peering router).
- 4-byte ASN compatibility is mandatory.
- Inbound firewall policies (ACLs) must allow inbound BGP sessions from the Kentik peering IP.
Note: Kentik recommends that you filter (not propagate) your default route to Kentik. If a default route is present, it may override the final destination ASN assignment of all unattributed-route flow records, either with your ASN or with the ASN of your default transit provider.
BGP Session Stability
Unlike normal peering or transit links, which are typically over point-to-point links, BGP sessions with Kentik typically traverse several transit providers outside the direct control of both Kentik and our customers.
- If your BGP session with Kentik is interrupted:
- Remember that routing will be unaffected. Our BGP sessions provide only telemetry data, they do not affect traffic forwarding.
- Flow data received by Kentik while a BGP session is down will continue to be correlated with the last known good BGP data received from your network. - If needed, consider the following options to maximize the stability of your BGP sessions with Kentik:
- Use longer timers to avoid unwanted resets when the Internet is “stormy.”
- Contact Kentik support about bypassing the Internet by establishing a Private Network Interconnect (PNI) with Kentik.
Router Troubleshooting
If you've configured a router to send flow to Kentik (using the router-specific configurations listed in Device Configs Directory) and you are not seeing flow from that router in the Kentik portal, then we'll need to know if the router is able to ping our collectors reliably with large packets. To find that out, please perform the following simple tests:
- Determine that there's no loss between your server and Kentik:
ping -c200 -D -s400 flow.kentik.com
- Determine if the MTU between you and Kentik is "normal":
ping -c100 -D -s1472 flow.kentik.com
- Determine if fragmentation works either way:
ping -c100 -s1500 flow.kentik.com
Note: If your organization is registered with Kentik in the EU, the above URLs should instead be flow.kentik.eu.
The information that you gather from these tests will help us troubleshoot the issue if you contact support@kentik.com.
SNMP OID Polling
SNMP polling by Kentik is covered in the following topics:
About SNMP Polling
OIDs are identifiers for SNMP objects that each represent the properties of a network-connected device such as a router. An OID takes the form of a path to the SNMP object it represents. Like a standard HTTP path, each segment represents a successively narrower slice of the entire networked universe, but in the case of an OID each segment is a pre-assigned number. The base OID for MIB-2 defined SNMP variables is 1.3.6.1.2.1.
Kentik polls SNMP OIDs in different categories (see details in the tables of the topics below):
- Selected counter OIDs: See Counter SNMP OIDs.
- Selected info OIDs: See Information SNMP OIDs.
- Selected system information OIDs: See System Information OIDs.
- Selected LLDP OIDs: See LLDP OIDs.
- OIDs relevant only to specific device vendors: See Vendor-specific SNMP OIDs.
Notes:
- By default, SNMP is polled on a given device only when Kentik is actively receiving flow from that device. To poll a device from which you're not receiving flow, use kproxy and specify the device with the -bootstrap_devices argument (see kproxy Proxy Agent Arguments).
- The timeout for polling from Kentik is 60 seconds. If a response is not received then polling is skipped until the next polling interval (see SNMP Polling Intervals).
SNMP Polling Intervals
The polling intervals for a given device depend on the device's SNMP Polling setting, which is set on the SNMP tab in the Add Device or Edit Device dialog (see Device SNMP Settings). The following options are supported:
- Standard: Interface counter and device counter will be polled every 5 minutes and interface description every 3 hours.
- Minimum: Interface counter and device counter won't be polled, and interface description will be polled every 6 hours.
Choosing Standard polling enables the following features of Kentik that depend on device/interface metrics):
- Health status:
- Display of health status, including interface utilization, in Kentik Map (see Kentik Map Health).
- Querying based on health in Data Explorer (see SNMP Interface Metrics). - Connectivity Costs: Calculation of costs based on SNMP-collected traffic volume data (see Connectivity Traffic Calculation).
Notes:
- The SNMP Polling setting has no effect on Kentik's polling of System Information OIDs.
- The Interface List (see Interfaces Page) includes indicators that enable you to compare flow volume as reported via SNMP polling with flow volume as reported in flow records from the same device.
Enabling SNMP Polling
To enable Kentik to properly poll SNMP on a given router:
- Determine which version of SNMP to use (see About SNMP V3).
- Ensure that SNMP is enabled for the router (consult documentation for your router make and model).
- Permit SNMP polling of the router from Kentik's SNMP polling IPs. The IPs are listed in the shaded box at the top of the SNMP tab of the router's Edit Device dialog in the Settings section of the portal (open the dialog by clicking the Edit icon for that router in the Device List).
- Set community on the router to match the SNMP Community string indicated on the router's SNMP tab.
- If the router has been configured to block polling of any of the specific OIDs polled by Kentik (see Kentik-polled SNMP OIDs), re-enable polling of those OIDs.
About SNMP V3
Kentik supports polling via SNMP V3, which is more secure than previous SNMP versions. SNMP V3 is recommended for customers who have concerns about using SNMP V2 over the public Internet.
The SNMP V3 implementation in Kentik allows each of the following to be enabled and configured independently:
- Authentication: Options include:
- None
- MD5
- SHA - Privacy: The actual encryption of SNMP transactions:
- None
- 56-bit DES encryption
- AES-128
Note: Kentik's SNMP V3 privacy options do not currently include 168-bit 3DES.
Using SNMP V3
To use SNMP V3:
- Configure your router to enable polling via SNMP V3. Consult your router documentation for the correct settings.
- Using the SNMP V3 Auth toggle switch in the Add Device or Edit Device dialog in the Kentik portal, enable SNMP V3 and fill in the resulting additional fields (see Edit a Device and Device SNMP Settings).
Verifying SNMP Polling
If you've successfully completed the steps in Enabling SNMP Polling, after about 5 minutes (one complete counter polling interval) you'll be able to verify in the portal that Kentik is able to poll your router:
- Go to the portal's Settings page and choose Networking Devices.
- In the Device list, find the row corresponding to the router and confirm that the SNMP indicator in the Status column is green.
- Click anywhere in the router's row to bring up the Device Details pane.
- Click the View Interfaces button (under Interfaces), which will take you to the Interfaces page for that router.
- Verify that names and descriptions for the router's interfaces appear on the Interfaces page.
- In the Traffic In and Traffic Out columns, verify that the SNMP value (the lower line) is greater than zero.
Note: If the Traffic In and Traffic Out columns are not visible in your Interfaces List, click the Customize button at the top right of the table. In the resuting popup,check the checkmark for those columns (see Customize Columns Popup).
Kentik-polled SNMP OIDs
The OIDs polled by Kentik are listed in the topics below. To enable Kentik to poll SNMP on a given device, the device must not be configured to block polling of any of the listed OIDs.
Notes:
- Discontinuities in the value of counters can occur at re-initialization of the management system, and at other times as indicated by the value of the OID ifCounterDiscontinuityTime (1.3.6.1.2.1.31.1.1.1.19).
- Additional information about the OIDs listed below may be found in the OID Repository at http://oid-info.com/ or the Global OID reference database at http://oidref.com.
Counter SNMP OIDs
The counter OIDs listed below are polled every 5 minutes when SNMP polling is standard (see SNMP Polling Intervals) and are not polled when polling is minimized.
OID | Object/variable name (SNMP_...) |
Portal metric | Streaming Telemetry path | Description |
1.3.6.1.2.1.1.3.0 | sysUpTime | Uptime (dimension) |
N.A. | The time (in hundredths of a second) since the network management portion of the system was last re-initialized. Polled for every device metric collection and stored as Uptime dimension. |
1.3.6.1.2.1.31.1.1.1.6 | ifHCInOctets | Input Bit Rate | in-octets | The total number of octets received on the interface, including framing characters. |
1.3.6.1.2.1.31.1.1.1.10 | ifHCOutOctets | Output Bit Rate | out-octets | The total number of octets transmitted out of the interface, including framing characters. |
1.3.6.1.2.1.31.1.1.1.7 | ifHCInUcastPkts | Input Packets | in-unicast-pkts | The number of packets, delivered by this sub-layer to a higher sub-layer, which were not addressed to a multicast or broadcast address at this sub-layer. |
1.3.6.1.2.1.31.1.1.1.11 | ifHCOutUcastPkts | Output Packets | out-unicast-pkts | The total number of packets that higher-level protocols requested be transmitted, and which were not addressed to a multicast or broadcast address at this sub-layer, including those that were discarded or not sent. |
1.3.6.1.2.1.2.2.1.14 | ifInErrors | Input Errors | in-errors | The number of inbound packets that contained errors preventing them from being deliverable to a higher-layer protocol. |
1.3.6.1.2.1.2.2.1.20 | ifOutErrors | Output Errors | out-errors | The number of outbound packets that could not be transmitted because of errors. |
1.3.6.1.2.1.2.2.1.13 |
ifInDiscards | Input Discards | in-discards | The number of inbound packets which were chosen to be discarded even though no errors had been detected, possibly to free up buffer space. |
1.3.6.1.2.1.2.2.1.19 |
ifOutDiscards | Output Discards | out-discards | The number of outbound packets which were chosen to be discarded even though no errors had been detected, possibly to free up buffer space. |
1.3.6.1.2.1.31.1.1.1.8 |
ifHCInMulticastPkts | Input Multicast Packets | in-multicast-pkts | The number of packets, delivered by this sub-layer to a higher sub-layer, which were addressed to a multicast address at this sub-layer. For a MAC layer protocol, this includes both Group and Functional addresses. |
1.3.6.1.2.1.31.1.1.1.12 | ifHCOutMulticastPkts | Output Multicast Packets | out-multicast-pkts | The total number of packets that higher-level protocols requested be transmitted, and which were addressed to a multicast address at this sub-layer, including those that were discarded or not sent. For a MAC layer protocol, this includes both Group and Functional addresses. |
1.3.6.1.2.1.31.1.1.1.9 |
ifHCInBroadcastPkts | Input Broadcast Packets | in-broadcast-pkts | The number of packets, delivered by this sub-layer to a higher sub-layer, which were addressed to a broadcast address at this sub-layer. |
1.3.6.1.2.1.31.1.1.1.13 | ifHCOutBroadcastPkts | Output Broadcast Packets | out-broadcast-pkts | The total number of packets that higher-level protocols requested be transmitted, and which were addressed to a broadcast address at this sub-layer, including those that were discarded or not sent. |
Information SNMP OIDs
The information OIDs listed below are polled every 3 hours when SNMP polling is standard (see SNMP Polling Intervals), and every 6 hours when polling is minimized.
OID | Object/variable name (SNMP_...) |
Portal dimension (filtering) | Description |
1.3.6.1.2.1.10.166.11.1.2.2.1.3 | mplsL3VpnVrfDescription | VRF Name | The human-readable description of this VRF. Default is "" (empty string). |
1.3.6.1.2.1.10.166.11.1.2.2.1.4 | mplsL3VpnVrfRD | VRF Route Distinguisher | The route distinguisher for this VRF. Default is "" (empty string). |
1.3.6.1.2.1.10.166.11.1.2.3.1.4 | mplsL3VpnVrfRT | VRF Route Target | The route target distribution policy. Default is "" (empty string). |
1.3.6.1.2.1.10.166.11.1.2.1.1.2 | mplsL3VpnIfVpnClassification | N.A. (Kentik internal use) | Denotes whether this link participates in a carrier's carrier, enterprise, or inter-provider scenario. Default is "enterprise." |
1.3.6.1.2.1.2.2.1.2 | ifDescr | Interface Name | A textual string containing information about the interface. Includes manufacturer name, product name, and interface version. |
1.3.6.1.2.1.31.1.1.1.18 | ifAlias | Interface Name | An 'alias' name for the interface, as specified by a network manager, that provides a non-volatile 'handle' for the interface. |
1.3.6.1.2.1.31.1.1.1.15 | ifHighSpeed | Interface Capacity | An estimate of the interface's current bandwidth in bits per second. |
1.3.6.1.2.1.2.2.1.3 | ifType | N.A. | IANAifType |
1.3.6.1.2.1.2.2.1.4 | ifMtu | N.A. | Interface MTU size |
1.3.6.1.2.1.2.2.1.6 | ifPhysAddress | N.A. | Interface Physical (MAC) address |
1.3.6.1.2.1.2.2.1.7 | ifAdminStatus | N.A. | The configured status of the interface. |
1.3.6.1.2.1.2.2.1.8 | ifOperStatus | N.A. | The interface operational status. |
1.3.6.1.2.1.2.2.1.9 | ifLastChange | N.A. | The value of sysUpTime at the time the interface entered its current operational state. If the current state was entered prior to the last re-initialization of the local network management subsystem, then this object contains a zero value. |
1.3.6.1.2.1.31.1.2.1.3 | ifStackStatus | N.A. | The status of the relationship between two sub-layers. |
1.3.6.1.2.1.31.1.1.1.17 | ifConnectorPresent | N.A. | This object has the value 'true(1)' if the interface sublayer has a physical connector and the value 'false(2)' otherwise. |
1.3.6.1.2.1.4.20.1.2 | ipAdEntIfIndex | N.A. | An index value that uniquely identifies an interface. Used to derive the IP displayed for the interface in the portal (interface-related pages and dialogs). |
1.3.6.1.2.1.4.20.1.3 | ipAdEntNetMask | N.A. | The subnet mask associated with the IP address of this entry. Used to derive the IP mask displayed for the interface in the portal (interface-related pages and dialogs). |
1.3.6.1.2.1.55.1.8.1.2 | ipv6AddrPfxLength | N.A. (Kentik internal use) | The length of the prefix (in bits) associated with the IPv6 address of this entry. |
System Information OIDs
The system information OIDs listed below are polled by Kentik only once per client restart and are not affected by the SNMP polling interval setting.
OID | Object/variable name (SNMP_...) | Description |
1.3.6.1.2.1.1.1 | sysDescr | A textual description of the entity. Includes the full name and version identification of the system's hardware type, software operating-system, and networking software. |
1.3.6.1.2.1.1.2 | sysObjectID | The vendor's authoritative identification of the network management subsystem contained in the entity. Note: Used by Kentik to determine the vendor. |
1.3.6.1.2.1.1.4 | sysContact | The textual identification of the contact person for this managed node, together with information on how to contact this person. If no contact information is known, the value is the zero-length string. |
1.3.6.1.2.1.1.5 | sysName | An administratively-assigned name for this managed node. By convention, this is the node's fully-qualified domain name. If the name is unknown, the value is a zero-length string. |
1.3.6.1.2.1.1.6 | sysLocation | The physical location of this node. If the location is unknown, the value is a zero-length string. |
1.3.6.1.2.1.1.7 | sysServices | A value indicating the set of services potentially offered by this entity. |
LLDP OIDs
The LLDP OIDs listed below are polled by Kentik every three hours. Kentik is able to create an L2 topology map based on the LLDP information.
OID | Object/variable name (SNMP_...) | Description |
1.0.8802.1.1.2.1.4.1.1.6 | lldpRemPortIdSubtype | The type of port identifier encoding used in the associated 'lldpRemPortId' object. |
1.0.8802.1.1.2.1.4.1.1.7 | lldpRemPortId | The string value used to identify the port component associated with the remote system. |
1.0.8802.1.1.2.1.4.1.1.8 |
lldpRemPortIdDesc | The string value used to identify the description of the given port associated with the remote system. |
1.0.8802.1.1.2.1.4.1.1.9 |
lldpRemSysName | The string value used to identify the system name of the remote system. |
Vendor-specific SNMP OIDs
Each OID listed below is polled only for devices of a specific vendor, which is determined based on the sysDescr OID (see System Information OIDs). Data gathered from polling these OIDs is used to enable metrics in the category SNMP Device Metrics.
Notes:
- When you configure your device to enable polling of a given OID, that permission includes polling of all children of that OID.
- While these OIDs contain both counter data (metrics) and non-numeric information, for the purpose of setting the polling interval they are treated as counters (see SNMP Polling Intervals).
- Additional information about the OIDs listed below may be found in the OID Repository at http://oid-info.com/ or the Global OID reference database at http://oidref.com.
OID | Object/ variable name | Kentik usage | Description |
Arista and Palo Alto Networks OIDs | |||
1.3.6.1.2.1.25.2.3 | hrStorageTable | Metric: Memory Utilization | The (conceptual) table of logical storage areas on the host. Used for Memory Utilization metric and Component dimension. |
1.3.6.1.2.1.25.3.2 | hrDeviceTable | Metadata: Dimension Component | The (conceptual) table of devices contained by the host. Used for Component dimension of the CPU metric. |
1.3.6.1.2.1.25.3.3 | hrProcessorTable | Metric: CPU | The (conceptual) table of processors contained by the host. Used for CPU Utilization metric. |
Cisco OIDs | |||
1.3.6.1.2.1.47.1.1.1.1.7 | entPhysicalName | Metadata: Dimension Component | The textual name of the physical entity. |
1.3.6.1.4.1.9.9.109.1.1.1 | cpmCPUTotalTable | Metric: CPU | A table of overall CPU statistics. |
1.3.6.1.4.1.9.9.48.1.1 | ciscoMemoryPoolTable | Metric: Memory Utilization | An entry in the memory pool monitoring table. |
F5 BIG-IP OIDs | |||
1.3.6.1.4.1.3375.2.1.1.2.20.2 | sysGlobalHostMemTotal | Component = Global | The total host memory in bytes for the system. |
1.3.6.1.4.1.3375.2.1.1.2.20.3 | sysGlobalHostMemUsed | Component = Global | The host memory in bytes currently in use for the system. |
1.3.6.1.4.1.3375.2.1.1.2.20.37 | sysGlobalHostCpuUsageRatio5m | Component = Global | The average usage ratio of CPU for the system in the last five minutes. |
1.3.6.1.4.1.3375.2.1.1.2.1.44 | sysStatMemoryTotal(44) | Component = TMM | The total memory available in bytes for TMM (Traffic Management Module). |
1.3.6.1.4.1.3375.2.1.1.2.1.45 | sysStatMemoryUsed | Component = TMM | The memory in use in bytes for TMM (Traffic Management Module). |
1.3.6.1.4.1.3375.2.1.1.2.20.44 | sysGlobalHostOtherMemoryTotal | Component = Other | The total other non-TMM memory in bytes for the system. |
1.3.6.1.4.1.3375.2.1.1.2.20.45 | sysGlobalHostOtherMemoryUsed | Component = Other | The other non-TMM memory in bytes currently in use for the system. |
1.3.6.1.4.1.3375.2.1.1.2.20.46 | sysGlobalHostSwapTotal | Component = Swap | The total swap in bytes for the system. |
1.3.6.1.4.1.3375.2.1.1.2.20.47 | sysGlobalHostSwapUsed | Component = Swap | The swap in bytes currently in use for the system. |
Huawei OIDs Note: Kentik will ignore any components which have both CPU and Memory utilization equal to 0. |
|||
1.3.6.1.4.1.2011.5.25.110.1.2.1.2 | hwifNet32BitIndex | Interface index mapping | NetStream32BitIndex indicates the interface index which is distributed by VRP. |
1.3.6.1.4.1.2011.5.25.31.1.1.1.1.5 | hwEntityCpuUsage | Metric: CPU | The overall CPU usage of an entity, generally calculated without considering the number of CPUs. |
1.3.6.1.4.1.2011.5.25.31.1.1.1.1.7 | hwEntityMemUsage | Metric: Memory Utilization | The memory usage of an entity, expressed as the percentage of the memory that has been used. |
1.3.6.1.4.1.2011.5.25.31.1.1.1.1.10 | hwEntityUpTime | Dimension: Uptime | The total duration when an entity is in the UP state. |
Juniper OIDs | |||
1.3.6.1.4.1.2636.3.1.13 | jnxOperatingTable | Dimensions and Metrics | A list of operating status entries. Used for CPU and Memory Utilization metrics and Component dimension. |
Nokia OIDs | |||
1.3.6.1.4.1.6527.3.1.2.3.4.1.4 | vRtrIfName | Metadata: VRF | The administrative name assigned this router interface. The interface name must be unique among entries with the same vRtrID value. In order for row creation to succeed, a value must also be assigned to vRtrIfName. |
1.3.6.1.4.1.6527.3.1.2.3.4.1.34 | vRtrIfDescription | Metadata: VRF | The value of vRtrIfDescription is a user provided description string for this virtual router interface |
1.3.6.1.4.1.6527.3.1.2.3.4.1.63 | vRtrIfGlobalIndex | Metadata: VRF | The value of vRtrIfGlobalIndex uniquely identifies this interface in the tmnx system. This field provides an identifier for router interfaces similar to the vRtrIfIndex value, except that vRtrIfIndex is unique within each virtual router. The vRtrIfGlobalIndex is unique system wide regardless of the vRtrID. |