Ecs: Fields for switch (and server) interface configuration information

[mikeh-elastic]

Like a server has multiple interfaces in https://github.com/elastic/ecs/issues/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

https://github.com/elastic/ecs/pull/689

[dainperkins]

https://github.com/elastic/ecs/pull/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 https://github.com/elastic/ecs/pull/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.