Dear TP-Link,

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:

 

 

TAB	Presumed Purpose
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.

Operation

System

Device

Client

 

Client Connected to Enterprise SSID (Wireless)	[]Event	[] Alert	[] Email
Client Connection Failed (Wireless)	[]Event	[] Alert	[] Email
Client Connected (Wireless)	[]Event	[] Alert	[] Email

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:

 

Event Correlation to Syslog

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.