Fields for switch (and server) interface configuration information

[mikeh-elastic]

Like a server has multiple interfaces in #226 we need to represent information about a switch having N interfaces, for example this has physical name, logical name, status, vlan, duplex, speed and type information.

Switch#show interfaces status
Port    Name               Status       Vlan       Duplex  Speed Type
Gi1/1                      notconnect   1            auto   auto No Gbic
Gi1/2                      notconnect   1            auto   auto No Gbic
Gi5/1                      notconnect   1            auto   auto 10/100/1000-TX
Gi5/2                      notconnect   1            auto   auto 10/100/1000-TX
Gi5/3                      notconnect   1            auto   auto 10/100/1000-TX
Gi5/4                      notconnect   1            auto   auto 10/100/1000-TX
Fa6/1                      connected    1          a-full  a-100 10/100BaseTX
Fa6/2                      connected    2          a-full  a-100 10/100BaseTX
Fa6/3                      notconnect   1            auto   auto 10/100BaseTX
Fa6/4                      notconnect   1            auto   auto 10/100BaseTX

For a server this information is also potentially needed to represent in ecs:

# ethtool eth0
Settings for eth0:
	Supported ports: [ ]
	Supported link modes:   Not reported
	Supported pause frame use: No
	Supports auto-negotiation: No
	Supported FEC modes: Not reported
	Advertised link modes:  Not reported
	Advertised pause frame use: No
	Advertised auto-negotiation: No
	Advertised FEC modes: Not reported
	Speed: 40000Mb/s
	Duplex: Full
	Port: Other
	PHYAD: 0
	Transceiver: internal
	Auto-negotiation: off
	Link detected: yes

Similar to how we don't attempt to represent all containers of a server with a single document and nested objects I would suggest a per interface document for a server, so a single switch will have N documents for the N interfaces which can be collected in a terms aggregation for all switches by the same server name/uid and composite aggregations to emit the server-interface pairs or a subbucket terms on interface within a switch or field collapsing to be able to provide documents to search requests.

Infra UI could key off this and represent a switch like we do containers or servers in the waffle viz to see hot and cold ports.

[dainperkins]

Great idea - nice easy way to start looking at Metrics as well...

if we moved forward with an interface.* field set would we also consider using this for metrics reporting for e.g. host interface metrics (if reported), switches, routers, firewalls, etc.

requires host fields for identification - also should note snmp interface settings to ensure interface ids stay consistent (ifindex persistence in Cisco parlance)

event.type = metrics (assuming snmp interface stats)
host.name = snmp sysname
parse out snmp.sysdesc into host fields (host.description might be nice to add)
*this is likely going to be very specific by vendor

Fields	Example
interface.index	1
interface.id	gigabitEthernet0/1
interface.name	gi0/1
interface.description	Uplink to L3 Core
interface.type	10/100/1000-TX
interface.status	connected/not_connected
interface.admin_status	enabled/disabled
interface.speed	1000 (MB/s) *may require normalization
interface.mtu	1500
interface.duplex	a-full / a-half / full / half
interface.physical_address	00:11:22:33:aa:bb
interface.polling_interval (??)	300s (May not be necessary??)
interface.last_changed	timestamp
interface.in_octets	500
interface.in_unicast	400
interface.in_non_unicast	100
interface.in_discards	5
interface.in_errors	10
interface.in_unknown_prot	2
interface.out_octets	500
interface.out_unicast	400
interface.out_non_unicast	100
interface.out_discards	5
interface.out_errors	10
interface.out_queue_length	64
Potential other items:
interface.dot1q_mode	access/trunk
interface.vlan_native	10
interface.vlan_secondary	50
interface.trunk_vlans	100,101,102
interface.acls	my_access_list_name
interface.channel_group	10
interface.channel_members	[eth1/1, eth 1/2, eth1/3, eth1/5
interface.spantree_mode	portfast
interface.nat	inside/outside
interface.mdix	enabled / disabled
interface.poe	disabled / auto / static / max
interface.poe_watts	18
interface.lldp_tx	enabled/disabled
interface.lldp_rx	enabled/disabled

[dainperkins]

started a PR with the basic interface fields. can add on metrics, etc. as discussion proceeds

#689

[dainperkins]

#689

[nnovaes]

This is also true even for logs. My understanding is that the current interface fields under observer.[ingress/egress] are not a good fit because the assumption on observer is that it is actually seeing some traffic (i.e. for netflow mapping). however, this model does not fit for interface status changes for example.

[djptek]

@dainperkins can we consider this closed after PR #752 ?

[dainperkins]

@djptek I'll open a new one at some point - #752 only covers the basics re: e.g. netflow. I have a bunch of SNMP stats coming in to a cluster but am still playing with field names, etc to put a new rfc in.