Omada SDN products, Access Points, Routers, Switches, Syslog messages, logs, flow records? HELP!
I have been working with devices under the new 'SDN' marketing label, specifically a pair of matched EAP225s. I am interested in logging remotely to a syslog server, and ultimately for such logs to be fed into an elasticsearch database for visualisation and correlation with other network events. I mention the reason for doing this, as it pertains to my questions, but the usage is irrelevant here.
I have taken the time to write this clearly because I hope the information will be useful to others, especially if it leads to the answers I seek. The information I have recorded below represents perhaps an entire day of investigation(!)
To save my fingers, when I use the term GUI I refer to the Omada Controller, of which I run the latest version (4.2.4). "Remote Syslog Server IP/Hostname" and "Syslog Server Port" are set, reflecting my lab environment.
In the GUI, on the "Log" (left-hand side) page I see there are three major tabs:
Alerts, Events, and Notifications
What appears in the Alerts and Events page is controlled by settings on the Notifications page. Here are shown four 'sub tabs' which contain different event types which seem to be categorised as:
|Operation||relevant to overall environment|
|System||relevant to the controller|
|Device||relevant to the EAP, switch, router|
|Client||relevant individual users/client devices|
For each of the tabs, there is an extensive collection of items.
Client Connected to Enterprise SSID (Wireless)
|Client Connection Failed (Wireless)||Event|| Alert|
|Client Connected (Wireless)||Event|| Alert|
Against each event type, eg "Client Connect (Wireless)" are three options:
- Event (means such events will appear in events screen on GUI). Here I presume event indicates, simply "it happened" useful for troubleshooting.
- Alert (means it will appear on alerts screen on GUI). Here I presume event indicates "it happened, you should check". ALSO alert will trigger a SYSLOG message for remote logging.
- Email (means an email will be generated (there is some rolling up of of similarly timed events into an email).
I have managed to correlate the categories as follows:
|Operation||local2||eg Logs were mailed to a*dy@a#y.com automatically|
|System||local3||Master Administrator <redacted> created wireless network with SSID|
|Device||local0||[ap:CC-32-E5-7C-9D-FE] was readopted automatically.|
|Client||local1||[client:B0-FC-0D-7B-D6-53] is roaming from [ap:CC-32-E5-7C-9E-9A][Channel 6] to [ap:CC-32-E5-7C-9D-FE][channel 44] with SSID|
I've left the MAC addresses intact in the example above as they are, after all, only locally relevant to my lab environment, and of little use externally.
I hope the above information will guide others, however it is not the entire story, so here are my questions:
1. List/Description of Possible Events by device
Can/will TP-Link consider publishing and maintaining a matrix of devices, supported log messages and their respective syslog facilities? Once completed I would expect that maintenance would not be onerous. Indeed I would hope that one exists already internally - and I see little logic in it being considered 'internal use only'.
I would anticipate the output being a long list of alert strings, grouped by the (Operation, System) scheme above. For example
|Message as it appears||Syslog 'facility'||Lvl||Meaning/Cause|
|Client Roaming (Wireless)||local1||info||A device has roamed between access points|
Each line of the table would be 'message', Facility (unless my tab->facility is 100% correct), Message meaning (ie the cause, if message is unclear), Severity. If there is any dependency for the alerts ('a' will not occur unless 'b' is ticket) then this too should be described.
2. Could/Would Developers consider improving the 'Client Detail Logs' function into industry standard?
I discovered, accidentally, that another of my system logs was getting suddenly very large. In as much as it was the file reserved for internal 'kernel' messages under Linux did cause me momentary panic until I checked the content. After another (unrecoverable) 90 minutes of packat capture, analysis and swearing I determined that this was, indeed, from one of the EAPs, and it was something akin to a primitive form of flow data, in that it represented a 5 second flow capture of Source and Destination IPs, MACs and TCP/UDP ports. This resulted from my clicking the 'Client Detail Logs' option.
I would ask why it is included in this form, and if it is intended to continue - could developers take it to the logical extreme and export the data as 'flow' records rather than syslog messages? There are ample standards to include, Netflow, IPFix and sFlow to name but the more common options. It occurs to me that all that is missing now is the size of the packet and the time taken.
3. Please would developers improve the Omada SDN platform logging to meet industry requirements?
Having read many posts in this forum, it is quite clear that the logging functionality of the overall platform is insufficient to meet the needs of its intended customers. You are presumably positioning these SDN products at the Small to Medium Business Sector, and within that the education and hospitality sectors. Many customers will have statutority as well as operational needs to user logging, flow and access records as well as for details of failed logins and other information. It seems that the platform supports a far greater granularity than current exposed - so how's about it?
My experience with current and recent products (I still run a pair of T1600G-28TS switches which provide way more granular syslog features AND (though not my version) sflow exporting (solves the 'who accessed what?' requirement of many). I fear you have 'dumbed down' the overall platform in the hope of attracting the 'prosumer' - and in doing so, put off the business community who were happy to purchase from you, as opposed to Cisco or Juniper (at far greater cost).
4. In light of my experience with 'Client Detail Logs' - could you please identify what other GUI options might/do lead to a sudden explosion in data output?
5. Please would you consider some 'case studies' to highlight how your logging features actually meet some or all of the requirements identified elsewhere on this forum (eg firewall logs) etc.
I hope you are able to respond to this. While I am not a greater spender of money, I have remained relatively loyal to TP-Link, however I am starting to despair over the 'dumbing down' of the product, and subsequently Ubiquiti and Mikrotik products - which compete in the same space as your Omada SDN - have far greater appeal.
For the purpose of searches: TP-Link, Omada SDN, EAP225, EAP245, R600, R605, syslog, facility, elasticsearch, logstash, kibana, router, switch, access point.